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

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 16 May 2018 15:45 UTC

Return-Path: <ginsberg@cisco.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 11B2D129C6E for <lsr@ietfa.amsl.com>; Wed, 16 May 2018 08:45:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 zx0cKDq-UNJT for <lsr@ietfa.amsl.com>; Wed, 16 May 2018 08:45:31 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9150C127286 for <lsr@ietf.org>; Wed, 16 May 2018 08:45:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4706; q=dns/txt; s=iport; t=1526485531; x=1527695131; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BOtzp0VBry24AEFwwyOxU5v5RbLsyxkcFz7+SRI0qm4=; b=nJMFMVmqEY+sNrFQ5WF3bdP3EF2d7xlfb2wU33/UYXBLO+KvLcYsCrwa I0ZCqDY7/MbQ/V8xK65sSrk1upBfWQpAFSk3qOUTr0z/uJnvWBwlsf1av IEzECQfOLb/OI7UFa8qZ9u/wpt3MbRmgtH/HRQUCtv0GOF4mKV6VGMekc k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAABHUfxa/5tdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNDYX0oCotujHSBeYEPkzIUgWQLI4RJAoMfITQYAQIBAQE?= =?us-ascii?q?BAQECbBwMhSgBAQEEOjEODAQCAQgOAwQBAR8QMh0IAgQOBQiDHYF/D6x3iES?= =?us-ascii?q?CIgWIJ4FUP4EOAYMMgxEBAQIBgUU+hS4CmEEJAoVmiGOBP4Nqgl+Ed4lchms?= =?us-ascii?q?CERMBgSQBHDiBUnAVgn6CIBeIWYU+b411gRgBAQ?=
X-IronPort-AV: E=Sophos;i="5.49,406,1520899200"; d="scan'208";a="114868659"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2018 15:45:30 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w4GFjUm5002735 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 May 2018 15:45:30 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 16 May 2018 10:45:30 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1320.000; Wed, 16 May 2018 10:45:30 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Christian Hopps <chopps@chopps.org>
CC: "lsr@ietf.org" <lsr@ietf.org>, "Jeff Tantsura (jefftant.ietf@gmail.com)" <jefftant.ietf@gmail.com>
Thread-Topic: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
Thread-Index: AQHT6MH1PNOx0hOav0WV2ZODAthv3KQpspbwgAckVQCAAAhDAIAAYCEA///78FCAAHnGAIAA0iSQ
Date: Wed, 16 May 2018 15:45:30 +0000
Message-ID: <0f4286d4000a459994b4a0bdcbdcd44c@XCH-ALN-001.cisco.com>
References: <152599973361.10651.12984126140632073221@ietfa.amsl.com> <a1522cde71f94291b49eedde5f48a468@XCH-ALN-001.cisco.com> <87mux1wb7p.fsf@chopps.org> <3fed98c8adef445e94df465e78e265f7@XCH-ALN-001.cisco.com> <874lj9c5yr.fsf@chopps.org> <a37d6ba6cd11437c87d3ffecd7f20d17@XCH-ALN-001.cisco.com> <87zi10vaet.fsf@chopps.org>
In-Reply-To: <87zi10vaet.fsf@chopps.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.63.47]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/u25BCVRTVU3_K6-E7jPucXzpkPs>
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: Wed, 16 May 2018 15:45:34 -0000

Chris -

V12 of the IS-IS Draft has just been posted. I believe this addresses your concerns.

In addition, Jeff and I have discussed and a new version of OSPF draft will be posted shortly which:

1)Removes the confusing text in Sections 2 and 3.
2)References the registry which is defined in the IS-IS document.

WG chairs please do what is necessary when progressing the documents so that the registry creation and reference to it do not become blocking items.

I hope this addresses all issues you have raised - but if not be sure to let us know. :-)

   Les


> -----Original Message-----
> From: Christian Hopps <chopps@chopps.org>
> Sent: Tuesday, May 15, 2018 3:09 PM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: Christian Hopps <chopps@chopps.org>rg>; lsr@ietf.org
> Subject: Re: [Lsr] I-D Action: draft-ietf-isis-segment-routing-msd-11.txt
> 
> 
> Les Ginsberg (ginsberg) <ginsberg@cisco.com> writes:
> 
> > Chris -
> >
> >> Or is it in fact the case that you are saying that no matter what the
> >> MSD-Type is the MSD value will always be as defined currently in sections
> 2 and 3?
> 
> > [Les:] Correct
> 
> >> That's would be surprising enough that I think it would need to be
> >> made explicit.
> 
> > [Les:] It is made explicit. Your expectation that this section is in any way
> specific to a particular MSD type is quite surprising.
> 
> Given the text in the OSPF document specifies the type, is the most recently
> updated of the 2 documents, and I've mentioned is the reason I'm bringing
> this discrepancy up, it is surprising that you find my surprise surprising. :)
> 
> Would you be amenable to change the text (and similarly the link section) to
> read,
> 
>     "The Node MSD value is a number in the range of 0-255. *Regardless of
> MSD type*, 0 represents lack of the ability to support SID stack of any depth;
> any other value represents that of the node. This value MUST represent the
> lowest value supported by any link configured for use by the advertising IS-IS
> instance."
> 
> Honestly, I don't know why you want to define such specific semantics (no
> subset of links ever?) for this and all future MSD types, but your more the
> expert on this technology and perhaps no other meaning for the values could
> ever make any sense.
> 
> >> FWIW, I noticed this by doing a diff so here's the OSPF text:
> >>
> >>    "MSD Type 1 (IANA Section), MSD and the Value field contains the MSD
> >>    of the originating router.  Node MSD is a number in the range of
> >>    0-255. 0 represents lack of the ability to impose MSD stack of any
> >>    depth; any other value represents that of the node.  This value
> >>    SHOULD represent the minimum value supported by a node."
> >>
> >> That text looks a bit off too ("MSD and the Value field"?), but at
> >> least its saying the MSD type is "1".
> >
> > [Les:] And it should not. OSPF draft section 5 define BMI-MSD - which is
> assigned codepoint 1.
> > The phrase " MSD Type 1 (IANA Section)" should be removed.
> 
> OK good then.
> 
> >> Note: this comment refers to both the Node and Link sub-TLVs.
> >>
> > [Les:] On this we agree. :-)
> >
> >> >> 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.
> >> >
> >> > [Les:] MSD inherits the procedures defined in
> >> https://tools.ietf.org/html/rfc7981#section-3 .
> >> >
> >> > There is therefore no need for further specification.
> >>
> >> Well that might cover the Node TLV, but not the Link TLV, right?
> >>
> > [Les:] OK - we can add text to cover this point as regards Link sub-TLV.
> >
> >> > The meaning of "one allowed" is not the same in IS-IS. Clearly
> >> > multiple MSD
> >> sub-TLVs are allowed since there are 255 possible MSD types and they
> >> would not all fit into a single sub-TLV.
> >>
> >> The main point I'm making here is that the OSPF document goes out of
> >> it's way to be explicit about multiple values not being allowed, the
> >> IS-IS document leaves this unspecified.
> >
> > [Les:] If you have a problem with this, please take it up in the context of
> RFC 7981.
> > No one has objected to that definition and it has been in place since 2006.
> 
> I did say that Node TLV was OK above so I'm not sure what further problem
> you think I might have with RFC 7981, in any case I don't. :)
> 
> Thanks,
> Chris.
> 
> >    Les