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

From: "Tarek Saad (tsaad)" <[email-masked]>
Date: Wed, 1 Nov 2017 22:44:53 +0000

Hi all,

I support this work (as co-author) and I see its utility in deployments where RSVP and segment-routing will/can interwork to provide a distributed traffic-engineering solution.
With respect to label terminology used in the current draft, authors had a short discussion and we agreed to align with terminology used in "draft-ietf-spring-segment-routing" for adjacency and binding segment labels so to minimize confusion. This will be clarified in a subsequent update to the document.

Regards,
Tarek
 
-----Original Message-----
From: Vishnu Pavan Beeram <[email-masked]>
Date: Tuesday, October 31, 2017 at 4:20 PM
To: Lou Berger <[email-masked]>
Cc: Loa Andersson <[email-masked]>, "[email-masked]" <[email-masked]>, "<[email-masked]>" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, Tarek Saad <[email-masked]>
Resent-Date: Tuesday, October 31, 2017 at 4:20 PM

    Lou, Hi!
    
    Thanks for the feedback!
    Please see inline.
    
    Regards,
    -Pavan
    
    On Fri, Oct 27, 2017 at 5:43 PM, Lou Berger <[email-masked]> wrote:
    > Hi Pavan,
    >         Sorry about the delayed response.  See below.
    >
    > On 10/23/2017 09:20 AM, Vishnu Pavan Beeram wrote:
    >> Lou, Hi!
    >>
    >> Thanks for reviewing this. Please see inline (prefixed VPB) for responses.
    >>
    >> Regards,
    >> -Pavan
    >>
    >>
    >> On Mon, Oct 16, 2017 at 1:41 PM, Lou Berger <[email-masked]> wrote:
    >>> Hi Loa,
    >>>
    >>>     I have some technical concerns about this document that IMO need to
    >>> be addressed. I think addressing them before adoption would be best but
    >>> is certainly not the only option:
    >>>
    >>> - The document is completely silent on the impact of shared labels on TE
    >>> bandwidth/tspec/rspec related processing.  Clearly there is some no
    >>> inconsequential impact and this needs to be covered.
    >>
    >> [VPB] We will add some text in the next version explaining the mapping
    >> between a shared label and the corresponding bandwidth-reservations.
    >> Implementations that maintain per-label bandwidth accounting at each
    >> hop must aggregate the reservations made for all the LSPs using the
    >> shared-label.
    >
    >> Note that using a shared pop-label (albeit a special
    >> label) along the path of an MPLS RSVP LSP is nothing new. Signaling
    >> for PHP LSPs (we can signal 1-hop PHP LSPs as well) is done today
    >> without any special changes to the tspec/flowspec processing at the
    >> penultimate hop. The only difference now (with the changes proposes in
    >> the draft) is that a pop-label can be used at any given hop along the
    >> path of the LSP.
    >
    > I think sharing in the middle of the network, and potentially onto other
    > hierarchical labels, is a bid different -- this said I think your first
    > couple of sentences above are right on the mark.
    >
    
    [Pavan] Ack. We'll add relevant text to the next version as indicated.
    
    >>
    >>>
    >>> - The definition of ' pop and forward tunnel' is a circular at best  (it
    >>> references  'pop and forward labels' which are not defined at all.)  --
    >>> I think I understand what the draft is trying to do, but how do I really
    >>> know that my interpretation is right without a formal definition.  On an
    >>> aside, I think the use of 'pop label' is a poor choice as we'll have an
    >>> architecture that allows for a node to 'pop labels' (i.e., the operation
    >>> defined in RCF3031) and a new RFC that adds 'pop labels' which are
    >>> labels whose value indicates that the node should pop the label and
    >>> forwarded out the interface indicated in the label. BTW this functions
    >>> seems similar to egress control discussed in rfc4003.
    >>
    >>
    >> [VPB] Please see if the following tweaks to the terminology section
    >> (remove the “verb” vs “noun” ambiguity) address the above concerns.
    >> We’ll fix all occurrences of these terms in the rest of the document.
    >>
    >> **
    >> A pop-label:   An incoming label at an LSR that will be popped by the
    >> LSR with the packet being forwarded over a specific outgoing TE link
    >> to a neighbor.
    >
    > How about just avoiding the well established verb altogether? Perhaps
    > "interface label", "TE link label" or even "shared label"?
    >
    
    [Pavan] We (the authors) aren't too particular about the terms that
    are currently being used in the document. We will be ok with whatever
    terms the WG agrees upon. Personally, I think the terms pop-label and
    swap-label make the operational intent explicit and help make the
    document a better read. That said, I would be ok with "TE link label".

    >>
    >> A swap-label:   An incoming label at a LSR that will be swapped to an
    >> outgoing label with the packet being forwarded over a specific
    >> outgoing TE link to a neighbor.
    >
    > isn't this just a "label"?
    >
    
    [Pavan] Yes, this is just the traditional swap-label. There are
    several places in the document where we refer to this type of label --
    so it seemed useful to define a "term" for this at the beginning and
    use it in the rest of the document.
    
    >>
    >> RSVP-TE pop-and-forward tunnel:   An MPLS RSVP-TE tunnel that requests
    >> the use of a pop-label on every hop of the LSP.
    >>
    > I think we can circle back to this after resolving pop-label.  I do
    > think your title is clear and perhaps there's something that can serve
    > as a short hand of that, maybe "Shared Forwarding TE-Tunnel" or "Segment
    > Routing TE Tunnel"?
    >
    >> Pop-and-forward data plane:   A forwarding plane where every
    >> participating LSR uses pop-labels on every LSP.
    >> **
    > I have the same basic comment here as the previous one.
    >
    >>
    >>>
    >>> - In writing this mail, it occurs to me that the addition of this
    >>> function is really an update to RFC3031 defined function and those
    >>> changes should be explicitly and formally described.
    >>
    >> [VPB] I believe what you are saying is that the “forward” aspect in
    >> “pop-and-forward” is not discussed in RFC3031. And hence, the need to
    >> formally update RFC3031. We (the authors) would be ok with whatever
    >> the WG deems fit in this regard.
    >
    > I think the draft needs to document how the defined operations fit into
    > 3031 or how they extend / update 3031.
    >

    > Lou
    >
    >>
    >>>
    >>> Lou
    >>>
    >>> On 10/14/2017 11:20 AM, Loa Andersson wrote:
    >>>> 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 ([email-masked]). 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
    >>>
    >>> _______________________________________________
    >>> mpls mailing list
    >>> [email-masked]
    >>> https://www.ietf.org/mailman/listinfo/mpls
    >>
    >

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Fri, 3 Nov 2017 08:02:46 +0000

