Subject: [pim] Few question/suggestions on 'Explicit RPF Vector' draft

From: Bharat Joshi <[email-masked]>
Date: Mon, 17 Jun 2013 08:54:04 +0000

Hi,

       I read through this draft and have some questions/suggestions on the same.

Regards,
Bharat

• Abstract uses 'explicitly configured path sent in the PIM join'. Should we call this explicitly configured path or something else as the path may not be configured in the system. Right?

• In introduction, "In some applications it might be useful" -> "For some applications it might be useful".

• Should we add a limit on number of RPF vectors in the stack? Is it ok to have any number of RPF vectors in the stack as long as the maximum IP packet length is not reached?

• Should the RPF vector address be PIM neighbor's primary IP address or it is fine even if it is one of the secondary IP address of a PIM neighbor?

• In introduction, in following sentence:

If a router receiving an explicit RPF vector does not have a PIM  neighbor matching the explicit RPF vector address it MUST NOT fall back to loosely routing the JOIN.

Its not clear what should be done with the JOIN. Should it be discarded? Should there be some counter maintained for such an action?

• Can we add some text on what happens at a router when the last entry in the explicit RPF vector stack is removed? It will have to do unicast route lookup for either source or the RP depending upon the PIM JOIN. Right?

• What happens if a router does not have a PIM neighbor for the explicit RPF vector at the top of the stack? Does he keep this information in case this neighbor comes up to expedite the joining process or does he discard this join as refresh will anyway take care of this though there may be some delay. 

• Should not this draft talk about join suppression?

• Should not this draft talk about PIM Asserts and how they should be handled?

• Should not this draft talk about how those PIM neighbors handle the PIM JOIN which do not understand this particular attribute yet?

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Stig Venaas <[email-masked]>
Date: Mon, 17 Jun 2013 12:20:06 -0700

Hi

> • Abstract uses 'explicitly configured path sent in the PIM join'. Should we call this explicitly configured path or something else as the path may not be configured in the system. Right?

Right, I think calling it "explicit path" should be sufficient.

> • Should we add a limit on number of RPF vectors in the stack? Is it ok to have any number of RPF vectors in the stack as long as the maximum IP packet length is not reached?

I can't think of any reason to limit it. It wouldn't make sense
to have more than 255 of course.

> • Should the RPF vector address be PIM neighbor's primary IP address or it is fine even if it is one of the secondary IP address of a PIM neighbor?

I think it's good to allow a secondary address, but it should be stated
clearly. Note that for IPv6 it says that a global address must be used,
hence for IPv6 it cannot be the primary address.

> • Can we add some text on what happens at a router when the last entry in the explicit RPF vector stack is removed? It will have to do unicast route lookup for either source or the RP depending upo…

I would think the last is processed just as the previous vectors. It 
will send it
to that neighbor. But the join it sends, won't have any attributes,
right? So the receiving router would then process the join as normal.
I don't see that anything needs to be added here.

> • What happens if a router does not have a PIM neighbor for the explicit RPF vector at the top of the stack? Does he keep this information in case this neighbor comes up to expedite the joining pro…

I think it could be discarded, waiting for the next periodic join. But it
would be a possible optimization. Perhaps this could be a MAY?

> • Should not this draft talk about PIM Asserts and how they should be handled?

Good points.

> • Should not this draft talk about how those PIM neighbors handle the PIM JOIN which do not understand this particular attribute yet?

I would assume according to 5384 if not specified. It might be good to
still mention it though.

Thanks for the detailed review. It certainly should help improve the
document quality.

Stig

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 17 Jun 2013 13:44:14 -0700

>>         I read through this draft and have some questions/suggestions

I found one additional issue. It also uses "S" instead of "E" to mark
end of stack.

Stig

