Re: [mpls] FW: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels

Vishnu Pavan Beeram <> Mon, 02 October 2017 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7611F13469C for <>; Mon, 2 Oct 2017 08:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 HBmmMm2gvxEx for <>; Mon, 2 Oct 2017 08:08:31 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87CE3132076 for <>; Mon, 2 Oct 2017 08:08:31 -0700 (PDT)
Received: by with SMTP id q11so4982287ioe.10 for <>; Mon, 02 Oct 2017 08:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ef4c/TZHvRnCd7dav3ArpTH55PRBigJ9xEbZ7fA5ibw=; b=rRscSRyE9POunmbxQ241Inycpg/xGu25JEaq9AgjgH7ncl1fR6ORx6Yrwlk8CKlrNd byOEhKnS9gOKNrxJMWN3EwB3EIPr0pyfmFG+dMd+Ji7WNlTOwNbOyeGx72Uak1uoBpp/ tTZ0m6bUGGr0AsakTQzHLBKRWFSYnKZvRs90CQAvnWWqD1Vfd8nb9aCAnO6cCMjdlhZY FvugraVABxyTpqV648kJTQ1MwXWFdiw2YiGc48TWaGK9c8wUEvD6tN+5yBxpSr3KQ0ay mnvf2jJA8fQN2cZnSNlHwS14bAFRaMztYgxWXhVkpZ9dKelIqCwgzp+vcj/rWP+GmIaT uX7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ef4c/TZHvRnCd7dav3ArpTH55PRBigJ9xEbZ7fA5ibw=; b=tGtDoTQPcAnkPE/1TecqXOAMcaJ63K84kg+N+Rt+b5LmMCW8o11w8BiOryJRnk7QHl PtaqK2Ttm8/xfeXoVPdUjvdfbMQuU5+AdQ7AVKBlsuDGS5zHxfikBN1jkyykeOKX0Eid 9akPXk7h3CkTeACLAylERsGVHjRvdWlyM4nIvtA6zUwyLixu2oolM14PhWk9BMxOpn3y eoPrxxYaqTcGD8P1oHSFlTv9b5KsB1WTa3cUJ1b/UQx8sETaKTwgGdCebRs8rXfqa9Fo +8FfRhs0lvxEBmhteaMX7GJv+Nr8hPsWP0LA30MCkn1Sip/Jt/OkYxUdynCxQinaqzGW fm0g==
X-Gm-Message-State: AMCzsaWvPJR+DLC7craAB4xJ5CWVHfpZHSNmP1xRPBNGqpTcI0eVAQAN HPjdyusgvZ88GW68shrj5U/Y0fne8v87yAkn+XA=
X-Google-Smtp-Source: AOwi7QBjE5QT2m7/pMLqY82UGira8BloBAxOmdnVHve26uk4PAroVxq6v8MLD5ypvAbJLpgJRp/tOnB6/BiJURFzTck=
X-Received: by with SMTP id g84mr26960604iod.272.1506956910506; Mon, 02 Oct 2017 08:08:30 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 2 Oct 2017 08:08:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Vishnu Pavan Beeram <>
Date: Mon, 2 Oct 2017 11:08:29 -0400
Message-ID: <>
To: IETF MPLS List <>
Content-Type: multipart/alternative; boundary="001a113f328857c18c055a91bf11"
Archived-At: <>
Subject: Re: [mpls] FW: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Oct 2017 15:08:34 -0000

{ plus MPLS WG }

> From: Vishnu Pavan Beeram <>
> Date: Sunday, October 1, 2017 at 5:06 PM
> To: Greg Mirsky <>om>, Loa Andersson <>
> Cc: "Rajiv Asati (rajiva)" <>om>, Stewart Bryant <
>>gt;, Yimin Shen <>et>, "
>" <
> Subject: Re: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
> Greg, Hi!
> Thanks for the thorough review. Responses inline (prefixed VPB).
> Regards,
> -Pavan
> From: Greg Mirsky <>
> Date: Tuesday, September 26, 2017 at 3:44 PM
> To: Loa Andersson <>
> Cc: "Rajiv Asati (rajiva)" <>om>, Stewart Bryant <
>>gt;, Yimin Shen <>et>, "
>" <
> Subject: Re: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
> Resent-From: <>
> Resent-To: Harish Sitaraman <>et>, Vishnu Pavan Beeram
> <>et>, <>om>, <>
> Resent-Date: Tuesday, September 26, 2017 at 3:44 PM
> Dear Authors, WG chairs,
> <>,
> below please find my review of draft-sitaraman-mpls-rsvp-shared-labels-02:
>    - the document is very well written and it was pleasure to read it;
>    - I believe that the proposed "pop and forward" functionality is
>    useful;
>    - the proposed solution is technically sound.
> Hence my conclusion - the draft is ready for WG adoption.
> [VPB] Thanks!
> Taking this opportunity I'd like to share my comments but I don't consider
> any gating WG adoption:
>    - Introduction refers to labels with pop and forward functionality as
>    transit labels. Later in the draft, as I understand, such labels referred
>    to as 'pop labels'. Please consider establishing that these terms are used
>    interchangeably or using only 'pop label' term;
> [VPB] We'll make the usage consistent in the next revision.
>    - I think that in all examples it is assumed that the egress LER
>    advertises implicit NULL label. There's no need to change examples but it
>    may be helpful to clarify use of the implicit NULL label by the egress LER;
> [VPB] The procedures discussed in the draft do not change based on the
> type of the label used by the egress LER. We can add a statement to clarify
> this.
>    - the draft introduces Effective Transport Label-Stack Depth (ETLD)
>    parameter. On the other hand, in Sectio 4 of Entropy Label for SPRING
>    Tunnels
>    <> introduced
>    Entropy Readable Label Depth/Readable Label Depth. Could it be that these
>    are the same? That only one parameter is sufficient?
> [VPB] ETLD is different from RLD (Readable Label Depth) or MSD (Maximum
> SID Depth). ETLD is the maximum number of transport labels that a given
> node can potentially send to its downstream hop relative to its position in
> a given delegation segment. As noted in the draft, the ingress or the
> delegation hop starts with an appropriate value. This value is then
> decremented/adjusted at each successive hop. If a node is reached where the
> ETLD set from the previous hop is 1, then that node selects  itself as the
> delegation hop.
> [VPB] A node can take both RLD and MSD into account before adjusting the
> ETLD. For example, if a node can read only 4 labels (read–limit) in the
> stack, then the ETLD on this node can be adjusted in such a way that the
> upstream node will never send more than 4 labels. Similarly if a node can
> push only 3 labels, then the ETLD on this node is adjusted in such a way
> that the node has to never push more than 3 labels.
>    - section 8.1 I think it will be helpful to provide information on
>    what the label stack looks when a packet arrives at node F;
> [VPB] With link-protection, the real node of interest is the merge-point
> (Node C in the example) and the focus of the current text is to highlight
> how the packet makes it to C (after the label gets popped at the PLR).  If
> the link-protecting bypass goes from B to C via F and G, then F is merely a
> transit node along the bypass path.
>    - extensions proposed in section Protocol Extensions will be easier to
>    understand and evaluate if these refer to figures.
> [VPB] Ok.
> Regards,
> Greg
> On Fri, Sep 15, 2017 at 2:47 AM, Loa Andersson <> wrote:
>> Greg, Rajiv, Stewart, Yimin
>> You have been selected as MPLS-RT reviewers for
>> draft-sitaraman-mpls-rsvp-shared-labels-02.
>> Note to authors: You have been CC'd on this email so that you can know
>> that this review is going on. However, please do not review your own
>> document.
>> Reviews should comment on whether the document is coherent, is it
>> useful (ie, is it likely to be actually useful in operational networks),
>> and is the document technically sound?
>> We are interested in knowing whether the document is ready to be
>> considered for WG adoption (ie, it doesn't have to be perfect at this
>> point, but should be a good start). Please remember that it often is
>> easier to progress the document when it has become a working group
>> document. All comments in the MPLS-RT review needs to be addressed,
>> but please think carefully about whether a comment is gating the
>> adoption or could just as easily be addressed after the adoption.
>> Reviews should be sent to the document authors, WG co-chairs and WG
>> secretary, and CC'd to the MPLS WG email list. If necessary, comments
>> may be sent privately to only the WG chairs.
>> If you have technical comments you should try to be explicit about what
>> needs to be resolved before adopting it as a working group document, and
>> what can wait until the document is a working group document and the
>> working group has the revision control.
>> Are you able to review this draft by August 29, 2017? Please respond
>> whether you are available to do the review in a timely fashion.
>> Thanks, Loa
>> (as MPLS WG co-chair)
>> --
>> Loa Andersson                        email:
>> Senior MPLS Expert                
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64