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

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 16 Aug 2016 19:33:57 -0700

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. 

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Aug 2016 05:35:00 +0000

Suresh -

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2016 7:34 PM
> To: The IESG
> Cc: [email-masked]; Christian Hopps; [email-masked];
> [email-masked]; [email-masked]
> Subject: Suresh Krishnan's Discuss on draft-ietf-isis-rfc4971bis-03: (with
> 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.)
> 
> 
> 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.
> 
[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.

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

   Les

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 17 Aug 2016 18:46:52 +0000

Hi Les,

> 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 t…

Please see below.

> 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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 17 Aug 2016 19:32:55 +0000

Suresh -

> Sent: Wednesday, August 17, 2016 11:47 AM
> To: Les Ginsberg (ginsberg); The IESG
> [email-masked]
> Subject: Re: Suresh Krishnan's Discuss on draft-ietf-isis-rfc4971bis-03: (with
> DISCUSS)
> 
> Hi Les,
> 
> >> Cc: [email-masked]; Christian Hopps;
> >> [email-masked]; [email-masked]; [email-masked]
> >> 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
> >> * Section 4 requires the CAPABILITY TLV to be leaked without any
> >> change based on the text below
> >>
> >> 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.
> >>
> > 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?).
> >>
> > 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.
> 
[Les:] Yes - that is exactly my position.
D bit is a control bit to control leaking of the TLV. IT has nothing to do with the contents of the TLV.

   Les