Please notice I raised 2 other issues outside of merging. If there will be a rev to the IS-IS document to deal with those then you could pull the registry definition from it and simply refer to the one defined by the OSPF document. We need to make sure that the OSPF document causes the registry to go to the IGP IANA page and not to OSPF though.
I'm fine with skipping the merging; however, them both being mostly encoding drafts doesn't preclude merging either. In fact all the rest of the text is /almost/ copy and paste, and repeating things in standards with slight differences is usually a bad idea. In this case though we're almost done so let's just finish the work and flex algorithm can be our first merged document instead. Thanks, Chris. Jeff Tantsura <[email protected]> writes:
Hi Chris, I don't see much value in merging, most of the content describes encodings which are different, per protocol, Wrt registry - please let us know which draft you'd want to request the new registry. Thanks! Cheers, Jeff On 5/15/18, 11:33, "Lsr on behalf of Peter Psenak" <[email protected] on behalf of [email protected]> wrote: Hi Chris, On 15/05/18 10:54 , Christian Hopps wrote: > > Hi Les, > > I was going over the 2 SR-MSD documents (IS-IS and OSPF) just wondering > how viable it would be and if we should combine them. > > In any case doing the diff highlighted a couple issues in the IS-IS > version. > > Issue: Under both the Node and Link sub-tlv's the MSD type (1?) is not > actually mentioned, only the "MSD value", if one was pedantic it would > mean that regardless of the type the value was always the same, > certainly not what is intended. :) > > Issue: The OSPF version adds text about what to do in the presence of > multiple instances of the same TLV. This highlighted the fact that the > IS-IS draft doesn't do this, but also doesn't talk about there only > being 1 allowed. > > Maybe Issue: We've got 2 drafts creating the same sub-[-sub]-tlv MSD > type registry. I fully agree that we should only have one registry, but > it's interesting that we'll have 2 publications that create and > reference it. Also, where does this registry go in IANA? There are > distinct IS-IS, OSPFv2 and OSPFv3 pages that contain the IANA registries > for each protocol. Should we create a new shared LSR or IGP page? Anyway > this might be a reason to combine the 2 documents. there is one already: https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml I agree that we need registry to be created in only one of the documents and have other reference it, unless we merge these two drafts. thanks, Peter > > While somewhat inelegant we could probably avoid any need to re-Last > Call if the combination was basically a cut and paste operation. > > Thanks, > Chris. > > Les Ginsberg (ginsberg) <[email protected]> writes: > >> This is a minor editorial revision to make the draft consistent w >> draft-ietf-ospf-segment-routing-msd-12. >> >> Les >> >>> -----Original Message----- >>> From: Lsr <[email protected]> On Behalf Of [email protected] >>> Sent: Thursday, May 10, 2018 5:49 PM >>> To: [email protected] >>> Cc: [email protected] >>> Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Link State Routing WG of the IETF. >>> >>> Title : Signaling MSD (Maximum SID Depth) using IS-IS >>> Authors : Jeff Tantsura >>> Uma Chunduri >>> Sam Aldrin >>> Les Ginsberg >>> Filename : draft-ietf-isis-segment-routing-msd-11.txt >>> Pages : 9 >>> Date : 2018-05-10 >>> >>> Abstract: >>> This document defines a way for an IS-IS Router to advertise multiple >>> types of supported Maximum SID Depths (MSDs) at node and/or link >>> granularity. Such advertisements allow entities (e.g., centralized >>> controllers) to determine whether a particular SID stack can be >>> supported in a given network. This document only defines one type of >>> MSD maximum label imposition, but defines an encoding that can >>> support other MSD types. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-msd/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-msd-11 >>> https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-msd- >>> >>> 11 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-msd-11 >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Lsr mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > . > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