>> Regards,
>> Bharat
>>
>> • Abstract uses 'explicitly configured path sent in the PIM join'.
>> Should we call this explicitly configured path or something else as
>> the path may not be configured in the system. Right?
>
>> • Should we add a limit on number of RPF vectors in the stack? Is it
>> ok to have any number of RPF vectors in the stack as long as the
>> maximum IP packet length is not reached?
>
>> • Should the RPF vector address be PIM neighbor's primary IP address
>> or it is fine even if it is one of the secondary IP address of a PIM
>> neighbor?
>
>> If a router receiving an explicit RPF vector does not have a PIM
>> neighbor matching the explicit RPF vector address it MUST NOT fall
>> back to loosely routing the JOIN.
>  >
>> Its not clear what should be done with the JOIN. Should it be
>> discarded? Should there be some counter maintained for such an action?
>>
>> • Can we add some text on what happens at a router when the last entry
>> in the explicit RPF vector stack is removed? It will have to do
>> unicast route lookup for either source or the RP depending upon the
>> PIM JOIN. Right?
>
>> • What happens if a router does not have a PIM neighbor for the
>> explicit RPF vector at the top of the stack? Does he keep this
>> information in case this neighbor comes up to expedite the joining
>> process or does he discard this join as refresh will anyway take care
>> of this though there may be some delay.
>
>> • Should not this draft talk about how those PIM neighbors handle the
>> PIM JOIN which do not understand this particular attribute yet?
>

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 18 Jun 2013 03:43:04 +0000

Hi Stig,

       Thanks for your response. You did not responsd to few of the questions/suggestions.

       Please see few responses in line.

Regards,
Bharat

> ok to have any number of RPF vectors in the stack as long as the maximum
> IP packet length is not reached?
> 

Ok. I was looking at it more from restricting someone creating a PIM join with huge number of explicit RPF vector and sending it out. It might be unnecessary processing.
 
> hence for IPv6 it cannot be the primary address.

Ok.

I also saw that for IPv6, it clearly mention the global IPv6 address but does not mention anything about IPv4.

Whether it should use secondary addresses or not, it should be clearly stated to avoid any misinterpretation.

> in the explicit RPF vector stack is removed? It will have to do unicast
> route lookup for either source or the RP depending upon the PIM JOIN.
> Right?
> 

I got what you are saying. You are right. The next router need not do any special processing.

> process or does he discard this join as refresh will anyway take care of
> this though there may be some delay.
> 

Ok.
 
> I would assume according to 5384 if not specified. It might be good to

Ok.

---

From: Stig Venaas <[email-masked]>
Date: Mon, 17 Jun 2013 20:55:58 -0700

>         Thanks for your response. You did not responsd to few of the questions/suggestions.

Yes. I just added my thoughts. You had some good questions that
I didn't comment on. Let's see what the authors say.

Stig

---

From: "Apoorva Karan (apoorva)" <[email-masked]>
Date: Wed, 19 Jun 2013 22:50:52 +0000

Hi Bharat,

Thanks a lot for your comments. Please see responses inline and please let us know if you have more questions.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bharat Joshi
Sent: Monday, June 17, 2013 1:54 AM
To: [email-masked]
Subject: [pim] Few question/suggestions on 'Explicit RPF Vector' draft

Hi,

Regards,
Bharat

* Abstract uses 'explicitly configured path sent in the PIM join'. Should we call this explicitly configured path or something else as the path may not be configured in the system. Right?
=> Changed text
 
* In introduction, "In some applications it might be useful" -> "For some applications it might be useful".
=> Changed text

* Should we add a limit on number of RPF vectors in the stack? Is it ok to have any number of RPF vectors in the stack as long as the maximum IP packet length is not reached?
=> There is no restriction on the number of RPF vectors in the stack.

* Should the RPF vector address be PIM neighbor's primary IP address or it is fine even if it is one of the secondary IP address of a PIM neighbor?
=> There is no restriction to limit the vector address to the primary IP address. Corrected the text.

