Hi Les, Deborah, I agree with Les. Especially since we’ve discussed and evolved these encodings in the LSR WG for over 3 years now. With the zero-length attribute bit mask, we essentially have the equivalent of the legacy advertisements, as well as all the limitations. As long as configuration is provided to dictate which encodings are used, I don’t see that the draft needs to specify the default. Thanks, Acee
From: "Les Ginsberg (ginsberg)" <[email protected]> Date: Wednesday, June 17, 2020 at 7:18 PM To: Deborah Brungard <[email protected]>, The IESG <[email protected]> Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, Acee Lindem <[email protected]>, Alvaro Retana <[email protected]> Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT) 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
