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

From: Stig Venaas <[email-masked]>
Date: Wed, 21 Apr 2010 11:15:38 -0700

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

---

From: "Papadimitriou, Dimitri (Dimitri)" <[email-masked]>
Date: Mon, 26 Apr 2010 15:35:02 +0200

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)

"- 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 ?

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

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?
> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>

---

From: ycai <[email-masked]>
Date: Wed, 28 Apr 2010 16:07:18 -0700

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:

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

> the doc. is written in such a way that what's defined as the default can never

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.

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

Again, thanks for the review.

-- 
Yiqun