Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt

Christian Hopps <chopps@chopps.org> Tue, 15 May 2018 13:13 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C640212D7E6 for <lsr@ietfa.amsl.com>; Tue, 15 May 2018 06:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kdy-or74UeCn for <lsr@ietfa.amsl.com>; Tue, 15 May 2018 06:13:41 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 28AA8127775 for <lsr@ietf.org>; Tue, 15 May 2018 06:13:41 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id ECA4461197; Tue, 15 May 2018 13:13:39 +0000 (UTC)
References: <152599973361.10651.12984126140632073221@ietfa.amsl.com> <a1522cde71f94291b49eedde5f48a468@XCH-ALN-001.cisco.com> <87mux1wb7p.fsf@chopps.org> <5AFAA965.2020308@cisco.com> <A67AE315-81D8-4C4D-9AF3-3915BBE0808A@gmail.com>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps <chopps@chopps.org>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Peter Psenak <ppsenak@cisco.com>, Christian Hopps <chopps@chopps.org>, "Les Ginsberg \(ginsberg\)" <ginsberg@cisco.com>, "lsr\@ietf.org" <lsr@ietf.org>
In-reply-to: <A67AE315-81D8-4C4D-9AF3-3915BBE0808A@gmail.com>
Date: Tue, 15 May 2018 09:13:39 -0400
Message-ID: <87603pawos.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/SDknabm4NWrD6pUpw73uNnAg1iU>
Subject: Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 13:13:44 -0000

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 <jefftant.ietf@gmail.com> 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" <lsr-bounces@ietf.org on behalf of ppsenak@cisco.com> 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) <ginsberg@cisco.com> 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 <lsr-bounces@ietf.org> On Behalf Of internet-drafts@ietf.org
>     >>> Sent: Thursday, May 10, 2018 5:49 PM
>     >>> To: i-d-announce@ietf.org
>     >>> Cc: lsr@ietf.org
>     >>> 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
>     >>> Lsr@ietf.org
>     >>> https://www.ietf.org/mailman/listinfo/lsr
>     >>
>     >> _______________________________________________
>     >> Lsr mailing list
>     >> Lsr@ietf.org
>     >> https://www.ietf.org/mailman/listinfo/lsr
>     >
>     > _______________________________________________
>     > Lsr mailing list
>     > Lsr@ietf.org
>     > https://www.ietf.org/mailman/listinfo/lsr
>     > .
>     >
>
>     _______________________________________________
>     Lsr mailing list
>     Lsr@ietf.org
>     https://www.ietf.org/mailman/listinfo/lsr
>