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

From: Loa Andersson <[email-masked]>
Date: Sat, 14 Oct 2017 17:20:28 +0200

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

Loa Andersson                        email: [email-masked]
Senior MPLS Expert
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Stewart Bryant <[email-masked]>
Date: Sun, 15 Oct 2017 12:42:41 +0100

Support, is a useful function.

Stewart

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 15 Oct 2017 14:46:18 +0100

Hi Loa,

I've reviewed this draft as it progressed, and I supplied some comments along
the way.

The draft covers an important and useful function and it would be good to move
it through the working group.

I support adoption.

Adrian
--
Support an author and your imagination
Tales from the Wood - Eighteen new fairy tales
More Tales from the Wood - Eighteen MORE new fairy tales
Tales from Beyond the Wood - a bumper collection of twenty-two new tales
https://www.feedaread.com/profiles/8604/
http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924
Or buy from me direct.

> -----Original Message-----
> From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: 14 October 2017 16:20
> To: [email-masked]
> Cc: <[email-masked]>; [email-masked];
mpls-
> [email-masked]
> Subject: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-
> shared-labels
> 
> Working Group,
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Ravi Torvi <[email-masked]>
Date: Sun, 15 Oct 2017 11:40:45 -0400

Support (as a contributor).

Ravi

On Sat, Oct 14, 2017 at 11:20 AM, Loa Andersson <[email-masked]> 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.
>

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Sun, 15 Oct 2017 12:24:55 -0400

I support adoption and would very much like the work to get progressed
through the WG.

This is a very useful addition (as mentioned by others on this thread) to
the Traffic-Engineering toolkit. Compatibility with traditional RSVP-TE
LSPs and the notion of automatic delegation of label-stack imposition make
this a very contemporary tool that can be easily deployed in current TE
networks.

Regards,
-Pavan (as a co-author)

---

From: Harish Sitaraman <[email-masked]>
Date: Sun, 15 Oct 2017 22:15:38 +0000

Support (as an author) for adoption as WG document.

The work is useful to decouple RSVP-TE further from the data plane and allows ease of backwards compatibility in addition to offering a self contained automatic delegation solution.

Harish

---

From: Chandrasekar Ramachandran <[email-masked]>
Date: Mon, 16 Oct 2017 09:06:21 +0000

> Sent: Saturday, October 14, 2017 8:50 PM
> To: [email-masked]
> Cc: <[email-masked]> <[email-masked]>; draft-sitaraman-mpls-rsvp-
> [email-masked]; [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_mpls&d=DwICAg&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=iEQmXlRGWdNbtvVr6ghcatwLYhZUbMF-u63wi_-
> VTtA&m=HDIw1wmhSUmvJHAzBwcIc5BAt66maXTEySzL6n-
> cAWA&s=kUCs8kIA2lzm4qSnsiD6t3QpJOshkcnRy_yvrNYDJuw&e=

---

From: "Parikh, Tejal" <[email-masked]>
Date: Mon, 16 Oct 2017 13:06:02 +0000

I support this draft as it's useful in service provider network.

Regards,
Tejal

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Saturday, October 14, 2017 10:20 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; <[email-masked]>
Subject: [E] 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.

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

/Loa
mpls wg co-chair
--

---

From: Ambrose Kwong <[email-masked]>
Date: Mon, 16 Oct 2017 13:22:31 +0000

Support.

Thanks,
Ambrose

-----Original Message-----
From: mpls [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Saturday, October 14, 2017 11:20 AM
To: [email-masked]
Cc: <[email-masked]> <[email-masked]>; [email-masked]; [email-masked]
Subject: [mpls] working group adoption poll on draft-sitaraman-mpls-rsvp-shared-labels

Working Group,

/Loa
mpls wg co-chair
-- 

_______________________________________________
mpls mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_mpls&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=n-5uAu-GCfqdzn74YkRhjy5vH3XycxLjDUS3d6GPeXU&m=1J-kCtStoGnlphzs8ZxNu3V97gfDF3VsPgLpgevZjaU&s=ktsssf-x0d89W8hVSfc1OL7oIMpGpT97x4FzzINH4xA&e=

---

From: Lou Berger <[email-masked]>
Date: Mon, 16 Oct 2017 13:41:52 -0400

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.

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

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

Lou

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 18 Oct 2017 15:18:28 +0000

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. 

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.

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:[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,

/Loa
mpls wg co-chair
--

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 23 Oct 2017 09:20:33 -0400

Lou, Hi!

Thanks for reviewing this. Please see inline (prefixed VPB) for responses.

Regards,
-Pavan

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

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

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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Mon, 23 Oct 2017 10:48:33 -0400

Jie, Hi!

Thanks for the review and for the support. Please see inline for
responses (prefixed VPB).

Regards,
-Pavan

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

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

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 27 Oct 2017 17:43:40 -0400

Hi Pavan,
	Sorry about the delayed response.  See below.

On 10/23/2017 09:20 AM, Vishnu Pavan Beeram wrote:
> shared-label. 

> Note that using a shared pop-label (albeit a special

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.

> LSR with the packet being forwarded over a specific outgoing TE link

How about just avoiding the well established verb altogether? Perhaps
"interface label", "TE link label" or even "shared label"?

> outgoing TE link to a neighbor.

isn't this just a "label"?

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

> participating LSR uses pop-labels on every LSP. 
I have the same basic comment here as the previous one.

> 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

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Tue, 31 Oct 2017 16:20:53 -0400

Lou, Hi!

Thanks for the feedback!
Please see inline.

Regards,
-Pavan

> couple of sentences above are right on the mark.

[Pavan] Ack. We'll add relevant text to the next version as indicated.

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

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