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

Vishnu Pavan Beeram <> Thu, 20 September 2018 22:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75181129AB8; Thu, 20 Sep 2018 15:51:43 -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 1gVvZMqIjXwO; Thu, 20 Sep 2018 15:51:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD9DD128BAC; Thu, 20 Sep 2018 15:51:39 -0700 (PDT)
Received: by with SMTP id k21-v6so5032567pff.11; Thu, 20 Sep 2018 15:51:39 -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=Xti0TbFHpnW9aWqJ6uBMTk2TFFmCbDVqO2s5X2xFe0o=; b=Og6NcZ/awhGIwOKI/tOMzlLTgF7x8+536Z4JdsuYi752VnwQHzbjMO8PufnKG4kEyP LVIrIjbeHokw+ULDg1p5l/Z8+7/WqTVOtPz9zGt0bSLCjVYUFu8SYf+4XHtBfGWnSrGm ZvJKSiypARwSDLqgYWj/N1Ony6DqYG+CcupJwp+CpuLoRKfvSzB7SS1AGtEjuYrLQOns hw0kVeZ7Eb/Dq1e3zAUkKYv85x46otpl5QFS/4XUV9hkKGdE3sBOTZkxUwGaIK5RELrm OWEBK0WcO5t0TGz0xbqTy2hekyqmasfU/v637PdL/EfiMASoe/p3J0vf8qpnFVKyC+FD rsww==
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=Xti0TbFHpnW9aWqJ6uBMTk2TFFmCbDVqO2s5X2xFe0o=; b=c89bhRNd3WtYy2KDgUeRUNEUFIVr1Ux7jSflxWF6nogoFBDxD3u5/AfWqdLyVokq2T /3vriyzGWWrSyKqfrMe6QqRXBTI+ghnfcCobZfbRMb6HfAtIyIeHNQoQZbqG5QJkT6yf BcLdxlaGkIneEJvfhf94qqwfejaHB1/QpAvcMznmjR/Ml6mNVvaNTh60Bl8v2ro/Izr6 TVdKYMa31ootEj4nmaXObyI85n6gfzgRS0u2BQeMsb/5CPnxPO0ZxaKGojPdI4e1YSCt cGjCXAg7tn9Sk7l/6U1ZQ76xABy0evDZ3Ol99ZuAJh5/uPu9ugsJSdbSLodVC16ibm65 wNoQ==
X-Gm-Message-State: APzg51DNWm7IG2Yb+yF9hPUqwt7pSZbLzB/N4ZS9zsljmbQVsHIBv/62 YvEggVijW2rWT/7ZCg6flguJ8czoctCmJsLhWb0=
X-Google-Smtp-Source: ANB0VdZsWRdEKZECjz4z+0VphseZVAdAjBJQKChYnBbZETtLi6U0ybio+5qpcJRrpXk34BHCJLN8mLVoUDJWZV/EIdk=
X-Received: by 2002:a62:56d9:: with SMTP id h86-v6mr43633730pfj.229.1537483899285; Thu, 20 Sep 2018 15:51:39 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Vishnu Pavan Beeram <>
Date: Thu, 20 Sep 2018 18:51:27 -0400
Message-ID: <>
Cc:, IETF MPLS List <>, TEAS WG <>
Content-Type: multipart/alternative; boundary="000000000000aa36410576555d49"
Archived-At: <>
Subject: Re: [Teas] [mpls] 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 22:51:44 -0000

Matt, Hi!

Please see inline for responses (prefixed VPB).



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

> Authors,
> A couple of comments on this. Apologies for leaving it until WGLC, but I
> hadn't read the draft previously...

[VPB] Much Thanks for the review. It is never too late to send in review

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

[VPB] “Difficulty” is a relative concept 😊. Supporting facility backup
link protection on the shared forwarding plane is straight-forward – this
is discussed in Section 8.1 of the draft.  But given the nature of the
forwarding plane, we needed to define new procedures for facility backup
node protection. Delegation is just another additional aspect to consider
while defining these procedures. By the time we put together the node
protection procedures, the base draft was sufficiently cooked for an
implementation to adopt and deliver a deployable solution (note that there
are deployments out there that don’t turn on node-protection). So, we went
ahead and published a separate draft for node protection
The procedures in this new draft are fully backwards compatible with the
procedures discussed in the base draft. IMO, stalling the progress of the
base draft and waiting for the node protection procedures to mature seems a
tad unfair. Our (the authors’) preference would be to progress the base
draft without any references to the node protection draft and let the node
protection draft go through the WG process independently (take the natural

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

[VPB] I don’t think I follow this. The last paragraph of section 4 reads:

   There MAY be local operator policy at the ingress LER that influences

   the maximum depth of the label stack that can be pushed for a Segment

   Routed RSVP-TE tunnel.  Prior to signaling the LSP, the ingress LER

   may decide that it would be unable to push a label stack containing

   one label for each hop along the path.  In this case the LER can

   choose either to not signal a Segment Routed RSVP-TE tunnel (using

   normal LSP signaling instead), or can adopt the techniques described

   in Section 5
or Section 6

All that the above text is trying to say is that in scenarios where the
ingress LER cannot handle the full label stack, it can get around this
limitation by either using the delegation approach or reverting to
traditional RSVP-TE. Where would a “SHOULD NOT/MUST NOT” statement come in?

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

[VPB] The draft doesn't make any mention of "loose-hop expansion" because
the authors didn't seen the need to add any specific text for this. There
are two types of delegation discussed in this document – Explicit
Delegation and Automatic Delegation (Sections 5.2 and 5.3). There is
nothing special about loose-hop expansion when Automatic Delegation is in
play. The node that expands the loose-hop processes the ETLD like any other
transit node as per the procedures defined in Section 5.3.1. Explicit
Delegation is meant to be used when the controller/ingress has full
visibility into the limitations of the nodes/links that constitute the path
of the LSP. If the controller/ingress does not have full visibility (as
would be the case when loose-hop paths are used), then it should just use
automatic delegation.

> Cheers
> Matt
> _______________________________________________
> mpls mailing list