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

[John E Drake <[e-mail]>]

I had mentioned "Application Specific"

Yours Irrespectively,

John



Juniper Business Use Only
From: Yingzhen Qu <[e-mail]>
Sent: Thursday, June 18, 2020 4:30 PM
To: Les Ginsberg (ginsberg) <[e-mail]>; 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)

[External Email. Be cautious of content]

Hi Les,

The proposed new titles are much better than the old ones. I'm debating between "application-scoped" and "application-based", but no strong opinion. It's up to you and Peter to decide a good name.

Thanks,
Yingzhen

From: "Les Ginsberg (ginsberg)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, June 18, 2020 at 11:04 AM
To: Yingzhen Qu <[e-mail]<mailto:[e-mail]>>, "Les Ginsberg (ginsberg)" <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>, "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)

Yingzhen -

Thanx for providing the YANG example - and for taking on the additions to the IGP YANG models.

Regarding changing the titles of the documents, I see your point. The work started because of issues related to different TE applications (RSVP-TE and SR Policy) - but you are correct that the solution provided can be used by applications that are NOT TE related.

Peter and I are still mulling this over, but how about these for new titles?

IS-IS Application-Scoped Link Attributes
OSPF Application-Scoped Link Attributes

   Les




From: Yingzhen Qu <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, June 17, 2020 11:29 PM
To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:ginsberg=[e-mail]>>; 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]>; Acee Lindem (acee) <[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)

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://urldefense.com/v3/__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*7Cebfff0c58b924ba8765208d813b215f3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637281002898434543&sdata=wHXivwmdfWQ5653WGjMKZSYIQClCTug3u*2BPoSKEEza0*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UA7KrwNY_w8mfXRLRdaE-wgWhLHJWfwf_h0cxPJvPZTmkj99gvRbCfr-fXTKX6k$>
https://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/<https://urldefense.com/v3/__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*7Cebfff0c58b924ba8765208d813b215f3*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637281002898434543&sdata=PpbaAJ3X*2FP4NA1GVcAFnGCrn3HEDKyCBh7nS9WtkIV4*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UA7KrwNY_w8mfXRLRdaE-wgWhLHJWfwf_h0cxPJvPZTmkj99gvRbCfr-mrupdFc$>

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.