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

From: Alia Atlas <[email-masked]>
Date: Thu, 19 Jun 2014 17:08:10 -0400

Have you had a chance to respond to my review?  It's getting very tight to
even think about getting this progressed before the July IETF.
The last IESG telechat before next IETF is July 10 - and we need to allow
at least 2 weeks for IETF last call.

Thanks,
Alia

On Tue, May 20, 2014 at 3:06 PM, Alia Atlas <[email-masked]> wrote:

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