Subject: Re: [pim] AD review of draft-ietf-pim-explicit-rpf-vector

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 15 Aug 2014 11:18:00 +0200

Hi Alia,

Really sorry for the delay in responding to your comments. I’ve taken over the editor role from Javed and will drive it forward.

> Comments from review:
> 
> Sec 10:  If the RPF vector isn't understood, isn't the path taken by
> the traffic not going to conform to that desire?  I agree that the
> possibility for loops is bad if the explicit RPF vector remained - but
> I am also concerned that there's no way to tell that the desired path
> wasn't taken - in terms of errors reported or so on.   I don't see a

Yes, you’re right, but this is also the nature of the beast ;-) PIM does not have any back signalling to indicate failures or notifications regarding the status of the tree being build.

> protocol based way of forcing an error to be returned or capability
> checking - so I'm expecting to see a small paragraph that talks about
> the requirement in terms of manageability for computing the explicit
> path and perhaps using mtrace to verify.   If you have a better
> suggestion, I would love to see it.

How the explicit path is determined is outside the scope of the draft. 

Whether or not the PIM tree is broken due to unicast routing, wrong RPF vector (RFC5496), or wrong explicit RPF vector on the stack (this draft), the same existing tools can be used to troubleshoot it, like mtrace. I don’t think this draft introduces different requirements. 

> I do feel that this mechanism is under-specified in the context of how
> it is to be used.  For example, is make-before-break important?  What
> about knowing that the new path is fully created before modifying the
> other one for live-live?  How is any of this coordinated if there are
> multiple leaf-nodes independently determining the explicit RPF vector
> to use?  I do see Sec 7 discussing how to handle conflicts - but I
> don't see any consideration of the dynamics of that solution or why it
> is a good choice (beyond being a choice and in RFC 5384).

Good question. The RPF vector stack carried within the PIM join is routing information that avoids a RIB lookup at each node. Suppose there is a change in the vector stack that makes the RPF interface change from A to B. This is treated as a RPF change that could have occurred due to a RIB update, no difference there. If you want to make the RPF change using Make-Before-Break you could, but its not a requirement introduced by this draft.

I think you’re overall concern is mostly about how do you guarantee the vector stack is consistent and managed, and users of this draft should be aware of the consequences of incorrect vectors. I’ve added the following text, does that address your concerns?

——
   This document describes the procedures to carry Explicit RPF vectors
   in PIM, but it does not introduce any new mechanism in PIM to
   validate the correctness of the RPF vectors.  It is up to the
   mechanism(s) that produce the Explicit RPF Vectors to ensure they are
   correct.  Existing mechanisms like [I-D.ietf-mboned-mtrace-v2] may be
   used to verify how the PIM tree was build.
—

> 
> Nits:
> Figure 1 - the figure is not properly aligned

Fixed.

I’ve attached the updated draft,

Thx,

Ice.

