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