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

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 <lberger@labn.net> 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.

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

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.

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.

Pop-and-forward data plane:   A forwarding plane where every
participating LSR uses pop-labels on every LSP.
**

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

>
> 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 (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
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls