Subject: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution

From: Eric C Rosen <[email-masked]>
Date: Mon, 20 Jul 2015 11:23:17 -0400

I see that draft-zhang-idr-upstream-assigned-label-solution ("Upstream 
Assigned Label Collision Solution") is on the IDR agenda, so I'd like to 
make a comment.

The draft talks about the use of "upstream-assigned labels" in the MVPN 
application, and discusses the problem of "collisions" when multiple 
routers independently assign upstream-assigned labels.

However, collisions in the assignment of upstream-assigned labels are 
not possible, because every router assigns them from its own 20-bit 
per-router label space.  Thus every assignment is unique in the context 
of the router that made the assignment.  In the MVPN application, if a 
multicast data packet is carrying an upstream-assigned label and is 
traveling on a P2MP LSP, the packet will have at least two labels.  The 
top label, probably assigned by mLDP or RSVP-TE-P2MP, is an ordinary 
downstream-assigned label that identifies the P2MP LSP.  The 
upstream-assigned label would be the second label.  The 
upstream-assigned label is always assigned by the router that is the 
root of the P2MP LSP.  Thus one can infer from the top label the 
identity of the router that assigned the second label.  Since the top 
label provides the context in which the second label is interpreted, no 
ambiguity (or collision) is possible, and there is no need to introduce 
procedures to coordinate label assignment among the routers.

I suspect the authors are really thinking about "domain-wide labels", 
where multiple routers have to interpret labels from a single label 
space.  If multiple routers are independently and dynamically assigning 
labels from a single label space, collisions are of course possible. 
But this is not a problem for an application, like MVPN, that doesn't 
use domain-wide labels.

By the way, IDR actually doesn't seem like the most appropriate WG for 
this topic; I'd have thought it more relevant to MPLS, BESS, or SPRING.

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 24 Jul 2015 03:57:02 -0400

Eric: 

Thank you for your feedback on this draft.   I look forward to the author's
response to you.  

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Monday, July 20, 2015 11:23 AM
To: IDR WG
Subject: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution

The draft talks about the use of "upstream-assigned labels" in the MVPN
application, and discusses the problem of "collisions" when multiple routers
independently assign upstream-assigned labels.

However, collisions in the assignment of upstream-assigned labels are not
possible, because every router assigns them from its own 20-bit per-router
label space.  Thus every assignment is unique in the context of the router
that made the assignment.  In the MVPN application, if a multicast data
packet is carrying an upstream-assigned label and is traveling on a P2MP
LSP, the packet will have at least two labels.  The top label, probably
assigned by mLDP or RSVP-TE-P2MP, is an ordinary downstream-assigned label
that identifies the P2MP LSP.  The upstream-assigned label would be the
second label.  The upstream-assigned label is always assigned by the router
that is the root of the P2MP LSP.  Thus one can infer from the top label the
identity of the router that assigned the second label.  Since the top label
provides the context in which the second label is interpreted, no ambiguity
(or collision) is possible, and there is no need to introduce procedures to
coordinate label assignment among the routers.

I suspect the authors are really thinking about "domain-wide labels", where
multiple routers have to interpret labels from a single label space.  If
multiple routers are independently and dynamically assigning labels from a
single label space, collisions are of course possible. 
But this is not a problem for an application, like MVPN, that doesn't use
domain-wide labels.

By the way, IDR actually doesn't seem like the most appropriate WG for this
topic; I'd have thought it more relevant to MPLS, BESS, or SPRING.

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: [email-masked]
Date: Sun, 26 Jul 2015 00:45:33 +0800

Hi Rosen, hi Sue,

    Thanks for reading of the draft. These scenes that are mentioned
by Rosen are not cover all situations.

    Routers forward MVPN flows by P2MP LSP, but also routers
can forward MVPN flows by MP2MP LSP. And as soon as routers mix several
MVPN flows into a single LSP, collision will happen, and it will
influence data forwarding.
 
    So I think it is still a problem, isn't it? further discussion is 
welcomed.
    Thanks!

Sandy

"Idr" <[email-masked]> 写于 2015-07-24 下午 03:57:02:

> "Susan Hares" <[email-masked]> 
> 发件人:  "Idr" <[email-masked]>
> 
> 2015-07-24 下午 03:57
> 
> 收件人
> 
> "'Eric C Rosen'" <[email-masked]>, "'IDR WG'" <[email-masked]>, 
> 
> 抄送
> 
> 主题
> 
> Re: [Idr] Comment on draft-zhang-idr-upstream-assigned-label-solution
> 
> Eric: 
> 
> Subject: [Idr] Comment on 
draft-zhang-idr-upstream-assigned-label-solution
> application, and discusses the problem of "collisions" when multiple 
routers
> However, collisions in the assignment of upstream-assigned labels are 
not
> identity of the router that assigned the second label.  Since the top 
label
> I suspect the authors are really thinking about "domain-wide labels", 
where
> But this is not a problem for an application, like MVPN, that doesn't 
use
> By the way, IDR actually doesn't seem like the most appropriate WG for 
this

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 24 Jul 2015 15:24:02 -0400

> influence data forwarding.

An MP2MP LSP has a single root node, and that root node would be 
responsible for assigning any upstream-assigned labels that are used 
within that LSP.

Just for clarity, the upstream-assigned label in the PMSI Tunnel 
attribute is not needed when multiple flows are being transmitted on a 
single LSP, it is needed only when flows from multiple VPNs are are 
transmitted on a single LSP.  I have to admit that using a single MP2MP 
LSP to carry traffic of several different VPNs is not a scenario that 
has been given a lot of attention, and will probably only work if (a) 
the hierarchical partitioned method (see RFC 7582) is used, and (b) all 
those VPNs have VRFs at the root node.  But it's not clear that there's 
any real value to multiplexing several VPNs onto a single MP2MP LSP.

There is another use of upstream-assigned labels described in RFC 7582 
("PE Distinguisher labels"), and those are always assigned by the root 
node of the MP2MP LSP.

---

From: [email-masked]
Date: Thu, 30 Jul 2015 17:42:53 +0800

Hi Eric,

    Refer to RFC5331, the context-specific label can be auto generated or 
manually configured. In IPv6 environment, manually control is required. 
And the network service that is supposed by L3VPN, not only include MVPN, 
but also include EVPN, DC interconnection, and so on. For the use of 
upstream assigned label, the Context-Specific label need a label range 
space. It is difficult to control manually, especially for the abundance 
of services. So the label space may have a collision. Even if the 
context-specific label is taken by p2mp or mp2mp tunnel, there may 
have a collision.

    And the p2mp and mp2mp tunnel may be used to transfer extranet flow. 
When 
different multicast flows which are forwarded to receivers in different 
VPN 
are mixed into one P-tunnel, are there more conflict?

Sandy

---

From: [email-masked]
Date: Thu, 30 Jul 2015 17:43:20 +0800

Hi Eric,

Sandy