> 
> Regards,
> Alia
> 
> 
> On Mon, May 19, 2014 at 7:09 PM, Javed Asghar <[email-masked]> wrote:
>> Hi Alia,
>> 
>> Did you get a chance to review? Its been awhile.
>> If its ok, we'd like to move it forward.
>> 
>> Thanks,
>> -Javed.
>> 
>> 
>> On 4/3/2014 3:11 PM, Alia Atlas wrote:
>> 
>> Thanks for updating the draft.  I will review it very soon so we can get it
>> moving along.
>> 
>> Alia
>> 
>> 
>> On Thu, Apr 3, 2014 at 9:07 AM, IJsbrand Wijnands <[email-masked]> wrote:
>>> 
>>> Thanks Adrian,
>>> 
>>>> Forwarded to Alia who now has the joy of being your AD.
>>>> 
>>>> From me, just to note that you cannot demand a code point from IANA, you
>>>> can only request one. The way to do it is to use the TBD form of the text I
>>>> suggested and then say. "It is requested that IANA assign the value 4."
>>> 
>>> We'll change it to say 'requested'.
>>> 
>>>> 
>>>> Note for future reference that if you feel an attachment for a specific
>>>> code point you really, really need to apply for an early allocation (RFC
>>>> 7120) because someone else might come along in the intervening time and use
>>>> your value for something else.
>>> 
>>> Yes, we know about that. I remember discussing it with Stig at one point,
>>> but since this was the only draft in the queue to request such value I think
>>> the conclusion was that its not necessary to do early allocation, but your
>>> right, we should really always do that to be safe.
>>> 
>>> Thx,
>>> 
>>> Ice.
>>> 
>>> 
>>>> 
>>>> Adrian
>>>> 
>>>> From: Javed Asghar [mailto:[email-masked]]
>>>> Sent: 02 April 2014 09:26
>>>> To: [email-masked]; draft-ietf-pim-explicit-rpf-vector
>>>> Subject: Re: AD review of draft-ietf-pim-explicit-rpf-vector
>>>> 
>>>> Hi,
>>>> 
>>>> Submitted updated draft:
>>>> http://www.ietf.org/internet-drafts/draft-ietf-pim-explicit-rpf-vector-04.txt
>>>> Please see comments inline below.
>>>> 
>>>> Cheers,
>>>> -Javed.
>>>> 
>>>> 
>>>> On 1/26/2014 3:22 AM, Adrian Farrel wrote:
>>>> Hi,
>>>> 
>>>> I have done my usual AD review of this document after receiving the
>>>> publication request. The purpose of the review is to catch and fix
>>>> any issues that might otherwise show up in IETF last call or IESG
>>>> review. This helps smooth the passage of the document later and also
>>>> increases the quality text.
>>>> 
>>>> This seems like a good and simple proposal, and I don't want to bog
>>>> it down. But there are a number of small editorial issues and a
>>>> couple of technical questions included below.
>>>> 
>>>> I have put the document into "Revised I-D Needed" state and will
>>>> wait to see an updated version before I start the IETF last call.
>>>> But please feel free to debate any of these points with me.
>>>> 
>>>> Thanks for the work.
>>>> 
>>>> Adrian
>>>> 
>>>> ---
>>>> 
>>>> You need to fix the idnits before I can put this to IETF last call.
>>>> 
>>>> - Missing page breaks
>>>> - 2119 boilerplate broken (you have "SHALL" "NOT")
>>>> - there is a line too long
>>>> - missing reference for [draft-mofrr-karan]
>>>> 
>>>> [Shepherd - Your write-up says no nits found. How come?]
>>>> 
>>>> ---
>>>> 
>>>> Conventionally we have used the term "strict" in counterpoint to
>>>> "loose" to describe hops, and termed the whole path "explicit". I
>>>> don't suppose this matters: you are defining your own terms for a
>>>> new application in PIM.
>>>> 
>>>> However, this has led to some confusion in the text because of the
>>>> normal use of the English word "explicit". For example, the Abstract
>>>> says:
>>>>   This document defines a new Reverse Path Forwarding (RPF) Vector
>>>>   TLV to build multicast trees via an explicit path sent in the PIM
>>>>   join.
>>>> ...which doesn't give any clue to the distinction between this work
>>>> and RFC 5496. You might be better with something like:
>>>>   The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
>>>>   can be included in a PIM Join Attribute to allow a leaf to apply
>>>>   controls to the path of a multicast tree. This document defines a
>>>>   new Vector Attribute type so that an RPF Vector TLV can be used to
>>>>   indicate that the unicast address indicated in the TLV must be used
>>>>   as the next hop in the multicast tree.
>>>> 
>>>> This kind of language could usefully be repeated throughout the
>>>> document.
>>>> 
>>>> JA>>> Updated
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Section 1
>>>> 
>>>>   For some applications, it might be useful to have a way to specify
>>>>   the explicit path along which the PIM join is propagated.
>>>> 
>>>> Could you possibly be a little less vague? :-)
>>>> If this is the level of certainty you have for the utility of your work
>>>> then it shouldn't be on the Standards Track. Fortunately, you *do* have
>>>> a good use case later in the document.
>>>> 
>>>> I suggest re-ordering paragraphs:
>>>> 
>>>> 3, 4, 2
>>>> 
>>>> ...and delete paragraph 1.
>>>> 
>>>> ---
>>>> 
>>>> JA>>> Updated.
>>>> 
>>>> 
>>>> Suggest to rename Section 3 "Motivation"
>>>> 
>>>> ---
>>>> 
>>>> JA>>> Updated
>>>> 
>>>> 
>>>> Section 3
>>>> 
>>>> As noted above, you need to provide the reference for
>>>> [draft-mofrr-karan]. But actually, I wonder whether you really need to
>>>> include the citation as the text in the paragraph seems to hold up well
>>>> without any further explanation.
>>>> 
>>>> ---
>>>> 
>>>> JA>>> Updated.
>>>> 
>>>> 
>>>> Section 3
>>>> 
>>>>   It might be useful to have a way to specify the explicit path
>>>>   along which the PIM join is propagated.
>>>> 
>>>> I think you established that it *is* useful in the previous text.
>>>> 
>>>> JA>>> Corrected.
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Section 3
>>>> 
>>>>   How the Explicit RPF Vector list is determined is outside the
>>>>   scope of this document. It may either be manually configured by
>>>>   the network operator or procedures may be implemented on the
>>>>   egress router to dynamically calculate the vector list based on
>>>>   a link state database protocol, like OSPF or IS-IS.
>>>> 
>>>> I agree that this should be out of scope and you should say so.
>>>> However, having said it is out of scope, why do you go on to
>>>> discuss it?
>>>> 
>>>> JA>>> Ack. This is implementation specific. We have changed this
>>>> discussion as example. This was feedback from previous reviews.
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> You should give more clarity as to why an RPF list using 5496 list
>>>> entries would not be good enough. In Figure 1 it would appear that the
>>>> list {R4, R3, R6, R5, R2, R1} would work just fine using 5496.
>>>> 
>>>> JA>>> Added more clarity with a comparison between Explicit RPF Vector
>>>> and RFC5496 procedures.
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Section 5
>>>> 
>>>>   This draft uses PIM join attribute type 4 for specifying an Explicit
>>>>   RPF Vector.
>>>> 
>>>> Please make this:
>>>> 
>>>>   This draft uses PIM join attribute type TBD by IANA for specifying an
>>>>   Explicit RPF Vector.
>>>> 
>>>> ---
>>>> 
>>>> JA>>> Updated.
>>>> 
>>>> 
>>>> Section 7 is describing, for example, simple network with source S and
>>>> leafs R1 and R2...
>>>> 
>>>>  A   R1
>>>> / \ /
>>>> S   C
>>>> \ / \
>>>>  B   R2
>>>> 
>>>> ...where R1 sends explicit RPF TLVs {C, A} and that path is set up.
>>>> Then R2 sends explicit RPF TLVs {C, B}.
>>>> 
>>>> Section 3.3.3 of RFC 5384 is cited as the tie-breaker.
>>>> This is OK, but it appears to say that the Explicit RPF is not
>>>> mandatory. It would be nice to make it very clear that a receiver has
>>>> no expectations that the explicit RPF list it supplies will actually be
>>>> used.
>>>> 
>>>> JA>>> There is no change in our draft with respect to this behavior and
>>>> its documented well in RFC 5384 section 3.3.3. Adding more text could
>>>> confuse the reader. We felt the current text is sufficient. Let us know if
>>>> this is ok with you.
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Section 10
>>>> 
>>>> This is important material to include, but I think it needs some work.
>>>> 
>>>>   The F bit MUST be set to 0 by a downstream router in the join that
>>>>   is sent to the upstream router that does not support Explicit RPF
>>>>   vector.
>>>> 
>>>> But the downstream router doesn't know whether the upstream router
>>>> supports the new vector or not! So I think you need...
>>>> 
>>>>   The F bit MUST be set to 0 in all Explicit RPF vectors in case the
>>>>   upstream router receiving the join does not support the TLV. As
>>>>   described in section 3.3.2 of [RFC5384], routers that do not
>>>>   understand the type of a particular attribute that has the F bit
>>>>   clear will discard it and continue to process the join.
>>>> 
>>>>   This processing is particularly important when the routers that
>>>>   do not support the Explicit RPF TLV are identified as hops in the
>>>>   explicit RPF list, because failing to remove the RPF vectors could
>>>>   cause upstream routers to send the join back toward these routers
>>>>   causing loops.
>>>> 
>>>> JA>>> Updated. Thanks for the clarity. Its very precise.
>>>> 
>>>> 
>>>> 
>>>> However, this doesn't seem to be the only way that loops can be caused
>>>> (referring back to section 9).
>>>> I don't see this mentioned in RFC 5496 either, but surely:
>>>> - the RPF list could contain an explicit loop
>>>> - the use of loose hops with poorly ordered list entries could create a
>>>>  loop
>>>> 
>>>> It is fine to note that this is caught by normal PIM processing, but
>>>> you should say so, and you should say what happens to the join. It
>>>> seems to me that 3.3.4 of 5496 only catches the case where join is
>>>> targeting the same upstream neighbor. But the sequential list nature
>>>> of the RPF list means that the loop might not be "endless" but could
>>>> still be a loop. How is this caught and handled?
>>>> 
>>>> 
>>>> JA>>> Please note that the explicit or loose RPF vector list at every
>>>> hop will consume the RPF vector entry. If an explicit or loose RPF vector
>>>> list is constructed poorly (eg. mis-config) the processing of the RPF vector
>>>> is still as described in RFC 5496 and doesn't need to change. We need to fix
>>>> the user error.
>>>> 
>>>> 
>>>> ---
>>>> 
>>>> Section 11
>>>> 
>>>> Please replace...
>>>> 
>>>> OLD
>>>>   Type
>>>>   ----
>>>>   The Vector Attribute type is 4.
>>>> NEW
>>>>   Type
>>>>   ----
>>>>   The Vector Attribute type is TBD by IANA.
>>>> END
>>>> 
>>>> ---
>>>> 
>>>> JA>>> We would like to request type 4 attribute from IANA explicitly.
>>>> 
>>>> 
>>>> Section 13 seems light!
>>>> 
>>>> The RPF list (and especially the explicit RPF) provides a way to
>>>> cause traffic to take different routes through the network. This
>>>> could be used to cause traffic to take expensive paths, to be
>>>> routed through hot parts of the network, or to be directed to
>>>> snooping nodes.
>>>> 
>>>> This means that the existence of the RPF TLV makes the use of
>>>> security in PIM more important to prevent tampering with the RPF
>>>> list.
>>>> JA>>> Good point.
>>>> 
>>>> 
>>>> But it also raises a question of policy and authorization. Clearly,
>>>> when a receiver seeks to join a multicast tree, it must be
>>>> authenticated for that join. But additionally, you may want to note
>>>> that the inclusion of an RPF list by a receiver should be subject to
>>>> policy.
>>>> 
>>>> JA>>> Updated.
>>>> 
>>>> 
>>>> .
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> pim mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pim
>> 
>> 
>>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 26 Aug 2014 17:08:42 -0400

