Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

[Yingzhen Qu <[e-mail]>]

Hi Rob,

Thank you for your comments, and I agree with you that a sever implementation could use a deviation to add a default if needed.

This YANG will be augmenting base OSPF and ISIS model at protocol instance level.

Thanks,
Yingzhen

From: "Rob Wilton (rwilton)" <[e-mail]>
Date: Thursday, June 18, 2020 at 2:29 AM
To: Yingzhen Qu <[e-mail]>, "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]>, "BRUNGARD, DEBORAH A" <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Acee Lindem (acee)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Hi Yingzhen,

Just commenting for a YANG configuration perspective, I think that the YANG you propose is a reasonable approach.

In future, when it is clear the default behaviour should be app-specific, then the YANG could be changed to remove the mandatory true and add a default.  The combination of these changes would be classified as a backwards compatible change.  Note, a server implementation could also use deviations to equivalent effect to assign a default for a given implementation.

I don’t know whether this YANG would be configured per routing protocol instance, or something more specific (area or interface), but a hierarchical configuration model could be used if this configuration would otherwise be repetitive.

Regards,
Rob


From: iesg <[e-mail]> On Behalf Of Yingzhen Qu
Sent: 18 June 2020 07:29
To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; Acee Lindem (acee) <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Hi Deborah and Les,

From YANG model’s perspective, whether there is a default value is based on the protocol definition and it is optional. For this case, if there is no default value the following could be an example YANG definition:

      choice te-app-op-mode {
        mandatory "true";
        leaf legacy {
          type empty;
        }
        leaf transition {
          type empty;
        }
        leaf app-specific{
          type empty;
        }
        description
          "Link attributes mode.";
      }

“mandatory true” is used here to make this configuration mandatory, which means implementations supporting this draft need to explicitly config the operation mode. I’ll add the YANG support of this feature for both OSPF and ISIS into the next version of the augmentation drafts.
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-yang-augmentation-v1/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-ospf-yang-augmentation-v1%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cfaefb1ec4ef84881166408d8136a1ae4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637280693735793409&sdata=s7JVkAmZK7pGQj7buTZ6juspJPQX4G%2F%2FLADW3zqrpoc%3D&reserved=0>
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-acee-lsr-isis-yang-augmentation-v1%2F&data=02%7C01%7Cyingzhen.qu%40futurewei.com%7Cfaefb1ec4ef84881166408d8136a1ae4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637280693735803401&sdata=bV%2B4lvc8i8hvEjoR6ztQ3ezvL7VSs6ZHKdKCE9MWXV8%3D&reserved=0>

BTW, I’m now wondering whether the title of the draft is precise? Instead of “IS-IS TE Attributes per application”, maybe something like “IS-IS per application link attributes”? considering more applications will be using the sub-TLV and they may not be TE. Same for OSPF.

Thanks,
Yingzhen

From: Lsr <[e-mail]<mailto:[e-mail]>> on behalf of "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>
Date: Wednesday, June 17, 2020 at 4:19 PM
To: "BRUNGARD, DEBORAH A" <[e-mail]<mailto:[e-mail]>>, The IESG <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Acee Lindem (acee)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)
Resent-From: <[e-mail]<mailto:[e-mail]>>

Deborah –

We have a protocol extension that provides alternative ways of supporting legacy applications.

Under the conditions noted in Section 6.1, implementations have a choice as to which advertisements they use.
There is nothing in the document to specify which choice is the default – nor should there be.
To do so  implies that you believe that an implementation which is otherwise compliant (i.e., it sends/receives TLVs in accordance with the specification) could or should be considered in violation of the specification because it chose to use new advertisements as the default with an option to select legacy advertisements rather than use legacy advertisements as the default with an option to use new advertisements.

