Re: [pim] I-D Action: draft-ietf-pim-explicit-rpf-vector-04.txt

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Ice,

The new text about conflict resolution looks good.

Another nit:

6.  Mixed Vector Processing

   Explicit RPF Vector attribute does not impact or restrict the
   functionality of other RPF vector attributes in a PIM join. It is
   possible to mix vectors of different types, such that some part of
   the tree is explicit and other parts are loosely routed. RPF vectors
   are processed in the order in which they are specified. That is, the
   first RPF vector attribute is looked at and processed, it can be
   either loose or explicit.

The last sentence looks odd to me with the "That is" part. I can understand the preceding sentence; I can also understand the last sentence w/o the "that is" part. But putting them together with "That is" confuses me. It seems to be that the entire last sentence could be deleted.

Thanks.
Jeffrey

> -----Original Message-----
> From: IJsbrand Wijnands [mailto:[e-mail]]
> Sent: Thursday, October 23, 2014 1:35 PM
> To: Jeffrey (Zhaohui) Zhang
> Cc: [e-mail]
> Subject: Re: [pim] I-D Action: draft-ietf-pim-explicit-rpf-vector-04.txt
> 
> Hi Jeffrey,
> 
> Did you have comments on this?
> 
> Thx,
> 
> Ice.
> 
> On 29 Aug 2014, at 10:33, IJsbrand Wijnands <[e-mail]> wrote:
> 
> > Hi Jeffrey,
> >
> > Thanks so much for the comments, see below.
> >
> >> I noticed that the spec does not talk about what to do when it
> receives some loose rpf vectors from one downstream neighbor and
> >> some strict ones from another neighbor - section 6 talks about mixed
> ones in the same join, and section 7 refers to section 3.3.3
> >> [RFC5384], which is about conflicts between the same type.
> >
> > I agree, this needs to be fixed.
> >
> > How about the following additional text to section 7.:
> >
> > ---
> > The conflict resolution procedures in section 3.3.3 [RFC5384] only
> apply to attributes of the same Join Attribute type. Join Attributes
> that have a different type can't be compared because the content of the
> Join Attribute may have a totally different meaning and/or encoding.
> This may cause a problem if a mix of Explicit RPF Vectors (this document)
> and 'loose' RPF vectors [RFC5496] is received from two or more
> downstream routers. The order in which the RPF vectors are encoded may
> be different and/or the combination of RPF vectors may be inconsistent.
> The procedures in section 3.3.3 [RFC5384] would not resolve the conflict.
> The following procedures MUST be applied to deal with this scenario.
> >
> > A router processing 'Explicit' or 'Loose' RPF Vectors MUST verify that
> the order in which RPF Vectors types appear in the PIM Join Attribute
> list received from its downstream PIM neighbors are equal. Once it is
> determined the RPF Vector types are on the stack are equal, the content
> of the RPF Vectors MUST be compared ([RFC5384]). If it is determined
> that there is either a conflict with RPF Vector types or the RPF Vector
> content, we use the RPF Vector stack from the PIM adjacency with the
> numerically smallest IP address. In the case of IPv6, the link local
> address will be used. When two neighbors have the same IP address,
> either for IPv4 or IPv6, the interface index MUST be used as a tie
> breaker.
> > ---
> >
> > Thx,
> >
> > Ice.