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

From: [email-masked]
Date: Fri, 31 Jul 2015 17:33:54 +0800

Hi Eric,

Eric C Rosen <[email-masked]> 写于 2015/07/30 23:24:24:

> On 7/30/2015 5:42 AM, [email-masked] wrote:
> 
> >      Refer to RFC5331, the context-specific label can be auto 
generated or
> > manually configured. In IPv6 environment, manually control is 
required.
> 
> Are you referring to Section 8 of RFC 5331, "Context Label on LANs"? 
> The labels discussed there are 20-bit values that uniquely identify a 
> router within the context of a particular LAN.  These are really a form 
> of domain-wide label, with the "domain" being a single LAN.  As I said 
> earlier, your draft really seems aimed at the problem of dynamically 
> assigning domain-wide unique labels, so I would agree that assigning 
> context labels on LANs is a possible application.
> 
> Note that the material from Section 8 of RFC 5331 is only applicable if 
> you are using ethernet multicast frames to carry MPLS multicast packets. 

>   I'm not sure whether there are actually any deployments of that.
> 
> > And the network service that is supposed by L3VPN, not only include 
MVPN,
> > but also include EVPN, DC interconnection, and so on.
> 
> The LAN context label only identifies a router, it is not 
> service-specific.  So you only need one per node per LAN.    (I think 
> it's a lot like a "node SID" in SPRING or a "BFIR-id" in BIER.)
> 
---I don't think that the context label is a lot like SID or BFR-id. The 
context 
label can be used to distinguish the service, such like MVPN, EVPN, DC 
interconnection, VxLAN and so on. So only one context label identifies a 
router
is not enough. More context labels are needed for different services on a 
router.

> The issue of how best to assign an identifier that is unique within a 
> certain scope is an issue that comes up in many contexts, though usually 

> it is IP addresses rather than 20-bit identifiers that need to be 
> assigned.  There are a lot of prior solutions that could be considered, 
> generally not requiring either BGP or time synchronization.
> 
> > 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?
> 
> MVPN extranet does not impose any particular requirement for 
> upstream-assigned labels or domain-wide labels.

---The different flows share one P-tunnel, that will decrease the number 
of P-tunnels.
And it will make more easier for service and policy deployment of 
operators. Maybe MVPN
extranet should consider the use of upstream-assigned labels. 

Sandy

---

From: Eric C Rosen <[email-masked]>
Date: Fri, 31 Jul 2015 11:34:56 -0400

> The different flows share one P-tunnel, that will decrease the
> number of P-tunnels. And it will make more easier for service and
> policy deployment of operators. Maybe MVPN extranet should consider
> the use of upstream-assigned labels.

Per draft-ietf-bess-mvpn-extranet, multiple flows can already share a
single P-tunnel, without the use of upstream-assigned labels.

As discussed, in MVPN, when upstream-assigned labels are used, the
tunnel provides the context for the upstream-assigned label, so there is
no issue of collisions when selecting a "context label".  (In MVPN/BIER, 
the BFIR-id provides the context.)

> The context label can be used to distinguish the service, such like
> MVPN, EVPN, DC interconnection, VxLAN and so on. So only one context
> label identifies a router is not enough. More context labels are
> needed for different services on a router

You mentioned RFC 5331, but there is no suggestion in that RFC that the 
routers on a LAN need multiple context labels per LAN.

It is certainly conceivable that there is a problem whose solution 
requires the dynamic assignment of domain-wide unique labels.  If we 
were trying to solve such a problem, your solution might be one of the 
alternatives to be considered.  Right now, I don't really see what more 
can be said about it.