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

Matt Hartley <> Fri, 21 September 2018 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4303C130E55; Fri, 21 Sep 2018 08:05:10 -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 DoLsoCb9cpx9; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BCA6612777C; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
Received: by with SMTP id d19-v6so6200212pgv.1; Fri, 21 Sep 2018 08:05:02 -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=OiBGQAsOHigHWcxg8xgMGGtLNXG/pczH5+iH6i8MOnE=; b=TTo4wbHD6cpwI8aatWuv4GMSoldMsZ6TZY5vgctD9clQFOT2TEhDgQGfWtjBzb+sT3 62SOso4C+f76KoWVRRag2lIk4YiJkkoWTbVK/Mzvy2117ftxIz2imVLZM5l1VSbeNH0U Kx7+Z24igyxXMOoGSBeXkwLiIHGAEQf+rMxGqg90s01SAX6oSR/AYVu5OB00eMsH3pfN 8xVzWYnl2OudicIrrTnz1+GP721L4yikD0rUg8ERFzEfiVamqunmIJbojP+nbYdLi8Mr HttWNaqemmvvuCwF5SSD9k2Pya9plKr2L5DfXwLbvywCtNX2c7moymmdet/56nU3jJ8v tPHA==
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=OiBGQAsOHigHWcxg8xgMGGtLNXG/pczH5+iH6i8MOnE=; b=lIntTjOAsryAuhfJKRAKy9yI42vKVY/fG12fPqKt0z2TQZLiQUC5nRO43Xeo4FA4OH qNTFrCoiRABvCoGtMR4gSs6oZI+ko3Gp47IleeqPJ2RUgJUHd2S/S0Hoo12HcEgBNfJu Vx1fu4++frF9Nk+q58FPKfh0RG/7CqCYdxYWzur63UbZPpLAVD/gBthUH2PnJhALJC8N umc9w6Q+pEEPD/PUld8B+Q12jnE4xPCwDz7Cc2GPBE3wvw2Og8kzmFxaDCdSKsYu2M6Y Wmn/FuRZxt5HDg5piFSyCCO0SSmoll+XnApet1hc1O8gZRq2AlNTn86Mdmtj9obpAhO2 oyCg==
X-Gm-Message-State: APzg51CQfQj6+esnvBaqG0kofjdXejAWTTo6BUfsHb5CDSu5EpdZbM0G 0m58MXOgPFRcfVkcR8lnl6dVqFSLCbTE89UdPck=
X-Google-Smtp-Source: ANB0VdZ0TQ9ii/GZ5m/6aFEHAVZ1jSn+RGFo4hrtxmyfv6Di5Qai5ppsftZtOwELdHCSjT+Ns4CJw4932t/L79Cedf8=
X-Received: by 2002:a63:d74f:: with SMTP id w15-v6mr42040727pgi.306.1537542302302; Fri, 21 Sep 2018 08:05:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Matt Hartley <>
Date: Fri, 21 Sep 2018 11:04:50 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000c1868d057662f6e4"
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 15:05:11 -0000


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

> Matt, Hi!
> Please see inline (prefixed VPB).
> Regards,
> -Pavan
> On Thu, Sep 20, 2018 at 2:25 PM Matt Hartley <>
> wrote:
>> 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
>    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.



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