Re: [mpls] short wgap confirmation poll on draft-sitaraman-mpls-rsvp-shared-labels-02

Folks, Hi!

As Loa mentioned, we published a new version (-03) to address relevant
comments/questions that were raised during the RT-review process and the WG
adoption poll. Please do go through the diffs (
https://tools.ietf.org/rfcdiff?url2=draft-sitaraman-mpls-rsvp-shared-labels-03.txt)
and let us know if there are any concerns with these changes.

The following is a high-level summary of the changes introduced in this new
version:

**
(1) Terminology:
There were some concerns raised regarding some of the terminology used to
aid the narrative in the -02 version. Based on the feedback received, we
replaced the terms ‘Pop label’, ‘Pop and forward data plane’ and ‘RSVP-TE
pop and forward tunnel” with ‘TE link label’, ‘Shared MPLS forwarding
plane’ and ‘Segment Routed RSVP-TE tunnel’ respectively. We got rid of the
term ‘swap label’ altogether. We simply use ‘regular label’ in places where
there is a need to refer to the traditional label.
**

(2) Does this draft update MPLS Architecture?
There was a question raised on whether the functionality discussed in this
draft updates the base MPLS architecture (RFC3031). The answer is “No”. We
added the following sentence to stress this point:

   This forwarding plane behavior fits in the MPLS architecture
   [RFC3031] and is same as that exhibited by Segment Routing (SR)
   [I-D.ietf-spring-segment-routing] when using an MPLS forwarding plane
   and a series of adjacency segments.
**

(3) Does this apply to P2MP Tunnels?
There was a question raised on the applicability of this functionality to
RSVP-TE P2MP tunnels. The current focus is only on P2P tunnels. We added
the following statement in the draft to make this obvious:

   The signaling procedures and extensions discussed in this document do
   not apply to Point to Multipoint (P2MP) RSVP-TE Tunnels.
**

(4) How does the notion of ’TE link labels’ impact implementations that
maintain per label bandwidth accounting?
We added the following statement in the draft to address this:

   Implementations that maintain per label bandwidth accounting at each
   hop must aggregate the reservations made for all the LSPs using the
   shared TE link label.
**

(5) Is there any impact on the behavior of PHP LSRs?
There is no impact. We added the following statement:

   There is no change in the behavior of a
   penultimate hop popping (PHP) LSR [RFC3031].
**

Regards,
-Pavan (on behalf of the authors)

On Sat, Dec 9, 2017 at 1:52 AM, Loa Andersson <loa@pi.nu> wrote:

> Working Group,
>
> draft-sitaraman-mpls-rsvp-shared-labels-02 did go through a poll
> to see if we had consensus to adopt it as as a MPLS working group
> document.
>
> The outcome of the wgap was that there were changes that we wanted¨to do
> before adoption of the document
>
> This is to start a short (one week) poll to see if the comments from the
> earlier wgap has been correctly addressed in draft-sitaraman-mpls-rsvp-shar
> ed-labels-03.
>
> Due to the nature of the poll silence will be considered to be consent,
> however it would be appreciated if those of you that made the comments
> we are now addressing can confirm that tou are comfortable with how
> they have been addressed.
>
> 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 Decembet 19, 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
>