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

Matt Hartley <> Thu, 20 September 2018 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C5A8130DEE; Thu, 20 Sep 2018 11:25:24 -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 yBpQpki5r1DX; Thu, 20 Sep 2018 11:25:22 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB18C130DD9; Thu, 20 Sep 2018 11:25:22 -0700 (PDT)
Received: by with SMTP id l63-v6so4813977pga.7; Thu, 20 Sep 2018 11:25:22 -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=jUsPa3bzTMkeSNhCSUhJvAURCZ6NwbS7opgLRcJ7qwU=; b=IGnuSzXF9zCibMRPahHYpVRiEjedCeoq7k6YE5ferE50X5IhtZFqG9TFQS4RvvgoDw FJTao7f5iZtVP5cof4BfaYcUzt4dbsZabVep8KxOLffxTyy3RrWxcyO5PWL7TlmqiOBI FoL+ZKed9OzIbUhLXcClTOQtqMP3f0V9U6SIr+ORfX5+q8vCrJA4H1CJ+Cp3mQE86HIZ +BJdUKucwm0QHY6TLS1LOm+TL2zUbmRKuy0euu+wBeY+bG6l1jOI03rPITOLUlD2iyad hCGfWqVt9Nh9TB3JzTUXi5ryDY12/utGSzXGSFFQ0ARj3WLgVHvn6GWeqGKioKddBT10 0dUw==
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=jUsPa3bzTMkeSNhCSUhJvAURCZ6NwbS7opgLRcJ7qwU=; b=P9VBY8HetzRh/dBdrNdN5mm1NNnhzIkoA7vQ5zUVbp/dMErTF4cPmMLhWKs87huuYv LHSmESnweunw4mhLFGwrMynbgq01Ztjb/QE4KZRdQqO8VZCP81apPDJnrIm0sPMoaS83 hmzAgI+ZapCIExRIjkK4Wa6KZw0Rg62njdAhRu4mdLuNzLtmbS+WKTJ8J+hqS/23Bd5l Z2931ooQ9bban8iE5Y1KzIoaKkrPDWH74zBAFiyCvvBOu8GmaaeKzgB9CRv4LH37nlrU rFOfrQ/nmIXzZjSWkaTQzJ3RdwK4WkmGICc+dJudXBvP2NZmF+ZghICCDRfmqsWNRGXL syiQ==
X-Gm-Message-State: APzg51D49MXZ7SKDTHagBfdjzFj2Km2208pOmsYuvA+g+a1MR//ViLxH hzMR6MEuz6OdZYjPI40DZ/JtlIqOT4NZeDQ6i55lng==
X-Google-Smtp-Source: ANB0VdZsqxgL7V561y1B47REsWxnoCwXSchRZsBt8SM5tGBxSAXLHB52fSq8eGMv1OHJL8zASb8cjALBQ5cfY4igoAA=
X-Received: by 2002:a62:59d5:: with SMTP id k82-v6mr42167279pfj.143.1537467922206; Thu, 20 Sep 2018 11:25:22 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Matt Hartley <>
Date: Thu, 20 Sep 2018 14:25:10 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000005b5429057651a54f"
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 18:25:25 -0000

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?



On Wed, Sep 19, 2018 at 11:43 AM Matt Hartley <>

> 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