Subject: Re: [pim] wglc for draft-ietf-pim-mtid-04?

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sat, 1 May 2010 09:23:29 +0200

Hi Yiqun, 

> -----Original Message-----
> From: ycai [mailto:[email-masked]] 
> Sent: Thursday, April 29, 2010 1:07 AM
> To: Papadimitriou, Dimitri (Dimitri); Stig Venaas; [email-masked]
> Subject: Re: [pim] wglc for draft-ietf-pim-mtid-04?
> 
> Hi Dimitri,
> 
> As usual, thanks for the review and comment.  Please see the comments
> inline.
> 
> 
> On 4/26/10 6:35 AM, "Papadimitriou, Dimitri (Dimitri)"
> <[email-masked]> wrote:
> 
> > Hi Stig,
> > 
> >  
> > a couple of comments here below:
> > 
> > 
> > Section 3.2: 
> > 
> > "this value must be unique and consistent within the 
> > network domain for the same topology "
> > 
> > explain means to verify uniqueness and consistency checks 
> > would be worth
> > considering (without such techniques, use of the proposed 
> > MT-ID scheme comes at risks of mis-merging)
> 
> This is something that A) we tried to avoid to discuss in 
> this draft which
> is intended to be a protocol specification, and B) we are working on
> separately to try to come up with one or a few tools to help 
> the deployment.
> 
> This draft does attempt to describe what a router should do 
> when it sees
> inconsistency (and many thanks to you and Thomas for helping 
> clarifying the text).  
> 
> The approach the draft takes is similar to what RFC4601 or RFC5015 has
> chosen. Neither specifies a means to verify that RP configuration is
> consistent or correct.

I understand details of such mechanism goes beyond the scope of the document. In case, the mechanism(s) can't be referenced the
minimal conditions for execution could be stated.

> > "- 0 is reserved as the default, and MUST NOT be included 
> > in the join attribute encoding."
> > 
> > the doc. is written in such a way that what's defined as 
> > the default can never be used - why ? 
> 
> For a PIM join generated by a router supporting this draft,  
> whether the
> join includes 0 or not, it refers to the same topology.  
> Therefore, in the
> spirit of trying to be "precise", the draft excludes the use 
> of 0 in the PIM MT-ID field.

I am still not sure to understand your statement ("same topology" than ?). In any case, as consequence, the text should state "- 0 is excluded" instead of "reserved" then (this to prevent confusion with the usual way of understanding "reserved" for future use).

> > Section 4:
> > 
> > "It is important to note that, if the sender is not a PIM neighbor
> >  that has included "PIM Join Attribute" or "PIM MT-ID" option in its
> >  Hello packets, the encoding may still be considered valid by an
> >  implementation."
> > 
> >  if this is the case why require condition of Section 4.1 (MUST) ?
> 
> An upstream router must be known to support this draft in order for a
> downstream router to include the attribute in its  Joins.  
> But the same is
> not true the other way around.  That is,  an upstream router 
> doesn't need to
> know if a downstream  router supports this draft or not when deciding
> whether to accept the attribute from it.
> 
> In essence the draft tries to describe an action that is 
> consistent with the
> "Robustness Principle" outlined in RFC761: "be conservative 
> in what you do,
> be liberal in what you accept from others"
> 
> But if you think such a description rather confuses things.  
> How about we remove the entire paragraph you quoted?

I would rather suggest to clarify the asymmetric processing you describe here (from the first paragraph you wrote here above). 

Now in the initial quote the what creates the confusion is the word "encoding" - the encoding of what ? and it appears to me that encoding is a necessary but not sufficient condition for validity ?

Thanks,
-dimitri.

> Again, thanks for the review.
> 
> 
> > 
> > Thanks,
> > -dimitri.
> > 
> >> -----Original Message-----
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Stig Venaas
> >> Sent: Wednesday, April 21, 2010 8:16 PM
> >> To: [email-masked]
> >> Subject: [pim] wglc for draft-ietf-pim-mtid-04?
> >> 
> >> At the Anaheim meeting there were 10 YES votes and 0 NO votes
> >> for moving
> >> to wglc for draft-ietf-pim-mtid-04. Please let us know what
> >> the rest of
> >> you think within a week from today. If we maintain rough 
> consensus, we
> >> will initiate a wglc on April 29th, so speak up.
> >> 
> >> http://tools.ietf.org/html/draft-ietf-pim-mtid-04
> >> 
> >> Stig
> >> _______________________________________________
> >> pim mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/pim
> >> 
> > _______________________________________________
> > pim mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pim
> 
> 
> -- 
> Yiqun
> 
>

---

From: ycai <[email-masked]>
Date: Fri, 07 May 2010 15:51:31 -0700

Dimitri,

Sorry for the late reply.  Have been busy with other things.  Please see
inline for the comment.  Thanks and have a good weekend.

On 5/1/10 12:23 AM, "Papadimitriou, Dimitri (Dimitri)"
<[email-masked]> wrote:

> I understand details of such mechanism goes beyond the scope of the document.
> In case, the mechanism(s) can't be referenced the

How about the following change to 3.2

From,

"      this value must be unique and consistent within the network
       domain for the same topology"

To, 

"      this value must be unique and consistent within the network
       domain for the same topology.  From deployment point of view,
       one should have a means to detect inconsistency of the MT-ID
       configuration, but the detail of such mechanism is beyond the scope
       of this document."

> I am still not sure to understand your statement ("same topology" than ?). In
> any case, as consequence, the text should state "- 0 is excluded" instead of
> "reserved" then (this to prevent confusion with the usual way of understanding
> "reserved" for future use).

Whether one uses multi-topology or not,  he always has a topology from which
RPF look up takes place.  For now, let us give a name to this topology and
call it "default" or "base".

Without using multi-topology,  it doesn't matter whether one assigns an ID
to "default" or base".

And when multi-topology is introduced,  the above topology must have 0
assigned as its PIM MT-ID.

That is what the text is trying to convey.  Maybe we will just put the above
text in stead of

"      - 0 is reserved, and MUST NOT be included in the
       join attribute encoding."

> I would rather suggest to clarify the asymmetric processing you describe here
> (from the first paragraph you wrote here above).
> 
> Now in the initial quote the what creates the confusion is the word "encoding"
> - the encoding of what ? and it appears to me that encoding is a necessary but
> not sufficient condition for validity ?

"encoding" means the join attribute in this case.

We will add the above paragraph in.

Any other comments?  Thanks.

-- 
Yiqun

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Sun, 23 May 2010 20:01:23 +0200

Hi Yiqun,

> Sent: Saturday, May 08, 2010 12:52 AM
> Sorry for the late reply.  Have been busy with other things.  

Idem. So please consider the following:

> Please see

OK. 

IMHO, one needs to define the behaviour in case non-unique value is effectively detected. The key question being is that behaviour part of PIM or not ?
 
> RPF look up takes place.  For now, let us give a name to this 
> topology and call it "default" or "base".

So, the "default" topology is the non-logically segmented topology.
 
> assigned as its PIM MT-ID.

OK.

>        join attribute encoding."

Thus "0" is associated to "non MT-ID" neighbors. Now, can you explain how multicast datagrams are processed on the incoming interface ? I mean how do you trigger such differentiated RPF (the details are missing from the current version of the document) ? 

> Any other comments?  Thanks.

Yes, "encoding" of join attribute is still not sufficient as condition. Actual "Validity" conditions must be described inside the document.

Thanks,
-dimitri.