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

Jeff Tantsura <jefftant.ietf@gmail.com> Tue, 15 May 2018 11:43 UTC

Return-Path: <jefftant.ietf@gmail.com>
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 0076612D958 for <lsr@ietfa.amsl.com>; Tue, 15 May 2018 04:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ug0KxY8DLTxX for <lsr@ietfa.amsl.com>; Tue, 15 May 2018 04:43:27 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B180127076 for <lsr@ietf.org>; Tue, 15 May 2018 04:43:27 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id j5-v6so465031wme.5 for <lsr@ietf.org>; Tue, 15 May 2018 04:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=E1Ktthn/Va/5FQ1TLzDS5EihDHMiLH60/QwavCTJxRI=; b=UHAmAnB/JpKvK4gHS9zADSssviC4s3nS2yojTOQiMBwq2/jFGlT6j+oAoqTmp3ixUl 0SyIbQ9Mv7djX59VVAQhz13gkjJ2SIKC1obhUHYGj0kIUSmiiB3MsCUTMFMRcuPHwnEx Fn4AGU78dXb1x2hkmp45CjYscPwm2k041JpfzhkxO+2WOzMCxj5tuHezvZqKieYCxIRQ bZjgMjK6l+kImMkC0jMsnhGGlQtAx+mWwKCJeFsuVCLrDUrFbkZ8xcCGhNUrWK8j2SbC M8+766af5JtX3uUycp7Z8GIVmTdFpdB9qeBk/Bxfzf1uCVO7T/Pn++rojwaofY267Hfq YFug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=E1Ktthn/Va/5FQ1TLzDS5EihDHMiLH60/QwavCTJxRI=; b=AOlgdsmvqmBHQn+DjiKtmetbmygkQdW34kdBUln8WIsnNpYsnBYrQHHIuNsngUCLDc L7yelIT02DmbGGnZECH3ZcO1WqTD7Dv7r3K3h/hrfhCV5fOFQocQ2LCpjbrzA9NSzgAN cko74VVJwuKE4XiiGIRvpQrMcNmTWSy04Eiui4lbxIfI914LrLeFjb4Ik/zhPl//QNhi +IDuWw3lpjVvd1HHn2HEYi2uykJBOYVz4a22bG2tVwrneMRrLs9/lK5PnOx1G7E3Mz3w P1kwYAtzNdl2PeVS9iP7OHl3tJH0WNs0c9TzBsTGNogyvs1l8r1QpcUwkIx+sYJYewD/ rDYg==
X-Gm-Message-State: ALKqPweWEOuSE9Mjzul1XIT6FcTktUVL3HWhuHrDT6kq7xyZ4y+xaWvo AxyXtOv/o86X8CXXTJLaKEY=
X-Google-Smtp-Source: AB8JxZol/7fxw0jb4mj7N4NwH6uNdH7IfQO6OL6nWe7zT/9ySi1NmkEYsngUDJOlhkal1Qs3OOOyVQ==
X-Received: by 2002:a1c:6e1e:: with SMTP id j30-v6mr7038293wmc.62.1526384605537; Tue, 15 May 2018 04:43:25 -0700 (PDT)
Received: from [193.0.26.160] ([2001:67c:64:42:70b0:5aee:25bb:9af3]) by smtp.gmail.com with ESMTPSA id h5-v6sm13380704wrm.37.2018.05.15.04.43.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 May 2018 04:43:24 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/10.c.0.180410
Date: Tue, 15 May 2018 13:43:23 +0200
From: Jeff Tantsura <jefftant.ietf@gmail.com>
To: Peter Psenak <ppsenak@cisco.com>, Christian Hopps <chopps@chopps.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "lsr@ietf.org" <lsr@ietf.org>
Message-ID: <A67AE315-81D8-4C4D-9AF3-3915BBE0808A@gmail.com>
Thread-Topic: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
References: <152599973361.10651.12984126140632073221@ietfa.amsl.com> <a1522cde71f94291b49eedde5f48a468@XCH-ALN-001.cisco.com> <87mux1wb7p.fsf@chopps.org> <5AFAA965.2020308@cisco.com>
In-Reply-To: <5AFAA965.2020308@cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/BUeT7RSoZDQUYZE6Sj3OUWKIvDM>
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 11:43:30 -0000

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