Further, what makes sense to be the default – from a user convenience POV - is likely to change over time. Initially the existence of legacy routers will be large and the upgraded routers few. This argues for legacy being the default. But a few years down the road and the numbers will be reversed – in which case the “better” default will be “new”. Declaring conformant implementations in violation simply because they decide to align their defaults with their most common deployment scenarios seems like unreasonable punishment.

There are certainly past examples – not least of which is the introduction of the “extended” TLVs in RFC 5305 - which have followed a similar path. Initially it made sense to default to old style advertisements – but over time it made more sense to default to new advertisements.
Note that RFC 5305 was silent on this – which in my opinion is correct and what we should do here.

I also take issue with your assumption that a default MUST be specified in the corresponding YANG model. I am far from a YANG expert – and will happily defer to those with more experience – but I see no reason why this cannot be modeled as a leaf which can take on one enumerated value – but there need not be a default. It is simply required to have a value.

A few more comments inline.


From: BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, June 17, 2020 1:07 PM
To: Les Ginsberg (ginsberg) <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

Les-

To shortcut the discussion on the need for adding a default for “control”, these two sections are inconsistent as currently worded:

Section 6.1.1
Specifies for SR Policy and/or LFA applications: “This will require implementations to provide controls specifying which type of advertisements are to be sent/processed on receive for these applications.”

Section 6.3.3.

“2)Enable the use of the application specific advertisements on all Routers”



[Les:] What is being described here is a “hitless transition strategy”. It is wrong to assume that the use of “enable” here means that the default is “disable”.

This is the action taken in Step 2 after you started (Step 1) by using legacy only.

None of this says or implies anything about what defaults are nor what config commands (if any) were needed to place the box in the state specified at Step 1.



This document is not a vendor configuration guide – and I do not want to make it one.



    Les





If one is “enabling” then the default is “OFF”? So this document already assumes it. I don’t understand the reluctance to add also to section 6.1.1. When the YANG model is defined, this will be the config default. So either you specify now or later – later, may result in every vendor/platform having a different default if they don’t read section 6.3.3. That will be a major interoperability problem – even potentially among the same vendor for different platforms.



This same comment is for the OSPF document – it needs to specify a default.



More notes below.

Thanks,
Deborah

[Les:] “Legacy” refers to routers which do not support the extensions defined in this document.
“Legacy advertisements” are explicitly listed in Section 3.
“Legacy advertisements” have been used (prior to this draft) in support of all of the applications discussed in this draft (RSVP-TE, SRTE (renamed to SR Policy as per your comment), and LFA) because there was nothing else available.
There is no intent to “upgrade RSVP-TE”. The new encodings can be used by RSVP-TE (as discussed in Sections 6.3.4) – but this is not a main motivation for the draft and if it never happens (i.e., RSVP-TE implementations continue to use legacy advertisements) that is fine.
[Deborah:]
Ok, but I still agree with Bruno – this is very confusing on what is being referenced, especially what needs to be done for RSVP-TE deployments. The addition of the default=off will clarify RSVP-TE deployments remain the same.

[Les:]
It is not an update to RFC 5305.
As an analogy, are you suggesting that RFC 5120 should be considered  an update to RFC 5305 because it introduces new forms of IS-Neighbor and Prefix Reachability advertisements?
[Deborah:]

If this document is similar to RFC5120, why doesn’t it use similar wording? It would be much clearer. RFC5120 abstract says “describes an optional mechanism”. It does not use the confusing terms “upgraded” or “legacy”. The abstract for this document says “This document introduces new link attribute advertisements that address both of these shortcomings.” This document does not say “optional”. It would really help to add similar wording to the abstract. Again, specifying the default “OFF”, will ensure the reader knows these are optional.



[Les:]

I see no reason to go beyond what the draft specifies. An implementation which is working and conforms to the published standards in terms of the form of advertisements sent/received is not going to change simply because an RFC says you SHOULD.

[Deborah:]

Maybe some vendors won’t follow an RFC, maybe they will still “work”, but I don’t see that as justification for not clearly defining a control default in one of our RFCs.