Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (with DISCUSS and COMMENT)

Alvaro Retana <> Wed, 23 January 2019 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2BC0130F33; Wed, 23 Jan 2019 13:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DZxNf-noRvUy; Wed, 23 Jan 2019 13:52:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::334]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7D59D130F30; Wed, 23 Jan 2019 13:52:59 -0800 (PST)
Received: by with SMTP id e12so3388642otl.5; Wed, 23 Jan 2019 13:52:59 -0800 (PST)
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=/P1uyAWRTPjGyRNcZlaT6RNEphVuk/YNZdrc/GIRwWE=; b=Ic5TestWe+FofN1hQnz5ZZVMT1doJWN6OknbvQi4jP8EYFygYvL6ZS84HVM2ZymKtU uF6ZQ3xrtBQMXiDvEkdoqKeA2no+VuOa5RH+YA1TFPzds5yEGPttNEh3J2MvHwlO+3jC mimHSjxa+YhHP8vXN9YXPLY1Nf8cV/OzeLW8JPZAMI9fXq846kL4IeMx9EwNJAgyff04 s82LGP6OachX4q5J6ov+F4xeh+4lkIY/V2jVLpSVmW28b6rU3fojCCkTHKyhxoEMBfqp 8m42LZjRLJpgpp8mrPvyAMaBreCjVukFMshmEU5orMA5LlB09Ylc+Ret5dIqprxXmhUK idlA==
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=/P1uyAWRTPjGyRNcZlaT6RNEphVuk/YNZdrc/GIRwWE=; b=orApXmexSSapgC5udQuHMi6LKSempmpqKp4uxR0uylWcNTocDXZpWixg7KQ2Ln/Ivi rQmIzcgKNEDhp2j1YbiZVxoNR+KwuiRjdu4JQ75d+bKoQPX5Ls9mfpE6Fvtz0ubgvQTm NDijEM4EmbYc47ItgD8E8H/9iiG+kJxjcMKDxqV+6wBkJF3iy4+RKtVmSiRwaBzrSnPq 6wkVZfQ6Uk2obEXzXTDUcf5ACXBX/tlGwfQegTDUsguv8/NdJPtF27QJdNxMONMV0b6E 9j9Uh9L3GTd/LU51Lo0FvhYZ/NlhaJJUmdKUUEVqUvbXowj17AZMdkuZBe/enrM3NvqJ GIMQ==
X-Gm-Message-State: AJcUukdvWTxMSTFCyBD1ib7g3Ws+MWgwiM2YC0O8Lwzt/nsEak3WDR+h 6nx1L+kkk+4OEwku/vKpTA7OPcnfWCASi0RKFGs=
X-Google-Smtp-Source: ALg8bN6xAmJlzyQZdA777n6DQOnHQno1ZWqe8JEFd/ncpdH+Syga37E2JdTUUY08TQI3WAYf5u/fqsdH0eFDpjP4IZ4=
X-Received: by 2002:a9d:694a:: with SMTP id p10mr2780629oto.44.1548280378728; Wed, 23 Jan 2019 13:52:58 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 23 Jan 2019 13:52:58 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Date: Wed, 23 Jan 2019 13:52:58 -0800
Message-ID: <>
To: Vishnu Pavan Beeram <>
Cc:, IETF MPLS List <>,, The IESG <>
Content-Type: multipart/alternative; boundary="000000000000fcabb50580271d8a"
Archived-At: <>
Subject: Re: [mpls] Alvaro Retana's Discuss on draft-ietf-mpls-rsvp-shared-labels-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Jan 2019 21:53:02 -0000

On January 18, 2019 at 8:43:42 AM, Vishnu Pavan Beeram ( wrote:



We just uploaded a new rev (-08) for this draft. Please do go through the
diffs (
and let us know if all your comments have been addressed.

No, not completely.  See below.

>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> A significant portion of this specification depends on knowing the label
>>> stack
>>> depth limits in the network, but §5.2 declares the mechanism out of
>>> scope:
>>>    In order to accurately pick
>>>    the delegation hops, the ingress needs to be aware of the label stack
>>>    depth push limit of each of the transit LSRs prior to initiating the
>>>    signaling sequence.  The mechanism by which the ingress or controller
>>>    (hosting the path computation element) learns this information is
>>>    outside the scope of this document.
>>> I think that not defining the mechanism in this document is ok -- but not
>>> having one means that important parts of this specification can't work.
>>> Please
>>> point at where such a mechanism is specified, or at least provide
>>> examples.
>>> The Shepherd's writeup says that "implementation plans and
>>> implementations" are
>>> known so I think that this should be an easy point to address.
>> [VPB] The specification discusses a couple of delegation options -- the
>> explicit delegation option (Section 5.2) and the automatic delegation
>> option (Section 5.3). The explicit delegation option is the only one that
>> needs the ingress or the controller to be aware of the label stack depth
>> push limit of each of the transit LSRs prior to signaling. This information
>> is not needed when the automatic delegation option is employed -- the
>> limitations of each transit node are taken into account while picking the
>> delegation hops during the initial signaling sequence.
>> For the explicit delegation option, an implementation may choose to
>> employ any of the following mechanisms to learn the label stack depth push
>> limit of each LSR in the network --  ISIS (RFC8491), OSPF (RFC8476),
>> BGP-LS (draft-ietf-idr-bgp-ls-segment-routing-msd), PCEP
>> (draft-ietf-pce-segment-routing), local config (just set a global limit),
>> netconf/restconf/grpc using the data-model specified in
>> draft-ietf-teas-yang-sr-te-topo.
>> Please see if the addition of the following statement to the end of the
>> first paragraph in Section 5.2 addresses your concern:
>> "Examples of such a mechanism are specified in RFC8491 and RFC8476."
>> These are fine examples, and they would satisfy the point above.
>> However, they raise an additional one.  rfc8491 has a very specific
>> definition of what the Base MPLS Imposition MSD is, but that definition may
>> not match what is discussed here.  The intent may be the same, but the text
>> is different, and given the extensive discussion prior to the publication
>> of rfc8491, I want to make sure that we are in fact talking about the same
>> thing: "label stack depth push limit” doesn’t directly map to "the total
>> number of MPLS labels that can be imposed, including all
>> service/transport/special labels” [rfc8491].  I note that this document
>> specifically mentions just transport labels.
>> If the definition of the BMI-MSD is what is expected in this document,
>> please explicitly say so.  If not, then I think that we would need to
>> define a new MSD-Type for the suggestions above to be applicable.
> [Pavan] The “label stack depth push limit” is the same as what is referred
> to as the BMI-MSD in RFC8491. We will make that explicit.

I see no place in the text where the relationship to the BMI-MSD is
explicitly made.

I see the text (in parenthesis) that you added in §5.3: "label stack depth
push limit (number of MPLS labels that can be imposed)”, but that doesn’t
make reference to either the BMI-MSD or rfc8491.  Also, the text added is
not the complete definition.  All this would make rfc8491 a Normative