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

Vishnu Pavan Beeram <vishnupavan@gmail.com> Mon, 02 October 2017 15:08 UTC

Return-Path: <vishnupavan@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7611F13469C for <mpls@ietfa.amsl.com>; Mon, 2 Oct 2017 08:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBmmMm2gvxEx for <mpls@ietfa.amsl.com>; Mon, 2 Oct 2017 08:08:31 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CE3132076 for <mpls@ietf.org>; Mon, 2 Oct 2017 08:08:31 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id q11so4982287ioe.10 for <mpls@ietf.org>; Mon, 02 Oct 2017 08:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.107.132.87 with SMTP id g84mr26960604iod.272.1506956910506; Mon, 02 Oct 2017 08:08:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.7.216 with HTTP; Mon, 2 Oct 2017 08:08:29 -0700 (PDT)
In-Reply-To: <2B07BAAD-A172-4E6C-A039-4D6614A690C3@juniper.net>
References: <d6676034-3841-e79f-f833-419e6c97d0de@pi.nu> <CA+RyBmWOE_w525S7DXc8i_YOxcgLs1Aqa_QDL_2aBOA7_K6D7w@mail.gmail.com> <A8AC9D17-2D93-4016-884C-AE34B36FFD26@juniper.net> <2B07BAAD-A172-4E6C-A039-4D6614A690C3@juniper.net>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Mon, 2 Oct 2017 11:08:29 -0400
Message-ID: <CA+YzgTsT9402DMW3O+BFrh_TyQdWg9vtH1NnE3O9peuaMFqWBQ@mail.gmail.com>
To: IETF MPLS List <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113f328857c18c055a91bf11"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/f4QLnYjAgceONQs1GOJh4Qj78OE>
Subject: Re: [mpls] FW: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Oct 2017 15:08:34 -0000

{ plus MPLS WG }



> From: Vishnu Pavan Beeram <vbeeram@juniper.net>
> Date: Sunday, October 1, 2017 at 5:06 PM
> To: Greg Mirsky <gregimirsky@gmail.com>om>, Loa Andersson <loa@pi.nu>
> Cc: "Rajiv Asati (rajiva)" <rajiva@cisco.com>om>, Stewart Bryant <
> stewart.bryant@gmail.com>gt;, Yimin Shen <yshen@juniper.net>et>, "
> draft-sitaraman-mpls-rsvp-shared-labels@ietf.org" <
> draft-sitaraman-mpls-rsvp-shared-labels@ietf.org>
> 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 <gregimirsky@gmail.com>
> Date: Tuesday, September 26, 2017 at 3:44 PM
> To: Loa Andersson <loa@pi.nu>
> Cc: "Rajiv Asati (rajiva)" <rajiva@cisco.com>om>, Stewart Bryant <
> stewart.bryant@gmail.com>gt;, Yimin Shen <yshen@juniper.net>et>, "
> draft-sitaraman-mpls-rsvp-shared-labels@ietf.org" <
> draft-sitaraman-mpls-rsvp-shared-labels@ietf.org>
> Subject: Re: MPLS-RT rreview of draft-sitaraman-mpls-rsvp-shared-labels
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: Harish Sitaraman <hsitaraman@juniper.net>et>, Vishnu Pavan Beeram
> <vbeeram@juniper.net>et>, <tejal.parikh@verizon.com>om>, <tsaad@cisco.com>
> Resent-Date: Tuesday, September 26, 2017 at 3:44 PM
>
> Dear Authors, WG chairs, et.al
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__et.al&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=rGQH19azWZ6Vtu2iMbPcVSFLpuiaJiFK19CE4FIgACk&s=g81q4Dyv36xSCwQ6hOag_2YA76cqzrqJFHkTVB2k-ds&e=>,
>
> 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
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmpls-2Dspring-2Dentropy-2Dlabel-2D06&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CFHVfW0WsgxSqM6wTJiWE5evUJAdlUl1fm7E0WVbiS8&m=rGQH19azWZ6Vtu2iMbPcVSFLpuiaJiFK19CE4FIgACk&s=JSKK4zTW11k75iLyn3n5T99U0NGSRnMGyg3tCHD6jx4&e=> 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 <loa@pi.nu> 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: loa@mail01.huawei.com
>> Senior MPLS Expert                          loa@pi.nu
>> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>>
>
>