Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15

"Les Ginsberg (ginsberg)" <> Thu, 27 September 2018 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B812130EE9; Thu, 27 Sep 2018 10:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oiSmZ5pFf3Oa; Thu, 27 Sep 2018 10:45:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3046130E30; Thu, 27 Sep 2018 10:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=29650; q=dns/txt; s=iport; t=1538070316; x=1539279916; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XvY6K14bn0M43IzBp5lNddYXm5M9BWpenSXJFcspwbg=; b=U/i7HkzpFqq0HhWPim2d4EUOqTJ+Ea++qKlXXLiDNBrvf9AzXcCo5mol Pq+7Tbi4mWhhjPg8h8T/D7GViz3IMocwKa+zWxBUo52TOGp//w4dy5ypJ 0m/YgdxGILMo0DDc2lHv9KXb9tThQJAQ4g5WeGt+kj3Xt4YBmecV3+VW7 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAADtFK1b/5hdJa1bGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUYEXd2Z/KAqDaogVjj+WUhSBZguEbAIXg3AhNBgBAwE?= =?us-ascii?q?BAgEBAm0ohTgBAQEBAgEjCkwFBwQCAQYCEQEDAQEWFQICAjAXBggCBAENBQi?= =?us-ascii?q?DGoEdXAiIN5tNgS6KDop+F4FBP4ESghR+hDkJJFeCQoJXAognhUkThWaJKAk?= =?us-ascii?q?CiUyGWB+BR4RWiR2UcwIRFIElHTiBVXAVGoMNgiUXjhhvjRKBHwEB?=
X-IronPort-AV: E=Sophos;i="5.54,311,1534809600"; d="scan'208,217";a="177722487"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Sep 2018 17:45:14 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id w8RHjEGe028169 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Sep 2018 17:45:14 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 27 Sep 2018 12:45:13 -0500
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Thu, 27 Sep 2018 12:45:13 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Julien Meuric <>, "" <>
CC: "" <>, "" <>, "" <>
Thread-Topic: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15
Thread-Index: AQHUSRr9GtZ+0d9dH0WUMIG4HP6jZqT++7dQgAD3yQCAAyVlkIABQdiAgAAhGwA=
Date: Thu, 27 Sep 2018 17:45:13 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5bd3a665544946e28bcf5785856f0ce8XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Lsr] [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Sep 2018 17:45:20 -0000

Julien -

Snipping out the resolved bits.

> -----Original Message-----

> From: Julien Meuric <>;

> Sent: Thursday, September 27, 2018 3:27 AM

> To: Les Ginsberg (ginsberg) <>;;

> Cc:;; draft-ietf-isis-segment-routing-


> Subject: Re: [RTG-DIR] RtgDir Review: draft-ietf-isis-segment-routing-msd-15


> Hi Les,


> Please see inline.


> Thank you,


> Julien



> >>>>

> >>>> - OLD

> >>>>    Path Computation Element Protocol (PCEP) SR extensions draft

> >>>>    [I-D.ietf-pce-segment-routing] signals MSD in SR Path

> >>>> Computation

> >>>>    Element (PCE) Capability TLV and METRIC Object.

> >>>>   NEW

> >>>>    The Path Computation Element communication Protocol (PCEP) SR

> >>>>    extension document [I-D.ietf-pce-segment-routing] defines how to

> >>>>    signal MSD using the SR-PCE-CAPABILITY sub-TLV (per node) and

> >>>>    the METRIC object (per request).

> >>>>

> >>> [Les:] I have updated this and included a reference to RFC 5440

> >>> where

> >> METRIC object was first defined.

> >>>

> >> [JM] Even better about METRIC. Consistently, "SR Path Computation

> >> Element

> >> (PCE) Capability TLV" still remains a loose phrase, the technical

> >> name from [I- D.ietf-pce-segment-routing] is "SR-PCE-CAPABILITY",

> >> which avoids ambiguity.

> >>

> >

> > [Les2:] I removed naming the specific TLVs and replaced it with " Path

> Computation Element Protocol (PCEP)".

> > I think this is better than mentioning specific TLV names - particularly since

> one of them is part of a draft and the TLV name might change before the

> document becomes an RFC. So any possible naming inconsistency is now

> eliminated.

> >

> [JM2] As there's an early IANA allocation on this TLV, I don't expect any

> change in its name, but I can hear that argument. If you want a full phrase,

> then I prefer the text from v16, because "SR Path Computation Element

> (PCE) Capability" matches the section title of the PCEP draft (and a slight

> change later wouldn't have much impact). In case you're into removing the

> TLV/objects names and just point to PCEP, then you MUST use the full

> expansion which is "Path Computation Element

> *communication* Protocol" (and SHOULD avoid asking about the missing C

> ;-) ).

