Hi Les, I am not sure I am following you.
As per the abstract in draft-hegde-isis-advertising-te-protocols, all I am talking about is "a mechanism to indicate which traffic engineering protocols are enabled on a link in IS-IS." At this stage, are you questioning the relevance of the poll to the IS-IS WG? (In case we really had considered another WG for this I-D, we would certainly have ended up in TEAS, not in CCAMP nor MPLS). In case mentioning the node counterpart is confusing, please ignore RFC 5073. In case joining Chris B's open discussion about renaming the "TE protocol sub-TLV" is not obvious, please do not consider that as a prerequisite to adopt the I-D. You suggest RFC 5029 as a candidate solution for draft-hegde-isis-advertising-te-protocols (section 3). That would save us a sub-TLV codepoint and leave us 14 bits instead of 32. This looks like a reasonable way forward to me. By the way, the suggested value for the sub-TLV in draft-hegde-isis-advertising-te-protocols is already allocated! Shraddha/Chris, could you please drop suggested codepoints from the I-D? Thanks, Julien Oct. 21, 2017 - [email protected]: > Julien - > > I think the issue you raise first needs to be discussed in CCAMP (or perhaps > MPLS) WG. If there is agreement that this is a problem which needs to be > addressed then a draft can be written. Perhaps this is RFC 5073bis - perhaps > something else. > > As far as link level signaling, in IS-IS there is already provision for that > using link attributes sub-TLV defined in RFC 5029: > https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-19of22 > If signaling is required to address the issue you raise that would be the > most appropriate place to do it. > > I don't think your issue is in scope for either > draft-hegde-isis-advertising-te-protocols or draft-ietf-isis-te-app. > > Les > > >> -----Original Message----- >> From: Isis-wg [mailto:[email protected]] On Behalf Of Julien Meuric >> Sent: Friday, October 20, 2017 7:15 AM >> >> Hi, >> >> I support the adoption of draft-hegde-isis-advertising-te-protocols as a >> foundation for a WG item. A per-link "Capability sub-TLV" (the term >> "protocol" might be too specific here) really adds a missing piece after RFC >> 5073. >> >> Once WG document, we may discuss an additional use case suggested by >> that RFC: on top of RSVP-TE support, distinguish between 3209-only and >> 3473-capable. Indeed, there are parameters like SRLGs that were defined as >> part of GMPLS extensions: an implementation (wildly) guessing RFC >> 3473 support from that would not be fully wrong. Similarly, an >> implementation may perfectly support 3473 even if it has not explicitly >> advertise a PSC switching capability on a given link. Let us make these >> explicit! >> >> My 2 cents, >> >> Julien >> >> >> Oct. 07, 2017 - Christian Hopps: >>> Hi Folks, >>> >>> The authors have requested the IS-IS WG adopt >>> >>> >>> https://datatracker.ietf.org/doc/draft-hegde-isis-advertising-te-proto >>> cols/ >>> >>> 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. >>> >>> >>> _______________________________________________ >>> Isis-wg mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/isis-wg >> >> _______________________________________________ >> Isis-wg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
