+1 to “Application-Specific”
Cheers, Jeff On Jun 18, 2020, 2:09 PM -0700, Les Ginsberg (ginsberg) <[email protected]>, wrote: > John – > > Yes – I like “Application-Specific” better. This matches the term we use > throughout the documents. > > Thanx. > > Les > > From: John E Drake <[email protected]> > Sent: Thursday, June 18, 2020 1:37 PM > To: Yingzhen Qu <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; BRUNGARD, DEBORAH A <[email protected]>; > The IESG <[email protected]> > Cc: [email protected]; [email protected]; Acee Lindem (acee) > <[email protected]>; [email protected]; [email protected] > Subject: RE: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: > (with DISCUSS and COMMENT) > > I had mentioned “Application Specific” > > Yours Irrespectively, > > John > > > Juniper Business Use Only > From: Yingzhen Qu <[email protected]> > Sent: Thursday, June 18, 2020 4:30 PM > To: Les Ginsberg (ginsberg) <[email protected]>; Les Ginsberg (ginsberg) > <[email protected]>; BRUNGARD, DEBORAH A <[email protected]>; > The IESG <[email protected]> > Cc: [email protected]; [email protected]; Acee Lindem (acee) > <[email protected]>; [email protected]; [email protected] > 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)" <[email protected]> > Date: Thursday, June 18, 2020 at 11:04 AM > To: Yingzhen Qu <[email protected]>, "Les Ginsberg (ginsberg)" > <[email protected]>, "BRUNGARD, DEBORAH A" > <[email protected]>, The IESG <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "Acee Lindem (acee)" <[email protected]>, > "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > 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 <[email protected]> > Sent: Wednesday, June 17, 2020 11:29 PM > To: Les Ginsberg (ginsberg) <[email protected]>; BRUNGARD, > DEBORAH A <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; [email protected]; Acee Lindem (acee) > <[email protected]>; [email protected]; [email protected] > 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://datatracker.ietf.org/doc/draft-acee-lsr-isis-yang-augmentation-v1/ > > 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 <[email protected]> on behalf of "Les Ginsberg (ginsberg)" > <[email protected]> > Date: Wednesday, June 17, 2020 at 4:19 PM > To: "BRUNGARD, DEBORAH A" <[email protected]>, The IESG <[email protected]> > Cc: "[email protected]" <[email protected]>, "[email protected]" > <[email protected]>, "Acee Lindem (acee)" <[email protected]>, > "[email protected]" <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [Lsr] Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: > (with DISCUSS and COMMENT) > Resent-From: <[email protected]> > > 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 <[email protected]> > Sent: Wednesday, June 17, 2020 1:07 PM > To: Les Ginsberg (ginsberg) <[email protected]>; The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; Acee > Lindem (acee) <[email protected]>; [email protected] > 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. > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
