Deborah -
Thanx for your review. Responses inline. > -----Original Message----- > From: Deborah Brungard via Datatracker <[email protected]> > Sent: Wednesday, June 10, 2020 3:17 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; Acee > Lindem (acee) <[email protected]>; [email protected]; Acee Lindem > (acee) <[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 > 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/ > > > > ---------------------------------------------------------------------- > 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
