Bruno, Thanks for expressing support for WG adoption, and for the comments.
The comments are addressed in-line with [CB]. Chris -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Monday, October 9, 2017 9:25 AM To: Christian Hopps <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: RE: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te-protocols 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" ======= [CB] That makes sense. A better name might be "Protocol Enablement sub-TLV", but I am interested in other naming suggestions as well. ======= 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) ========== [CB] These are good points. At this point, the authors have identified the one use case described in section 3.2. It would be useful to understand if there are other use cases from the rest of the working group. I am certainly open to refinements or modifications of the SR flag as the working group sees fit. With respect to MPLS SR and SRv6, the current intention of the text is MPLS SR when referring to the SR flag. However, we will make this clearer in the next revision of the text. ========== 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) =========== [CB] Below is proposed text to make this point crystal clear. "When traffic engineering extensions were first defined, the primary consumers of link attributes were RSVP-based applications that use the link information to compute paths which were subsequently signaled using RSVP-TE. Over time, these link attributes have been used by non RSVP-TE applications, such as IP/LDP fast-reroute using loop-free alternates as described in [RFC7916]. More recently, applications based on Segment Routing [I-D.ietf-spring-segment-routing] have started to make use of these link attributes. In order to remove any ambiguity about the status of non RSVP-TE uses of TE link attributes, the current document makes the following normative statement. Existing and future traffic engineering link attributes MAY be used by non RSVP-TE applications." ============ 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dprotocols_&d=DwIFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=mIF18ha_B3lsg_QPPZ0uZE5Mp5Q7LXQIPJHrP9QhvL4&m=S0MISL1PhJdVSGSOkWSRY-tyTlkaOS4u6Zs82okra40&s=baaIDeBkWxThZOMBrijUmD9F1EocY9lBoGkN9xlS5RY&e= > > 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
