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

Christian Hopps <chopps@chopps.org> Tue, 15 May 2018 15:08 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 EE5B912D889 for <lsr@ietfa.amsl.com>; Tue, 15 May 2018 08:08:00 -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 Bkks3Djbx7fy for <lsr@ietfa.amsl.com>; Tue, 15 May 2018 08:07:58 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 989C012D942 for <lsr@ietf.org>; Tue, 15 May 2018 08:07:58 -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 A2D8D61196; Tue, 15 May 2018 15:07:57 +0000 (UTC)
References: <152599973361.10651.12984126140632073221@ietfa.amsl.com> <a1522cde71f94291b49eedde5f48a468@XCH-ALN-001.cisco.com> <87mux1wb7p.fsf@chopps.org> <3fed98c8adef445e94df465e78e265f7@XCH-ALN-001.cisco.com>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps <chopps@chopps.org>
To: "Les Ginsberg \(ginsberg\)" <ginsberg@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, "lsr\@ietf.org" <lsr@ietf.org>
In-reply-to: <3fed98c8adef445e94df465e78e265f7@XCH-ALN-001.cisco.com>
Date: Tue, 15 May 2018 11:07:56 -0400
Message-ID: <874lj9c5yr.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/pU04gbN6l-3jTIHEq3ZRIEm7EhE>
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 15:08:01 -0000

Les Ginsberg (ginsberg) <ginsberg@cisco.com> writes:

> Chris -
>
>> 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. :)
>
> [Les:] In both sections the draft says (emphasis added):
>
> "Value: field consists of one or more pairs of a 1 octet MSD-Type
>    (IANA Registry) and 1 octet Value.
>
> Why do you see this as unclear?

Let me come at this a different way:

    Type -- specified: 23
    Value -- specified: pairs of MSD type and MSD values.
    MSD-Type  -- *unspecified*
    MSD-Value -- specified "the MSD value is a number ..."

One might could infer after looking at the *current* registry that the only valid value could be:

    Type: 1 -- Base MPLS Imposition MSD

However, the text also doesn't even use "Base MPLS Imposition MSD" to describe the MSD value here (it talks about this in later sections), so I'd say it's under-specified at this point.

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? That's would be surprising enough that I think it would need to be made explicit.

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".

Note: this comment refers to both the Node and Link sub-TLVs.

>> 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?

> 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.

Thanks,
Chris.