[Les:] I don't really care, but I am having trouble with your suggestion.

IT is true that RFC 5440 is entitled:  "Path Computation Element (PCE) Communication Protocol (PCEP)"

However, in the body of the RFC we see

"This document specifies the Path Computation Element Protocol (PCEP)".

Also, in draft-ietf-pce-segment-routing-12 we also see

"[RFC5440] describes the Path Computation Element Protocol (PCEP) ..."

So explain to me why this document should deviate from these other PCE oriented documents???

> >>>> - In section 5, BMI-MSD is defined as "the total number of MPLS

> >>>> labels which can be imposed" (which is OK when the incoming packet

> >>>> is unlabled). When the incoming packet is labeled (e.g. use of

> >>>> segment routing binding SID), if the incoming label is to be

> >>>> "replaced" by N outgoing labels, what processing model is assumed

> >>>> when advertising the

> >> MSD:

> >>>>  * one swap and one imposition of N-1 labels?

> >>>>  * one pop and one imposition of N labels?

> >>>>

> >>> [Les:] What is being defined is the maximum number of SIDs/labels

> >>> which

> >> can be "imposed". If popping or swapping affects the MSD which can be

> >> supported this needs to be accounted for in the advertisement.

> >> BMI-MSD is not being used to advertise a value specific to labeled or

> >> unlabeled packets nor a value which is "swap specific" or "pop specific".

> >>>

> >> [JM] We seem to agree on an architecture-agnostic use of BMI-MSD. "If

> >> popping or swapping affects the MSD [...] this needs to be accounted

> >> for" is a great introduction to the issue and deserves to be included

> >> in the I-D. My comment now binds to: in order to have interoperable

> >> implementations, I believe the document should be more prescriptive

> >> on how we account that for.

> >>

> > [Les2:] Added text

> >

> [JM2] Thanks, this is a significant improvement. After talking to Bruno, we

> however feel that the proposed wording remains ambiguous, and especially

> the phrases "imposed under all conditions" and "be accounted for". Indeed,

> section 3.10 of RFC 3031 defines "the operation to perform on the packet's

> label stack" and doesn't mention "impose". The closest concept may be

> found in:

> "        replace the label at the top of the label stack with a

>          specified new label, and then push one or more specified new

>          labels onto the label stack."

> Combining this split to your current text may lead to different

> interpretations. Could you clarify the paragraph to be more specific on the

> corresponding definitions and fully clear the fuzzy zone?


[Les:] I am trying to understand exactly what is desired here.

It seems you do not like the term “impose/imposition” – which affects other places in the draft. I appreciate that RFC 3031 does not use the term “impose”. However the usage here is not to formally define a specific MPLS operation but to use a generic term which covers all the flavors of MPLS operations (swap, pop, push).

I can eliminate perhaps some of the “fuzziness” by:


“The value advertised MUST indicate what can be imposed under

   all conditions e.g., if label popping/swapping affects the number of

   labels which can be imposed this MUST be accounted for in the value

   which is advertised.”


“The value advertised MUST indicate the lowest maximum number of labels which  can be imposed under

   all conditions e.g., if label popping/swapping reduces the maximum number of

   labels which can be imposed this lower number MUST be what is advertised.”

But I suspect this does not address all of your concerns.