Hi Pavan,

Sorry for the delay in response. Please see inline:

> From: Vishnu Pavan Beeram [mailto:[email-masked]]
> Sent: Monday, October 23, 2017 10:49 PM
> To: Dongjie (Jimmy) <[email-masked]>
> Cc: Loa Andersson <[email-masked]>; [email-masked]; <[email-masked]>
> <[email-masked]>; [email-masked];
> [email-masked]
> 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) <[email-masked]>
> 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.

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

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. 

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?

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. 

I think all of the above can be done after the adoption. 

Best regards,
Jie

> 
> >
> > It would be great if the above concerns could be considered either before or
> after the adoption.
> >
> > Best regards,
> > Jie
> >
> > From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> > Sent: Saturday, October 14, 2017 11:20 PM
> > To: [email-masked]
> > Cc: <[email-masked]>;
> > [email-masked]; [email-masked]
> > Subject: [mpls] working group adoption poll on
> > draft-sitaraman-mpls-rsvp-shared-labels
> >
> > Working Group,
> >
> > Please send your comments (support/not support) to the mpls working group
> mailing list ([email-masked]). 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.
> >
> > --
> > Loa Andersson                        email: [email-masked]
> > Senior MPLS Expert
> > Huawei Technologies (consultant)     phone: +46 739 81 21 64
> >

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 3 Nov 2017 13:04:37 -0400

Jie, Hi!

Thanks for the follow-up. Please see inline.

Regards,
-Pavan

On Fri, Nov 3, 2017 at 4:02 AM, Dongjie (Jimmy) <[email-masked]> wrote:

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

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

> group