Hi Ice,

On Fri, Aug 15, 2014 at 5:18 AM, IJsbrand Wijnands <[email-masked]> wrote:

> Hi Alia,
>
> Really sorry for the delay in responding to your comments. I’ve taken over
> the editor role from Javed and will drive it forward.
>

Ok.   Could you please also respond to Jeffrey's comments in
http://www.ietf.org/mail-archive/web/pim/current/msg02993.html ?  I asked
him for a review as well, due to my concerns.

> Yes, you’re right, but this is also the nature of the beast ;-) PIM does
> not have any back signalling to indicate failures or notifications
> regarding the status of the tree being build.

Right - so you get a best-effort attempt to follow the RPF vector.  At a
minimum,
there should be something about manageability or operational concerns here.

> Whether or not the PIM tree is broken due to unicast routing, wrong RPF
> vector (RFC5496), or wrong explicit RPF vector on the stack (this draft),
> the same existing tools can be used to troubleshoot it, like mtrace. I
> don’t think this draft introduces different requirements.

Then say so - b/c you have silent failures and no details on how the paths
could or should be
computed.

> Good question. The RPF vector stack carried within the PIM join is routing
> information that avoids a RIB lookup at each node. Suppose there is a
> change in the vector stack that makes the RPF interface change from A to B.
> This is treated as a RPF change that could have occurred due to a RIB
> update, no difference there. If you want to make the RPF change using
> Make-Before-Break you could, but its not a requirement introduced by this
> draft.
>
> I think you’re overall concern is mostly about how do you guarantee the
> vector stack is consistent and managed, and users of this draft should be
> aware of the consequences of incorrect vectors. I’ve added the following
> text, does that address your concerns?
>
> ——

It helps.  I'm also concerned that conflicts for the explicit rpf vector
differences aren't clearly articulated.

Finally - I really don't see this as being informational.  Either it's
experimental or, since the chairs believe that it has WG consensus, it is
standards track.

Thanks,
Alia

---

From: IJsbrand Wijnands <[email-masked]>
Date: Thu, 28 Aug 2014 10:56:28 +0200

Hi Alia,

Thanks for the comments.

> Ok.   Could you please also respond to Jeffrey's comments in http://www.ietf.org/mail-archive/web/pim/current/msg02993.html ?  I asked him for a review as well, due to my concerns. 

Yes, will do.

> It helps.  I'm also concerned that conflicts for the explicit rpf vector differences aren't clearly articulated.

Ok, that relates to Jeffrey’s comments, right?

> 
> Finally - I really don't see this as being informational.  Either it's experimental or, since the chairs believe that it has WG consensus, it is standards track.

I had already changed it to ‘Standards Track’ in version-05 that I attached :-)

Thx,

Ice.