* In introduction, in following sentence:

Its not clear what should be done with the JOIN. Should it be discarded? Should there be some counter maintained for such an action?
=> The packet may be processed and vector stack stored so that the upstream join may be triggered as soon as the neighbor comes up. Updated the text. 

* Can we add some text on what happens at a router when the last entry in the explicit RPF vector stack is removed? It will have to do unicast route lookup for either source or the RP depending upon the PIM JOIN. Right?
=> After the last vector is popped, the PIM join is processed normally. I believe this is obvious and doesn't need added text ?

* What happens if a router does not have a PIM neighbor for the explicit RPF vector at the top of the stack? Does he keep this information in case this neighbor comes up to expedite the joining process or does he discard this join as refresh will anyway take care of this though there may be some delay. 
=> This is implementation specific. We have changed the wording to say that the vector stack may be stored.

* Should not this draft talk about join suppression?
=> Please refer to RFC 5496, same behavior applies to explicit rpf vector.

* Should not this draft talk about PIM Asserts and how they should be handled?
=> Please refer to RFC 5496, same behavior applies to explicit rpf vector.

* Should not this draft talk about how those PIM neighbors handle the PIM JOIN which do not understand this particular attribute yet?
=> RFC 5384 says that an attribute that isn't understood is dropped and not forwarded.  The same behavior applies to this attribute too. The result will be that a regular PIM join will be send upstream of this router.

Regards,
Apoorva

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 20 Jun 2013 03:23:10 +0000

Hi Apoorva,

         Thanks for your response. Please see few responses in line.

Regards,
Bharat

> * Should we add a limit on number of RPF vectors in the stack? Is it ok
> to have any number of RPF vectors in the stack as long as the maximum IP
> packet length is not reached?

Ok.
 
> * What happens if a router does not have a PIM neighbor for the explicit
> RPF vector at the top of the stack? Does he keep this information in
> case this neighbor comes up to expedite the joining process or does he
> discard this join as refresh will anyway take care of this though there
> may be some delay.

Ok.
 
> => Please refer to RFC 5496, same behavior applies to explicit rpf

But the draft should at least mention this with a reference to the other RFC.

> => Please refer to RFC 5496, same behavior applies to explicit rpf

Same as above.

> * Should not this draft talk about how those PIM neighbors handle the
> => RFC 5384 says that an attribute that isn't understood is dropped and
> not forwarded.  The same behavior applies to this attribute too. The
> result will be that a regular PIM join will be send upstream of this
> router.

Again, I think the draft should mention this or refer to the RFC.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 25 Jun 2013 04:49:56 -0700

> to have more than 255 of course.

Is there really anything today that would limit the scope of an MPLS
core to 255 ? IP TTL does not get decrement across an LSP, so it
would have to be something in the MPLS control plane, right ?

Does anybody know what, if any limitations there are on RSVP-TE EROs ?

Adding a TE expert, maybe he can suggest some limit that would be
inline with the TE ERO-size limits.

Cheers
    Toerless

> >? Should the RPF vector address be PIM neighbor's primary IP address or it 
> >is fine even if it is one of the secondary IP address of a PIM neighbor?
> 
> >? In introduction, in following sentence:
> >
> >If a router receiving an explicit RPF vector does not have a PIM  neighbor 
> >matching the explicit RPF vector address it MUST NOT fall back to loosely 
> >routing the JOIN.
> >
> >Its not clear what should be done with the JOIN. Should it be discarded? 
> >Should there be some counter maintained for such an action?
> >
> >? Can we add some text on what happens at a router when the last entry in 
> >the explicit RPF vector stack is removed? It will have to do unicast route 
> >lookup for either source or the RP depending upon the PIM JOIN. Right?
> 
> >? What happens if a router does not have a PIM neighbor for the explicit 
> >RPF vector at the top of the stack? Does he keep this information in case 
> >this neighbor comes up to expedite the joining process or does he discard 
> >this join as refresh will anyway take care of this though there may be 
> >some delay.
> 
> >? Should not this draft talk about join suppression?
> >
> >? Should not this draft talk about PIM Asserts and how they should be 
> >handled?
> 
> Good points.
> 
> >? Should not this draft talk about how those PIM neighbors handle the PIM 
> >JOIN which do not understand this particular attribute yet?
> 

