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

From: ycai <[email-masked]>
Date: Fri, 04 Jun 2010 15:44:49 -0700

Hi Dimitri,

In order to maintain readability,  I will just quote the three main points
you brought up.  

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

I would consider this *NOT* part of PIM (or OSPF/IS-IS, for that matter).
The protocols wouldn't know what the operator's intention is.

> 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) ?
 
This draft only modifies the procedure to select an RPF interface (and
neighbour) for a (*, G)/(S, G) entry.  It doesn't modify the procedure of
RPF check done by forwarding code.  Thus, forwarding is not affected by this
draft and not mentioned.

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

Could you please help with some text.  That will help us move things forward
faster.

Thanks.

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

> Hi Yiqun,
> 
>> -----Original Message-----
>> From: ycai [mailto:[email-masked]]
>> Sent: Saturday, May 08, 2010 12:52 AM
>> To: Papadimitriou, Dimitri (Dimitri); Stig Venaas; [email-masked]
>> Subject: Re: [pim] wglc for draft-ietf-pim-mtid-04?
>> 
>> Dimitri,
>> 
>> Sorry for the late reply.  Have been busy with other things.
> 
> Idem. So please consider the following:
> 
>> 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:
>> 
>>> 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.
>> 
>> 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."
> 
> 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 ?
>  
>>>>> "- 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).
>> 
>> 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".
> 
> So, the "default" topology is the non-logically segmented topology.
>  
>> 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.
> 
> OK.
> 
>> 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."
> 
> 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) ?
> 
>>>>> 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 ?
>> 
>> 
>> "encoding" means the join attribute in this case.
>> 
>> We will add the above paragraph in.
>> 
>> 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.
> 
>>> 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
>>>> 
>>>> 
>> 
>> 
>> -- 
>> Yiqun
>> 
>> 
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

-- 
Yiqun

---

From: ycai <[email-masked]>
Date: Thu, 10 Jun 2010 21:09:16 -0700

Dimitri,

Inline please.

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

> Hi,
>> Sent: Saturday, June 05, 2010 12:45 AM
> We use to have "manageability" sections in our document where such
> consideration where expected to be described.
> 
>> RPF check done by forwarding code.  Thus, forwarding is not
>> affected by this draft and not mentioned.
> 
> The sentence to add would read as:
> 
> "This document only modifies the procedure to select an RPF interface (and
> neighbour) for a (*,G) or (S,G) entry. MTID does not modify RPF check
> procedure itself compared to cases where MTID is not used."
> 
>> Could you please help with some text.  That will help us move
>> things forward faster.
> 
> Here is the proposed text:
> 
> 4.2.3. Validating PIM MT-ID Join Attribute
> 
>    An encoded PIM MT-ID join attribute is valid if all of the following
>    conditions are satisfied:
> 
>      - there is exactly 1 PIM MT-ID attribute encoded;
> 
>      - the length field must be 2;
> 
>      - the value must be included in the range [1,4095].
> 
>    If one of these conditions is not verified the encoded PIM MT-ID
>    join attribute is invalid. The Join/Assert packet is not further
>    processed.
> 
>    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
>    implementation if the above conditions are verified.

You pointed out something that the draft indeed needs to clarify/correct.
However,  I would like to suggest something slightly different.

>      - there is exactly 1 PIM MT-ID attribute encoded;
> 

If there are more than one PIM MT-ID attributes included for a source (or
the RP),  I think it is OK to still process this source; we just need to
decide which PIM MT-ID to choose from.  And the draft says to choose the
last one.  Do you see any issue with that?

Frankly speaking,  I'm OK if we decide to ignore this source.  But what is
important here is that, the rest of the PIM J/P message should still be
processed normally.

>      - the length field must be 2;

If the length field is not 2,  the REST of the PIM J/P message MUST be
ignored.  The group, source and RP that is already processed should still be
considered valid.

> 
>      - the value must be included in the range [1,4095].
 
Well,  there are only 12 bits specified for MT-ID.  So the only error case
is when the MT-ID is 0.  I would think it is a bit overkill to ignore the
source if the MT-ID is 0,  but again, I'm fine if we do so.

However, the same as the first error condition, a router must only ignore
the source whose MT-ID attribute encodes MT-ID 0.  The rest of the PIM J/P
message should still be processed normally.

Is the above modification looking good to you?

Many thanks again for the comment.

-- 
Yiqun