Julien, Perhaps what is needed is an MPLS/GMPLS capabilities advertisement which lists explicitly what are the advertising node's capabilities. I seem to remember some work years ago regarding the migration from MPLS to GMPLS and their attendant coexistence, and that might be useful as a starting point.
I am copying Adrian and Lou w/ the expectation that their memories are better than mine. Yours Irrespectively, John > -----Original Message----- > From: Isis-wg [mailto:[email protected]] On Behalf Of Les Ginsberg > (ginsberg) > Sent: Wednesday, October 25, 2017 2:45 PM > To: Julien Meuric <[email protected]> > Cc: [email protected] > Subject: Re: [Isis-wg] WG Adoption poll for draft-hegde-isis-advertising-te- > protocols > > Julien - > > I point out the newly added Section 6 in > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Disis-2Dte- > 2Dapp_&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0R > FNJ-Y&s=iiYJ0nRe9SlDwIoqwDZMGaiHCU4VYT_QsXyoGhaKOJc&e= . > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_ > > >>> assignments_isis-2Dtlv-2Dcodepoints_isis-2Dtlv- > 2Dcodepo&d=DwICAg&c > > >>> =HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LG > > >>> hEWH- > s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0R > F > > >>> NJ-Y&s=j3pCfLzDhjBl4INO9pPA-Ml_3plUlQfcL_Nln7apnbk&e= > > >>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker > > >>>>> .ietf.org_doc_draft-2Dhegde-2Disis-2Dadvertising-2Dte-2Dp&d=DwIC > > >>>>> Ag&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CRB2tJiQePk0c > > >>>>> T-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawl > > >>>>> v4L7W0RFNJ-Y&s=urLF6Ya-h-JyUcprEz- > 6Wi8Xa0TYy4wjOrn_Ek21tl8&e= > > >>>>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.or > > >>>>> g_mailman_listinfo_isis- > 2Dwg&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBX > > >>>>> eMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5V > > >>>>> E&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0RFNJ- > Y&s=0uBaEWzChU8vMa > > >>>>> X_gnFWcaHmV_ScWM7cZMZtSoIkgEI&e= > > >>>> > > >>>> _______________________________________________ > > >>>> Isis-wg mailing list > > >>>> [email protected] > > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org > > >>>> _mailman_listinfo_isis- > 2Dwg&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeM > > >>>> K-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m > > >>>> =vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0RFNJ- > Y&s=0uBaEWzChU8vMaX_gn > > >>>> FWcaHmV_ScWM7cZMZtSoIkgEI&e= > > >>> > _______________________________________________ > Isis-wg mailing list > [email protected] > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_mailman_listinfo_isis- > 2Dwg&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH- > s_xXXup3HzvBSMRj5VE&m=vRDDozQWVQuCQeQnNkzN6VSK3Plqawlv4L7W0R > FNJ-Y&s=0uBaEWzChU8vMaX_gnFWcaHmV_ScWM7cZMZtSoIkgEI&e= _______________________________________________ Isis-wg mailing list [email protected] https://www.ietf.org/mailman/listinfo/isis-wg
