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

From: Javed Asghar <[email-masked]>
Date: Tue, 20 May 2014 01:09:27 +0200

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] 
> <mailto:[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]
>     <mailto:[email-masked]>]
>     > Sent: 02 April 2014 09:26
>     > To: [email-masked] <mailto:[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] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/pim
>
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 May 2014 15:06:58 -0400

Hi Javed,

Yes - I'm sorry for the delay (travel & sick).
If you and others can respond to my comments quickly, I can get this
into IETF Last Call before
Thurs so it will make the telechat after this one.

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
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.

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).

Nits:
Figure 1 - the figure is not properly aligned

Regards,
Alia

On Mon, May 19, 2014 at 7:09 PM, Javed Asghar <[email-masked]> 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,
>>
>> > 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."
>>
>> > 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]]
>> > To: [email-masked]; draft-ietf-pim-explicit-rpf-vector
>> >    The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
>> >    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
>> >    For some applications, it might be useful to have a way to specify
>> > 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
>> > [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
>> > entries would not be good enough. In Figure 1 it would appear that the
>> > 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
>> >
>> > 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
>> >    The F bit MUST be set to 0 in all Explicit RPF vectors in case the
>> >    explicit RPF list, because failing to remove the RPF vectors could
>> > However, this doesn't seem to be the only way that loops can be caused
>> > - the use of loose hops with poorly ordered list entries could create a
>> >   loop
>> >
>> > 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
>> >    ----
>> > JA>>> We would like to request type 4 attribute from IANA explicitly.
>> >
>> >
>> > Section 13 seems light!
>> >
>> [email-masked]