Re: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels

Vishnu Pavan Beeram <vishnupavan@gmail.com> Fri, 03 November 2017 17:04 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 89C7D13FEF4; Fri, 3 Nov 2017 10:04:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 SXyLjt_pogP4; Fri, 3 Nov 2017 10:04:39 -0700 (PDT)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 9D88613FAED; Fri, 3 Nov 2017 10:04:39 -0700 (PDT)
Received: by mail-pf0-x229.google.com with SMTP id z11so2630004pfk.4; Fri, 03 Nov 2017 10:04:39 -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 :cc; bh=d/F+8awFb05GpRotYLWWzXaG8HhltSa1LFBSlFkoVVk=; b=YJNbIaDco0eBjhxSAXylL+Z9ethLrHqe4e+s1PqbaxmiFjD1Z0VGcInSxtM29E0lvb jMy3cX8VeU/hH/mPcWYU+blsGhwMIH685RBcyYUh6k1OaeGmBN52f2vWX8McK3zcyDm1 1aj0MFx3VkYlT3cMzOcY1lCGNxi22PEc7eZ2w9+0guPOi1dmXpoHgPTTC7o+8LJvizqN 7otIfWAu3Py6hc2CjFbsFrousb/Hd/dbmj9Cc8uA13fUAJnJz2LayqPStWxqgHKFAvmn DeKjmwBjBnaeb+p8xlp0Pv/gbCuiJXu3tBKODWrUmMndXTVTEivH5SDX/SqvPHSsMOr1 BAhA==
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:cc; bh=d/F+8awFb05GpRotYLWWzXaG8HhltSa1LFBSlFkoVVk=; b=sODm8esZvwQLwOdQU6/4hXfRd9hAh9ReLxUgaDHDHKlOYpfhuAiOYU1+MRE5aL+L5E UxosfxZcosOvdgTlj1MwJd2dhu45vYhCavW6dpeVoJuBLUcb3YVoYGjYwY44WXcALmGL E7YzcAwvj5VmJdDV9POfZGwg/2pzFq30myEhxCxd80Bu11xpoTD+BlxjRpg0tQhzkk5f astKoitppDztMObAhhB5psB6lrDJlLmiMjpeRSWjMLVo4k9Nu+lvHGpYjCtaniB6yYBw j9OqoICr8fVT+lpQvyPmUErXK5e9QYFXXpf88HyZy0CtOP/vcLERWGXuY6UKdygk6y8i 5zRw==
X-Gm-Message-State: AMCzsaW7xAPNcqeLtImjJanzRYOne/3HwaJQcGyOdiarSm0HptNrEH0k aBeguvKrbQUtsOTAPk24/wluw9mSSJI4Y4jIwaTXFg==
X-Google-Smtp-Source: ABhQp+S1QXkbB6EZwDWDkL49r9sWFWCbtyQpWo/KFWHJ50+nepiNC1VW5aCZUMUJhuYpJHFp6Lc8LX9ftloiKFVvAOw=
X-Received: by 10.84.235.69 with SMTP id g5mr7579609plt.239.1509728678877; Fri, 03 Nov 2017 10:04:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.145.8 with HTTP; Fri, 3 Nov 2017 10:04:37 -0700 (PDT)
In-Reply-To: <76CD132C3ADEF848BD84D028D243C9279812347F@NKGEML515-MBS.china.huawei.com>
References: <1872ff72-845f-4b85-11a5-f00123223fb5@pi.nu> <76CD132C3ADEF848BD84D028D243C92793895C23@NKGEML515-MBX.china.huawei.com> <CA+YzgTuAp-p4+2VdYvW=PDFV5ix01UwgC7MBfwvLZxaewbq0cA@mail.gmail.com> <76CD132C3ADEF848BD84D028D243C9279812347F@NKGEML515-MBS.china.huawei.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
Date: Fri, 3 Nov 2017 13:04:37 -0400
Message-ID: <CA+YzgTuvt4hiA0D9J1T7rdga_mfYmt4b5icnzP4C+ahL4QkNuQ@mail.gmail.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: Loa Andersson <loa@pi.nu>, "mpls@ietf.org" <mpls@ietf.org>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "draft-sitaraman-mpls-rsvp-shared-labels@ietf.org" <draft-sitaraman-mpls-rsvp-shared-labels@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="089e0820c4389ca1aa055d1719d4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/wlEsRbDSLxi2qfnxt6OMR6_TnNk>
Subject: Re: [mpls] working group adoption poll on 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: Fri, 03 Nov 2017 17:04:42 -0000

Jie, Hi!

Thanks for the follow-up. Please see inline.

Regards,
-Pavan

On Fri, Nov 3, 2017 at 4:02 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

