Julien - I point out the newly added Section 6 in https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/ . If you have not read this new section please do so. It may help explain why I think draft-hegde-isis-advertising-te-protocols is unneeded.
As regards advertising RFC 3473 support and/or other RSVP related capabilities, my opinion is unchanged. This first needs to be discussed in the appropriate WG (teas, ccamp, mpls - I leave that to yourself and others to choose) so that consensus on this requirement is first established. Then, if needed, an appropriate way to advertise this support (both in IS-IS and OSPF) would be defined. But IMO this does not belong in either of the two drafts mentioned above. I understand that you may still disagree. Les > -----Original Message----- > From: Julien Meuric [mailto:[email protected]] > Sent: Wednesday, October 25, 2017 7:38 AM > To: Les Ginsberg (ginsberg) <[email protected]> > Cc: [email protected] > Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- > protocols > > Hi Les, > > My original post was discussing two parallel items: > - my unconditional support to the adoption of draft-hegde-isis-advertising- > te-protocols (irrespective of the decision about my following proposal), > - a candidate use case, to be discussed "once WG document". > > For clarification, let me try to summarize the open questions: > > 1- Do we need to advertise RFC 3473 support on a per link basis? > You seem to argue that combining RSVP link advertisement and 3473 support > as a node advertisement (RFC 5073) may address the issue. Fair enough, > provided implementations do support all necessary TLVs. > [Otherwise, collocated bits are not a big deal: RFC 5073 did not block on a > "qualitative" boundary between the M bit and the G bit.] > > 2- Should we restrain ourselves from improving an in-progress specification > where presence/absence of advertisement imply a support that "depends > upon the application"? > You say yes, I say no (you say goodbye...). Application-specific semantics are > an error-prone way to convey a basic binary information. > [To map it onto the example above, combining advertisement with > application-specific semantics before linking it to a barely implemented > node-related TLV would clearly limit the number of implementations actually > able to identify if a 3473-compliant RSVP message can be sent to control a > given link.] > > 3- When the poll in progress concludes, if the rough consensus on "2" > favors explicit capability advertisement, what solution should we progress? > The more I think about it, the more I believe that requesting a flag > allocation > (e.g. 0x04) from sub-TLV 19 (created by RFC 5029) deserves to be considered > as part of the solution space for draft-hegde-isis-advertising-te-protocols. > > Cheers, > > Julien > > > Oct. 23, 2017 - [email protected]: > > Julien - > > > > My position on WG adoption of draft-hegde-isis-advertising-te-protocols > (opposed) and the reasons why have been stated in an earlier post to the > list. > > > > draft-hegde-isis-advertising-te-protocols is discussing how to signal > whether an application which makes use of link attribute advertisements is > enabled on a link. For the purposes of this discussion the application is > specifically RSVP. > > > > Your post is discussing a quite different thing. Given that RSVP is enabled > you are asking/suggesting that we might want to also signal certain specific > capabilities of RSVP - which is a qualitatively different thing. > > I believe that is out of scope for draft-hegde-isis-advertising-te-protocols > (and draft-ietf-isis-te-app). > > > > Les > > > > > >> -----Original Message----- > >> From: Julien Meuric [mailto:[email protected]] > >> Sent: Monday, October 23, 2017 5:16 AM > >> > >> 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-codepo > >>> in > >>> ts.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-p > >>>>> ro > >>>>> to > >>>>> 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
