Re: [Isis-wg] Suresh Krishnan's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS)

[Suresh Krishnan <[e-mail]>]

Hi Les,

On 08/17/2016 01:35 AM, Les Ginsberg (ginsberg) wrote:
> Suresh -
>
>> -----Original Message-----
>> From: Suresh Krishnan [mailto:[e-mail]]
>> Sent: Tuesday, August 16, 2016 7:34 PM
>> To: The IESG
>> Cc: [e-mail]; Christian Hopps; [e-mail];
>> [e-mail]; [e-mail]
>> Subject: Suresh Krishnan's Discuss on draft-ietf-isis-rfc4971bis-03: (with
>> DISCUSS)
>>
>> Suresh Krishnan has entered the following ballot position for
>> draft-ietf-isis-rfc4971bis-03: Discuss
>>
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-isis-rfc4971bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> * Section 4 requires the CAPABILITY TLV to be leaked without any change
>> based on the text below
>>
>> "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV
>> MUST be leaked into another level without change even though it may
>> contain some sub-TLVs which are unsupported by the Router doing the
>> leaking. "
>>
>> but Section 2 requires a router leaking the TLV from level-2 to level-1 to set
>> the D bit and this violates the "without change" requirement.
>>
>> I think this inconsistency needs to be resolved somehow.
>>
> [Les:] I have trouble seeing this as an inconsistency.
> The text in Section 2 defines the use of the D bit as a means to prevent looping of advertised information. Clearly the setting of the D bit has no impact on the meaning of any of the sub-TLVs in the encapsulating TLV so it is hard for me to see that this is in any way contradictory to the text in Section 4.

Please see below.

>
>> P.S.: One possible way would be to add some exception text for the D bit
>> into the above text in Section 4. Another would be to remove the restriction
>> against change (I noticed that this restriction did not exist in RFC4971 - was
>> this check added to fix some issue identified during deployment?).
>>
> [Les:] The text in RFC 4971 is:
>
> "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
>    TLV MUST be leaked into another level even though it may contain some
>    of the unsupported sub-TLVs."
>
> This was revised in the most recent BIS draft version based on GenArt review comments from Dale Worley to be:
>
> "If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
>    TLV MUST be leaked into another level without change even though it
>    may contain some sub-TLVs which are unsupported by the Router doing
>    the leaking."
>
> We both felt that the revised wording was  more grammatically correct - but it certainly is not any different in intent from the original RFC 4971 text. So I do not see that we have made any substantive change here.
>
> The prohibition against change of content when leaking is essential to correct operation - which is why a normative MUST is present.

I believe that we disagree on what "entire CAPABILITY TLV MUST be leaked 
without change" means. I believe that the Flags field is part of the "entire 
CAPABILITY TLV" and changing the contents of the Flags field violates the 
"without change" clause. You apparently think the prohibition against change 
is limited to the sub-TLVs and changing a flag is not changing the TLV. Is my 
understanding of your position correct?

Thanks
Suresh