> Hi Pavan,
>
> Sorry for the delay in response. Please see inline:
>
> > -----Original Message-----
> > From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com]
> > Sent: Monday, October 23, 2017 10:49 PM
> > To: Dongjie (Jimmy) <jie.dong@huawei.com>
> > Cc: Loa Andersson <loa@pi.nu>nu>; mpls@ietf.org; <rtg-ads@ietf.org>
> > <rtg-ads@ietf.org>rg>; draft-sitaraman-mpls-rsvp-shared-labels@ietf.org;
> > mpls-chairs@ietf.org
> > Subject: Re: [mpls] working group adoption poll on,
> > draft-sitaraman-mpls-rsvp-shared-labels
> >
> > Jie, Hi!
> >
> > Thanks for the review and for the support. Please see inline for
> responses
> > (prefixed VPB).
> >
> > Regards,
> > -Pavan
> >
> > On Wed, Oct 18, 2017 at 11:18 AM, Dongjie (Jimmy) <jie.dong@huawei.com>
> > wrote:
> > > Hi Loa,
> > >
> > > I've read this document and think it provides a useful function for
> reducing the
> > data plane state of RSVP-TE LSPs. Thus I support the adoption.
> > >
> > > I concur with Lou's concern about the TE bandwidth/tspec/rspec
> processing,
> > the impact of shared label on this needs to be specified.
> >
> > [VPB] Please see if my response to Lou adequately addresses your concern.
>
> The proposed text about the mapping between shared label and the bandwidth
> reservations would be a good start, and maybe the consequence of the
> reservation aggregation can also be described.
>

[Pavan] We will add the proposed text.


> > >
> > > I also have some concerns about the automatic delegation process
> described
> > in section 5.3, maybe I need to reread it, but it seems that in some
> cases the
> > mechanism may not result in an appropriate set of delegation nodes. And
> what
> > would happen if the ETLD value in the received PATH message is bigger
> than the
> > maximum number of labels this node can handle? It seems this case was not
> > covered in section 5.3.
> >
> > [VPB] Section 5.3.1 says --
> > "The ETLD MUST be decremented at each non-delegation transit hop by
> either 1
> > or some appropriate number based on the limitations at that hop."
> >
> > The "limitations at that hop" reference is not necessarily limited to the
> > "outbound limitation", it could include the "read limitation" as well.
> Consider a
> > transit hop that can read only 6 labels. If this hop receives an ETLD of
> 8 from the
> > previous-hop, then it could adjust the outgoing ETLD to 5 (thus ensuring
> that it
> > can never receive more label-stack-entries than it can read).
> Wi
> Thanks for the explanation. Yes both the send limitation and read
> limitation need to be taken into consideration. So in many cases decrement
> by some number other than 1 would be needed.
>
> [Pavan] Yes, agree. This is covered by the following statement in the
draft:

The ETLD MUST be decremented at each non-delegation transit hop by
either 1 or some appropriate number based on the limitations at that
hop.

Maybe it is worth mentioning that for transit nodes, the ETLD it sent is
> determined by both the received ETLD from previous hop and its read and
> send limitation in label processing?
>
[Pavan] The current text in the draft leaves sufficient room for this
behavior (and I'm aware of an implementation that does this already) and
also for the behavior where only the "imposition limitation" is taken into
account. That said, we can add some text to make this point clear.


>
> Another point is the ETLD is defined in HOP_ATTRIBUTES subobject, which
> means the transit node will add a new ETLD Attributes TLV for itself,
> rather than modifying the ETLD attribute it received from the previous hop.
> Some update to the description about the ETLD manipulation may be needed to
> reflect this.
>
[Pavan] Yes, as mentioned in the draft, ETLD is just another per-hop
attribute -- RFC7570 procedures come into play. A transit-hop that does not
support this functionality will not record the ETLD. We could possibly add
an Appendix detailing a "sample algorithm" in a later revision (if needed).


> I think all of the above can be done after the adoption.
>
[Pavan] Thanks!


> Best regards,
> Jie
>
> >
> > >
> > > It would be great if the above concerns could be considered either
> before or
> > after the adoption.
> > >
> > > Best regards,
> > > Jie
> > >
> > > -----Original Message-----
> > > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson
> > > Sent: Saturday, October 14, 2017 11:20 PM
> > > To: mpls@ietf.org
> > > Cc: <rtg-ads@ietf.org>rg>;
> > > draft-sitaraman-mpls-rsvp-shared-labels@ietf.org; mpls-chairs@ietf.org
> > > Subject: [mpls] working group adoption poll on
> > > draft-sitaraman-mpls-rsvp-shared-labels
> > >
> > > Working Group,
> > >
> > > This is to start a two week poll on adopting
> > > draft-sitaraman-mpls-rsvp-shared-labels-02 as a MPLS working group
> > document.
> > >
> > > Please send your comments (support/not support) to the mpls working
> group
> > mailing list (mpls@ietf.org). Please give a technical motivation for
> your
> > support/not support, especially if you think that the document should
> not be
> > adopted as a working group document.
> > >
> > > There are three IPR disclosures (though one disclosure seems to be an
> > > update) against this document.
> > >
> > > All the authors have stated on the MPLS wg mailing list that they are
> > > unaware of any other IPRs that those that has been disclosed
> > >
> > > The working group adoption poll ends October 29, 2017.
> > >
> > > /Loa
> > > mpls wg co-chair
> > > --
> > >
> > >
> > > Loa Andersson                        email: loa@pi.nu
> > > Senior MPLS Expert
> > > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > mpls@ietf.org
> > > https://www.ietf.org/mailman/listinfo/mpls
>