Deborah – Inline.
From: BRUNGARD, DEBORAH A <[email protected]> Sent: Friday, June 12, 2020 4:16 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) Hi Les, On my Discuss, that’s good. On my comments, I’m still confused then on the scope of the draft. If it was (2) below only, it would seem that this is an extension of current capabilities (my first reading). Considering (1), “unambiguously”, and the use of the terms “legacy” and “all routers are upgraded” in the document, I wonder why this is not considered an update to RFC5305 – is this updating RSVP-TE routers too? If not, and it is only referring to (legacy) SR routers which are doing “legacy advertisements” then I would agree this would not be an update as there is no RFC saying how an SR router should advertise. Depending on the intention, it would really help to clarify “legacy”, e.g., it is not an RSVP-TE router but a router with SR capabilities still doing “legacy” advertisements. I think Bruno was trying to say this in his rtgdir review. It is really confusing, e.g., here in Section 3, suggest: Section 3. Legacy Advertisements/s/Legacy SR Advertisements, and “in support of RSVP-TE”/s/”in support of SR” (as it’s an SR “legacy” router) But if the intention is to upgrade ALL RSVP-TE routers too, and this is an UPDATE to 5305, here can say “in support of RSVP-TE and SR”. Though if this is the intention, it clashes with 6.1 where it says there is no need to do anything for RSVP-TE. [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. This is introducing new advertisements for link attributes which support per application semantics and provide unambiguous association between link attribute advertisements and applications. This is necessary to address deployments where the constraints defined in Section 6.1 cannot be met. 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? What the draft mandates is that new applications (i.e., other than RSVP-TE, SR Policy, LFA) MUST use the new advertisements (Section 6.1) . This avoids the introduction of the issues associated with a mixture of legacy/non-legacy routers that can occur with the pre-existing applications. For existing applications, while we might like to see SR Policy/LFA use the new advertisements, we recognize that this may or may not happen based on the marketplace. For RSVP-TE, the main motivation to move to new advertisements would be to be able to deprecate the use of legacy advertisements and thereby simplify implementations. But we recognize this isn’t a very compelling motivation and likely won’t happen – or will take many years to happen. For 6.1, the 2nd bullet, you should add: RSVP-TE is not deployed/s/RSVP-TE is not deployed or planned to be deployed. Here, I agree with Bruno, you really need to provide guidance on “control”, otherwise you will most likely not have interoperability. Suggest: The default SHALL be use of legacy advertisements. Otherwise this is an UPDATE to 5305 as different vendors will choose different defaults. [Les:] Section 6.1 makes explicit the conditions under which legacy advertisements may be used. This is reflecting the operational realities e.g., since legacy advertisements do not provide per application semantics using them when multiple applications are enabled requires congruence for all of the applications enabled. It also provides guidance to implementors that controls for the types of advertisements which are sent/received will likely be needed. 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. If this is updating RSVP-TE routers, this should have been shared with TEAS (I don’t recall anything). [Les:] I leave it to the WG chairs to address this request – to which I have no objection. Les Thanks, Deborah From: Les Ginsberg (ginsberg) <[email protected]<mailto:[email protected]>> Sent: Thursday, June 11, 2020 11:05 AM To: BRUNGARD, DEBORAH A <[email protected]<mailto:[email protected]>>; The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; Acee Lindem (acee) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: RE: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT) Deborah - Thanx for your review. Responses inline. > -----Original Message----- > From: Deborah Brungard via Datatracker > <[email protected]<mailto:[email protected]>> > Sent: Wednesday, June 10, 2020 3:17 PM > To: The IESG <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; Acee > Lindem (acee) <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]>; Acee Lindem > (acee) <[email protected]<mailto:[email protected]>> > Subject: Deborah Brungard's Discuss on draft-ietf-isis-te-app-14: (with > DISCUSS and COMMENT) > > Deborah Brungard has entered the following ballot position for > draft-ietf-isis-te-app-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=B0HMc26iv-rRpJSj6b79IoD45eROsMXYl_47vjPbzpU&s=Sxxeqg1sPR25hOlFdq6FdXJ9FDoxb36lV9tKE8EC6ZI&e=> > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Disis-2Dte-2Dapp_&d=DwMGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=B0HMc26iv-rRpJSj6b79IoD45eROsMXYl_47vjPbzpU&s=NU8WByfd9_z3-C2bkJPB9eCdI-EuaRt4JQL5MFWKnEc&e=> > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > This should be simple to resolve - the use of the SR-TE term is > out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing > Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy. > [Les:] Peter and I have discussed this suggestion. We have agreed to change “SRTE” to “SR Policy” in both drafts. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I found this document a bit easier to read than the OSPF one. Though it also > seems (implementation) confused on 1:1 association of signaling over a link > with data use of the link and so the confusion on what application to support > on the link. As I noted on the OSPF one, it would be much clearer to simply > discuss the main problem (to me) - the ability to support advertisement of > application specific values? > [Les:] There are two issues which this draft is addressing – as detailed in the Introduction: 1)Unambiguously indicate which advertisements are to be used by a given application 2)Support advertisement of application specific values Both are important. > I don't see any discussion on the dark bandwidth problem or the security > problems identified in RFC8426? It would be helpful if the draft pointed to > the > RFC8426 solution. > [Les:] I see RFC8426 and this document as complementary. RFC8426 discusses the operational challenges when multiple applications (specifically RSVP-TE and SR Policy) are deployed in the same network. This document is defining new encodings in support of application specific advertisements, which eliminate ambiguity as to how to pair link attribute advertisements with applications. Discussing dark bandwidth issues seems out of scope for this document. Les >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
