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

[Lou Berger <[e-mail]>]

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 <[e-mail]> 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.

> 
>>
>> - 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"?

> 
> 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"?

> 
> 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 ([e-mail]). 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>