Re: [Teas] Comments on draft-ietf-mpls-rsvp-shared-labels

Vishnu Pavan Beeram <> Fri, 21 September 2018 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98FD5130E4B; Fri, 21 Sep 2018 15:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 VO8fVFtJQSNI; Fri, 21 Sep 2018 15:41:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 735A2130E4A; Fri, 21 Sep 2018 15:41:29 -0700 (PDT)
Received: by with SMTP id w14-v6so6545088plp.6; Fri, 21 Sep 2018 15:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iX+VDKiNMkkimkmDFjdrDOqFsHbNM9hPMKuB2CDae3c=; b=JfljR4qFCzCw9jIgPVDEBAo86wFwOqRGgH5gsW+ZAgzYPcxs+LAz4pgpuGGTcdG6lF UZySMhj/jSU211VQzUoPMMbHZr8QNRNTvKLb59gR8YGNHERW/46KOzMnZk7oJM33x7Ad ptUJnUYeLMqxN+sYiKEGgLD9MMrOs4cCCVNj+BNK9ZOK00hSfzTOwSxWpbyQJKndHhxo 6NPojDDBHUj+fyLMraWsZPZVUqRp2SauPiSjap0SPfq/lUN1Kwr7ayDZvrKyL3ZqD3TV bxb61buuLpmqHUyUsKuu5SBFOjwgubakXeF74EdFcVjAGitSLika7gZC3MiXoag4pQmz nTxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iX+VDKiNMkkimkmDFjdrDOqFsHbNM9hPMKuB2CDae3c=; b=QLYdAVxnvXkKgDf7xFShqMcwQePXZ/zk9xotQATRBPocSJGdB0c+BERzOz0S8VnVjP WhxnfexRqg79ZLMCKUkZtq0cAJqHNR3sck05HCWs+WKBqWpsqwG+4BY34LxpRWBkulK2 4cHZIOSOBvI1dzlaIhu3mxTOicmN3HNeOGfTdkG4Z5kQvSNlvMmPbohNfV24XsCsrOZx BtFiPoJIn4ZOLLcIbJHj1nbOreM4zeERN/jrlM12X9bgFpp7bCjcENYTjjuXE3m85Pev WDaKRE2Qj2pE5jElGXK/IrKxLNUhxIEvRg05sL0LV+3lYk7BGJHvHuk1oafy3p1gH1Se ueaQ==
X-Gm-Message-State: APzg51BKFQdutAxk+N0smBnpUJSR2v0uHzv2LpWIpE+CsyCv48LWtJN2 Jm5ywZBfqiye8u40QUmL0M6VpuNvOIIeVSwTAlE=
X-Google-Smtp-Source: ANB0VdYp1FV3CuqdiXO0PA6ig8wEqFTO5uqt5wON4afZKwzf+bZpoL8w8Qi+jlYD4QGNM7F3bWpzadeOrAS36ftY3hA=
X-Received: by 2002:a17:902:b81:: with SMTP id 1-v6mr46716396plr.319.1537569688946; Fri, 21 Sep 2018 15:41:28 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Vishnu Pavan Beeram <>
Date: Fri, 21 Sep 2018 18:41:16 -0400
Message-ID: <>
Cc:, IETF MPLS List <>, TEAS WG <>
Content-Type: multipart/alternative; boundary="000000000000208d1b057669578d"
Archived-At: <>
Subject: Re: [Teas] Comments on draft-ietf-mpls-rsvp-shared-labels
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Sep 2018 22:41:32 -0000

Matt, Hi!

Please see inline (prefixed Pavan).



On Fri, Sep 21, 2018 at 11:05 AM Matt Hartley <>

> Pavan,
> On Thu, Sep 20, 2018 at 7:16 PM Vishnu Pavan Beeram <>
> wrote:


>> Obviously none of this works unless you have label recording in the RRO.
>> That's requested in the session attribute flags (0x02). Should we add a
>> line to say that this MUST be set if you want to use shared labels?
> [VPB] Yes, it is obvious that label recording is mandatory. Please see the
> text in Section 9.2.
>    Bit Number 16 (Early allocation by IANA): TE Link Label
>    The presence of this in the LSP_ATTRIBUTES/LSP_REQUIRED_ATTRIBUTES
>    object of a Path message indicates that the ingress has requested/
>    mandated the use and *recording* of TE link labels at all hops along
>    the path of this LSP.
> Label recording is requested/mandated by setting the “TE Link Label” bit
> object of a Path message. So, even if a PATH message comes in without the
> 0x02 flag set in the SESSION_ATTRIBUTES object and with the above bit set
> in the Attribute Flags TLV, the implementation should treat it as a label
> recording request/mandate.
> This is fine if you're using an LSP_REQUIRED_ATTRIBUTES object, because a
> node that doesn't understand this will generate a Path-Error. But if you
> use LSP_ATTRIBUTES, you can't guarantee that every node along the path will
> have processed and understood this, and a node that doesn't process this
> won't know it should record labels in the RRO.
> Given that there seems to be a desire to use TE link labels in situations
> where not all nodes support this document, I think you need to either set
> the SESSION_ATTRIBUTES flag too, or explain how a node that hasn't
> processed this object knows that it should record labels.

[Pavan] Okay. I see that an explicit statement is needed to cover
implementations that do not set this SESSION_ATTRIBUTES flag for
unprotected LSPs (no issues with LSPs requesting local protection). We’ll
go ahead and add the following statement in Section 9.2:

   An ingress LER that sets this bit MUST also set the "label recording

   desired" flag in the SESSION_ATTRIBUTE object.

> Cheers
> Matt
>>> Cheers
>>> Matt
>>> On Wed, Sep 19, 2018 at 11:43 AM Matt Hartley <>
>>> wrote:
>>>> Authors,
>>>> A couple of comments on this. Apologies for leaving it until WGLC, but
>>>> I hadn't read the draft previously...
>>>> It's fairly clear while reading the draft that delegating label stack
>>>> imposition makes node-protection... difficult. The draft explicitly
>>>> declines to address the issue, but I see that we now have
>>>> draft-chandra-mpls-rsvp-shared-labels-np which addresses this issue. Would
>>>> it make sense to combine the two documents so that we have a more complete
>>>> shared-label solution? I think it would be better if we could... but this
>>>> is more of a preference on my side if the authors feel they'd prefer to get
>>>> the base technology standardized earlier.
>>>> At the end of section 4, you mention that an ingress node might want to
>>>> avoid creating a shared-label LSP which will have a deeper label stack than
>>>> it can handle by using delegation or reverting to standard RSVP-TE.
>>>> Hopefully implementations will have the sense to avoid signalling
>>>> shared-label LSPs like this, but I think it might be worth being more
>>>> assertive about this and making it a SHOULD NOT or even a MUST NOT.
>>>> Something the draft doesn't address at all (unless I missed it) is how
>>>> this works with loose-hop expansion. There seems to be an implicit
>>>> assumption that the ingress node calculates the entire path and can
>>>> therefore request delegation nodes to keep the label stack manageable if
>>>> need be, but once loose hops are in play this is no longer possible and you
>>>> could quite easily end up with a label stack that exceeds the ingress
>>>> node's capabilities. I think it would be worth adding some text to address
>>>> this; maybe specify that a node performing loose-hop expansion on a
>>>> shared-label LSP must also act as a delegation node for the segment of the
>>>> path that it expands, although there are other solutions too.
>>>> Cheers
>>>> Matt
>>> _______________________________________________
>>> Teas mailing list