-- 
---
Toerless Eckert, [email-masked]
Cisco NSSTG Systems & Technology Architecture
SDN: Let me play with the network, mommy!

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 25 Jun 2013 13:22:06 +0000

> core to 255 ? IP TTL does not get decrement across an LSP, so it would have to be something in the MPLS control plane, right ?

MPLS header has TTL, same as that of IP header.

> Does anybody know what, if any limitations there are on RSVP-TE EROs ?

RFC3209 doesn't place any restriction on number of ERO or RRO sub-objects.

Cheers,
Rajiv

Sent from my Phone

---

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Tue, 25 Jun 2013 07:13:13 -0700

Thanks, Rajiv.

Seems then we can easily stay in the same ball park by not specifying any
limits either but leave the text as it is.

Cheers
    Toerless

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 25 Jun 2013 13:40:05 +0000

Some offhand answers below...if there are specifics I'm missing in the question let me know.

> would have to be something in the MPLS control plane, right ?

An MPLS label stack entry has an 8-bit TTL, and you have to decrement it by 1 at every hop.  There are some hacks we can do ('no-propagate-ttl' is one vendor's knob) but at the end of the day you have to respect the limit.  We could come up with further hacks to disregard the limit - maybe nested labels and not copying down the outer TTL - but ignoring the TTL is a really bad idea so in practice I can't see it happening.  So TTL is going to be your limiting factor.

As far as ERO, that gets trickier.
(for non-TE people; an Explicit Route Object is an ordered list of hops an RSVP Path message must traverse, and is how we force an LSP across the network down a path other than the IGP shortest path.)

You don't *have* to have an ERO in an RSVP Path message, but of course it's really handy.  You can also have loose hops in a Path which you hairpin through, so you can diverge from the IGP shortest path by only specifying a subset of the hops you want to take.  You're going to hit MTU limits first, and a Path message can have lots of other optional stuff that can eat into the size you'd otherwise use for ERO hops. But if you have 1,000 bytes for ERO hops that's still 125 hops and if you make them loose you can probably cover quite a bit of ground, depending on topology.  There are also facilities to specify not IPaddrs but ASes in an ERO, although I've never seen that in the wild.  

Note that I have not been asked to comment on whether a network with >255 hops is realistic.  In my experience, though, that's an order of magnitude more than people are doing today, and end-to-end TE tunnels are rarer than core-only tunnels (if that matters to your question).

eric

> From: Toerless Eckert (eckert)
> Sent: Tuesday, June 25, 2013 7:50 AM
> To: Stig Venaas
> Cc: Bharat Joshi; [email-masked]; Eric Osborne (eosborne)
> Subject: Re: [pim] Few question/suggestions on 'Explicit RPF Vector'
> draft
> 
> neighbor
> discarded?
> case
> > >for the use of the addressee(s). If you are not the intended
> recipient,
> > >please
> > >notify the sender by e-mail and delete the original message. Further,
> you
> > >are not
> > >to copy, disclose, or distribute this e-mail or its contents to any
> other
> > >person and
> > >any such actions are unlawful. This e-mail may contain viruses.
> Infosys
> > >has taken
> > >every reasonable precaution to minimize this risk, but is not liable
> for
> > >any damage
> > >you may sustain as a result of any virus in this e-mail. You should
> carry
> > >out your
> > >own virus checks before opening the e-mail or attachment. Infosys
> reserves
> > >the
> > >right to monitor and review the content of all messages sent to or
> from
> > >this e-mail