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

Vishnu Pavan Beeram <> Thu, 20 September 2018 23:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20E08124D68; Thu, 20 Sep 2018 16:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 eG2RHSNAZ871; Thu, 20 Sep 2018 16:16:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E97C11286D9; Thu, 20 Sep 2018 16:16:06 -0700 (PDT)
Received: by with SMTP id b129-v6so5108232pga.13; Thu, 20 Sep 2018 16:16:06 -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=sJouSWYwVglFdWe4eCRaf0iNFSdHgw+oyj4c9Cvd/t8=; b=QFBYKalec8lKsRjdpRjTpNFi2AMgzYj1YPARMame8L/l7ov2/sp096f7VHGmleDrJe 7cG3e5cGiMzY+wLeztEfso1MAzVE7NJUNhWQMtxNALb8bXKvdyA1xIMKsDx/dhcjvKUl XRvUO/Y9vO8rMBRU+PwBVV9evL3Yb90l4gJZQJQo/ZtKtKU1TvXIOH+AgorWXY1rBLf5 wqp9udMhec1XXqcmURGlUeB4yXBmxbV4iq1/NVzJuesozasow2woFywAiXAHmZF3+a+Q FcPibpkxhbYfx30FdgxOTuBFNUgv0GXj39r4NG/GiJdtJCbQLZltVq3fl12Akij7cSN8 BAUQ==
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=sJouSWYwVglFdWe4eCRaf0iNFSdHgw+oyj4c9Cvd/t8=; b=kvoX4/kFYmoz0AWw/evUf5GpJq8p6+13sepjBVvS77JMoMOERlcZr6bJemTrLr9pPV vbhfka4VTPeS8TtM05zafv33Dfg0M5HqVOb4BD14zb5/lk1QjIu50yfBgnpA7B+VmO8a +JdzbYqaq4/RH6MwrxuEXiWGR9JtTqcLyluZPXUgm8XGU4UbfgSIaQ3B/bmHuxOkEA8I NcsVWLLP2xoeFnNt5IJZLk7hX02qv2xKl//bSsrnCAvhCKhRzRWI7pIW5qPrm1GUIOB/ 4WgxHdm3ZKuAxNmwrbE5v5bQHK7l8KmJxubVbWLFfyar4MwYmtMQjp4CCr/nVT43mAsB rDkg==
X-Gm-Message-State: APzg51BeflboXPYCGvB8TDY/FV05vhtKNZXlwPVmkdSgNbSwoQyg7qN7 o+NR9AHybz+ecXhIEsq539GbNIOMrbQ/QPiyuyM=
X-Google-Smtp-Source: ANB0VdZ8gPvdqc/ECiQLmrC+mvqUdI6Nsxy6Dd+uJ/3ZsoTA0fiX1eilRRQIafHVMU0dp6z53IQHjJItY6ngUa9Cb6A=
X-Received: by 2002:a62:56d9:: with SMTP id h86-v6mr43707270pfj.229.1537485365864; Thu, 20 Sep 2018 16:16:05 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Vishnu Pavan Beeram <>
Date: Thu, 20 Sep 2018 19:15:53 -0400
Message-ID: <>
Cc:, IETF MPLS List <>, TEAS WG <>
Content-Type: multipart/alternative; boundary="000000000000146f29057655b53b"
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: Thu, 20 Sep 2018 23:16:10 -0000

Matt, Hi!

Please see inline (prefixed VPB).


On Thu, Sep 20, 2018 at 2:25 PM Matt Hartley <>

> One more thing...
> 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


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

> 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