Hi Chris, authors, all,
I support WG adoption of this document. This document provides explicit signaling for the support of RSVP-TE over a link and hence avoids implicit assumptions which may not be interoperable. Please find below some comments: 1) Traffic-engineering protocol sub-TLV I feel that a Flags field attached to links may be useful for multiple applications and usages. I would not limit the usage to TE, hence I would propose to use a more generic name. At least to avoid comment such as "you cannot use this field to advertise xx as xx is not TE" 2) Segment Routing flag Thanks for adding section 3.2 which is definitely needed. Although I can live with it, I'm still not convinced that we need such a SR flag. "The Segment Routing flag is set to zero to indicate that Segment Routing is not enabled on a link." What does "SR enabled on a link" means? - If the goal is to signal Network Operator policy, probably the use of link color (aka administrative groups) is the right tool. (while for RSVP-TE, this is a technical capability that a router may advertise by itself without network operator configuration) - If the goal is to signal that MPLS is not enabled on the link (layer) then may be it should renamed as MPLS flag, and could possibly be used more broadly. - Are there other cases? (a priori SR seems a node property rather than a link property) - Do you make a distinction between MPLS SR and SRv6? (SRv6 capability may be line card hence link dependent) 3) uses of TE info for non-RSVP-TE usages. " However, these traffic engineering link attributes have also been used by other applications, such as IP/LDP fast- reroute using loop-free alternates as described in [RFC7916]. In the future, it is likely that traffic engineering applications based on Segment Routing [I-D.ietf-spring-segment-routing] will also use these link attributes." Could this document make it crystal clear, using normative language, that existing and future TE link attributes may be used by non RSVP-TE applications? Otherwise, this document lose its motivation (as the presence of TE sub-TLV may be used to signal the presence of RSVP-TE) Thanks, Regards, --Bruno > -----Original Message----- > From: Isis-wg [mailto:[email protected]] On Behalf Of Christian Hopps > Sent: Saturday, October 07, 2017 4:43 AM > To: [email protected] > Cc: [email protected]; [email protected]; > [email protected] > Subject: [Isis-wg] WG Adoption poll for > draft-hegde-isis-advertising-te-protocols > > Hi Folks, > > The authors have requested the IS-IS WG adopt > > > https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-protocols/ > > as a working group document. Please indicate your support or no-support > for taking on this work. > > Authors: Please indicate your knowledge of any IPR related to this work > to the list as well. > > Thanks, > Chris & Hannes. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
