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

Alvaro Retana <> Thu, 27 September 2018 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 83CB3130EF0; Thu, 27 Sep 2018 10:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Status: No, score=-1.737 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OWCUurAJ0IMv; Thu, 27 Sep 2018 10:54:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B38F8130EEC; Thu, 27 Sep 2018 10:54:04 -0700 (PDT)
Received: by with SMTP id i12-v6so3458004otl.1; Thu, 27 Sep 2018 10:54:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=rHs/E1jjvsE9gVDLcbcM052l/3ae8Cj6ygyv5s38rE8=; b=Lu1HYx3Cwzy3MSoitZo0FUdrkYF9BHTbz30ZaXg+8JakSdXDNJiujWs1E0PlSeHWRu /aAIlX1fHAhNxoLPHUJ1ksJ9lsCD/3won/+N8gnODvMiLKh60jpfWVD7XDanq5399WnD knReoXjr5tZzdasJCZBIa5YnCa0vBu/zO5mtP0P5lMP6aSDho/ScqG7kKdD1aRXkW77h PCZwqHdXurjelPurgxNJ+ggTJ5q5rN+HDuJyNQAzlkYoX3jFZuDT/mhBK3TEZBGEbhkZ 531LwlEYMMgzcbLWpUhyXTg3d2ooF9pscSHshYxAYr/I40JJAyXDgSKqFs/PNa4UDbUj 2jig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=rHs/E1jjvsE9gVDLcbcM052l/3ae8Cj6ygyv5s38rE8=; b=nHp2h7iPe9nDWQP93gRd0vezMcTu6GElLDVYrX+G6WhWSP8E7XzGfYGg00A+VJtKdl BDc8VKWawaOBO3PzX58GBXWdiZes/IT7gxeFNtrY2rS00qnRRxtJTnHqhMaFBKbn3PPE QtVgUmZeMypkTCFUzKKCwnG/dWYgPm9aM4BVc6mK0VA9mryA0CSbc3FsBLhhsqe2KzHM 8wyPV7LycThtUI0kw0T6wTrgRXAuFdai/Py+ZI5j9rHW1RY7svbFydiAgTIoargOYza8 xN9g084udaqKWALU52F3djpMkMCbeEGjxggES1o6Rkd8VnPqMdWFYDKQ2IxlyXdCdIGI ZmLg==
X-Gm-Message-State: ABuFfojgjIJt13lr8tzGMqKeUoY6r8bL9BRXSAKFER84ikU9ZKIyGmEf rOPpkSMdBrXl8dJQt4+9nL6hOf/TGFHD1+EBWmI=
X-Google-Smtp-Source: ACcGV63TffXMGaFCWLELdD10GoqK7eZtedRGWBDMxdmPSq5ZjcxQZi6UD2PWgkO32C5clxtFHfJRAh2rh6V85kZbtz8=
X-Received: by 2002:a9d:1552:: with SMTP id z18-v6mr7504848otz.44.1538070843931; Thu, 27 Sep 2018 10:54:03 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 27 Sep 2018 10:54:03 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Airmail (506)
MIME-Version: 1.0
Date: Thu, 27 Sep 2018 10:54:03 -0700
Message-ID: <>
To: Julien Meuric <>, "Les Ginsberg (ginsberg)" <>
Cc: "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000004ac10b0576de063a"
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:54:08 -0000

On September 27, 2018 at 6:26:57 AM, Julien Meuric (


It looks like the outstanding item is this one about the terminology used
in §5.

tl;dr: I think that the terminology can be slightly improved to be in line
with other documents.  See suggestion at the bottom.

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

The document currently (-17) reads:

   Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS
   labels which can be imposed, including all service/transport/special
   labels.  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.

   If the advertising router performs label imposition in the context of
   the ingress interface, it is not possible to meaningfully advertise
   per link values.  In such a case only the Node MSD SHOULD be

I think that the term “label imposition” is relatively well understood, as
the act of putting labels on the packet (labeling a packet).  However,
rfc3031 doesn’t talk about imposition; instead it says that a ""labeled
packet" is a packet into which a label has been encoded”, and it talks
about pushing labels on the stack.  The SR documents (rfc8402
and draft-ietf-spring-segment-routing-mpls) also don’t talk about
imposition, nor do they offer a better alternative.

The text may be interpreted from the point of view of what the LSR can
impose, vs what can be imposed on the packet…which can result in
confusion.  Note that §7 clarifies which node is expected to do the
imposition: "the head-end (the node performing the imposition)”.

rfc4221 does provide a clear precedent of the use of imposition, and a
related definition (referring to the LSR MIB / rfc3813):
"mplsMaxLabelStackDepth defines the maximum size of a imposed label stack
supported at this LSR”.  This definition is akin to what this document
already says: “MSD...the number of SIDs supported” (§1.1).  The definition
in rfc4221 also presents a subtle difference (from the text in this
document): it talks about the “imposed label stack supported” (not “labels
which can be imposed”).  I interpret the “imposed label stack” as already
taking into consideration any operations that can be performed (rfc3031).

My suggestion is to borrow from rfc4221 and simplify the definition:


   Base MPLS Imposition MSD (BMI-MSD) indicates the maximum size of an
   imposed label stack supported by the node.

   If it is not possible to meaningfully advertise
   per link values, then only the Node MSD SHOULD be

 In line with that suggestion, we could clean up some of the related text:

§1 s/the controller learns the Maximum SID Depth (MSD) that can be imposed
at each node/link/the controller learns the Maximum SID Depth (MSD)
supported at each node/link

§1 s/not exceed the number of SIDs the node is capable of imposing/not
exceed the number of SIDs the node is capable of supporting

§1.1: s/BMI: Base MPLS Imposition…/BMI: Base MPLS Imposition is the size of
the imposed label stack supported

Does this work?