Subject: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

From: <[email-masked]>
Date: Tue, 11 Dec 2018 15:09:34 +0000

Hi WG,

We have received an early allocation request for the draft-ietf-bess-mvpn-evpn-aggregation-label.

Please raise your concerns if you object to this request and if you think that the document is not mature enough.
Feel also free to support this request.

We will wait until next Monday (12/17) to gather feedbacks.

Thanks,

Stephane

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 11 Dec 2018 16:19:54 +0000

Stephane, and all,
Support.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   [email-masked]

From: BESS <[email-masked]> On Behalf Of [email-masked]
Sent: Tuesday, December 11, 2018 5:10 PM
To: [email-masked]
Subject: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

Thanks,

Stephane

Thank you.

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: Xiejingrong <[email-masked]>
Date: Wed, 12 Dec 2018 01:13:32 +0000

Objection.

I remember I have raised my concerns, but I didn't find the response.

Copy the concerns I have listed before:
1.      The problem stated by this draft is valid, and the proposed method is useful for some of the listed problem. For example, EVPN BUM who uses MPLS identification and dataplane.
2.      EVPN BUM using vxlan/vni identification may not need a MPLS label to identify the vpn/tenant.
3.      For MVPN who has a UMH(Upstream Multicast Hop) selection procedure, the exist using of upstream-assigned VpnLabel can be optimized to only populate to forwarding-state when there are c-multicast flows selecting the specific UMH PE.
4.      For an End-to-End deployment of MVPN who spans multi-ASes as the way stated in <draft-geng-bier-sr-multicast-deployment>, the allocation of a global-unique label is useful and possible. But operators may need to be very careful to allocate the very limited MPLS labels. Because, MPLS labels has been divided to SRLB and SRGB, and SRGB may have been again divided by SR-domains according to <draft-filsfils-spring-large-scale-interconnect-12>.
5.      For segmented MVPN deployment, the further divide of the MPLS Label is also difficult when thinking of the above.
6.      For BIER, is the BIER proto=1 indicating a BIER-specific unique VpnLabel ? or a Per-platform (RFC5331) downstream-assigned unique label ?  if it is the later one, how about adding a new BIER proto value to indicating a BIER-specific unique VpnLabel ?  And then a static Context (BIER) can be optional to the dynamic advertising of a Context ?

Jingrong

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 11, 2018 11:10 PM
To: [email-masked]
Subject: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

Thanks,

Stephane

Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 12 Dec 2018 14:41:53 +0000

Jingrong,

Please see zzh> below.

From: BESS <[email-masked]> On Behalf Of Xiejingrong
Sent: Tuesday, December 11, 2018 8:14 PM
To: [email-masked]; [email-masked]
Subject: Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Objection.

Zzh> Please note that this is not a LC for the draft. This is the poll for early allocation for the DCB-flag and an extended community type.

Zzh> Sorry for missing those. Please see below.

1.   The problem stated by this draft is valid, and the proposed method is useful for some of the listed problem. For example, EVPN BUM who uses MPLS identification and dataplane.
Zzh> Do you think the proposed solution is reasonable for the problems? If so, we would like to see early allocation is done. The allocation is temporary - it would time out after some time if the draft does not become a RFC.

2.   EVPN BUM using vxlan/vni identification may not need a MPLS label to identify the vpn/tenant.
Zzh> The draft is about "aggregation label", so vxlan/vni is irrelevant. On the other hand, in case of vxlan/vni, the VNI is no different from a DCB label in concept (so the solution of using DCB label should be reasonable).

3.   For MVPN who has a UMH(Upstream Multicast Hop) selection procedure, the exist using of upstream-assigned VpnLabel can be optimized to only populate to forwarding-state when there are c-multicast flows selecting the specific UMH PE.
Zzh> If that is a better solution, perhaps a separate draft can be written. The solution in this draft is simpler and in concept no different from vxlan case.

4.   For an End-to-End deployment of MVPN who spans multi-ASes as the way stated in <draft-geng-bier-sr-multicast-deployment>, the allocation of a global-unique label is useful and possible. But operators may need to be very careful to allocate the very limited MPLS labels. Because, MPLS labels has been divided to SRLB and SRGB, and SRGB may have been again divided by SR-domains according to <draft-filsfils-spring-large-scale-interconnect-12>.
Zzh> What's relevant here is the second part of your text above (the "But operators ...") - though that is the same point #5 below (please see my response below).

5.   For segmented MVPN deployment, the further divide of the MPLS Label is also difficult when thinking of the above.
Zzh> Please see section 2.2.2 of this draft.

6.   For BIER, is the BIER proto=1 indicating a BIER-specific unique VpnLabel ? or a Per-platform (RFC5331) downstream-assigned unique label ?  if it is the later one, how about adding a new BIER proto value to indicating a BIER-specific unique VpnLabel ?  And then a static Context (BIER) can be optional to the dynamic advertising of a Context ?
Zzh> In BIER header, proto=1 indicates downstream-assigned label. There is no need to define a new BIER specific proto value. The reason is that "downstream-assigned label" just means that it is a label in the "main/default" label space of the receiving router, and a DCB label is just that. Nothing is BIER specific here. I believe Tony also responded to you (and in BIER WG).
Zzh> Thanks!
Zzh> Jeffrey

Jingrong

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Tuesday, December 11, 2018 11:10 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

Thanks,

Stephane

Thank you.

---

From: Xiejingrong <[email-masked]>
Date: Thu, 13 Dec 2018 02:22:30 +0000

Hi Jeffrey,

Let me take the section 2.2.3 for explaination:

   In summary, labels can be allocated and advertised the following
   ways:

   1.  A central authority allocates per-VPN/BD/ES labels from the DCB.
       PEs advertise the labels with an indication that they are from
       the DCB.

   2.  A central authority allocates per-VPN/BD/ES labels from a few
       common context label spaces, and allocate labels from the DCB to
       identify those context label spaces.  PEs advertise the VPN/BD
       labels along with the context-identifying labels.

   3.  A central authority assigns disjoint label blocks from those a //
       few context label spaces to each PE, and allocate labels from the
       DCB to identify the context label spaces.  Each PE allocates
       labels from its assigned label block independently for its
       segmented S-PMSI, along with the context-identifying labels.

   Option 1 is simplest, but it requires that all the PEs set aside a
   common label block for the DCB that is large enough for all the
   VPNs/BDs/ESes combined.  Option 3 is needed only for segmented
   selective tunnels that are set up dynamically.  Multiple options
   could be used in any combination depending on the deployment
   situation.

Option-1 is simplest and I like it very much (anyone who don't like simplification?). For Inter-area EVPN deployment scenarios, it is strong and simple enough I think.
But when it is not the suitable case, and Option-2 has to be used, I think things are becoming complex: You still need a DCB from 'main/default' label-space, though this DCB is very small, which maybe only include ONE label. And then the ONE label is used as 'context-label'. While for BIER case, BIER header itself can act as a 'BIER-Context' naturally. Am I understanding correctly ?
For Option-3, I do understand it as two sub-options, Option-3a if there is enough number of Labels in the DCB, and Option-3b if there isn't and the ONE 'DCB' label is used as context-label. Each one is difficult for me to consider the development and deployment. One the other hand, the segmented MVPN can use the 'UMH' mechanism to select the right upstream-assigned VpnLabel to download to forwarding states.

So my summarized comments:
DCB is similar to VNI very much, but the MPLS labels in the "main/default" space is very costly due to the 'per-platform' (RFC5331) allocation.
DCB is similar to SRGB very much, but DCB requires 'absolute' unique value other than the 'unique' index in SRGB(at least has such mechanism).
Use of context-label from a DCB can be comparable to the use of the 'BIER-specific' context in case of BIER.
Use of 'dynamic' allocation with DCB mechanism in segmented MVPN deployment may add extra complexity.

I suggest this draft to make more clear what the use cases are, what it really want to solve, and what it don't.

Thanks.
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Jingrong,

Please see zzh> below.

From: BESS <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong
Sent: Tuesday, December 11, 2018 8:14 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: Xiejingrong <[email-masked]>
Date: Thu, 13 Dec 2018 02:24:01 +0000

s/inter-area/intra-area/g

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Thanks.
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: <[email-masked]>
Date: Thu, 13 Dec 2018 08:40:27 +0000

Hi Jingrong,

Speaking as co-chair, what I need to know from this discussion is if there is a blocking point for the early allocation.
Yes, of course the draft will require some polishing, clarifications... as Jeffrey has mentioned, this is not a WGLC.

Based on your last sentence (and the overall discussion), I don't see any real blocking point but I want this to be crystal clear. So please state clearly if you object to the early allocation or not and why. What is important to me is to ensure that the encoding is stable and does not require any change.

Thanks,

Stephane

From: BESS [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Thursday, December 13, 2018 03:24
To: Jeffrey (Zhaohui) Zhang; LITKOWSKI Stephane OBS/OINIS; [email-masked]
Subject: Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

From: Xiejingrong

Hi Jeffrey,

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 13 Dec 2018 14:31:57 +0000

Hi Jingrong,

Please see zzh2> below.

From: BESS <[email-masked]> On Behalf Of Xiejingrong
Sent: Wednesday, December 12, 2018 9:24 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Zzh2> So I assume you're not objecting to the early allocation for DCB-flag at least?

Zzh2> Nowadays with the adoption of SR, allocating SAME SRGBs across routers is not difficult and is the preferred way. If you use DCB (could just be the SRGB itself) for non-segmented case, what's the concern with allocating a context label from the DCB/SRGB? See later comment about BIER-context.

Zzh2> There is no 3a. There could be multiple DCB labels for multiple context label spaces, either because of scaling requirement (in theory) or for whatever reason an operator wants to use multiple.
Zzh2> I don't think selectively installing upstream assigned labels based on UMH is good enough (and it introduces more complexity). The sources could be everywhere, and in case of EVPN, the forwarding could be (*,g) based, so you'll end up with the original problem.

Zzh2> If one can do common SRGB for SR, then one can do DCB for MVPN/EVPN. If you're still concerned with that, you can have a separate context label space for EVPN/MVPN purpose, with the context label from the DCB/SRGB. I don't want to tie it to BIER only though, because the problem and solution equally applies to P2MP tunnels.

Zzh2> Practically, operators strongly desire to use common SRGBs. Vendors had resisted the push for using common SRGBs but now have given up.

Zzh2> There is no need, and it is not desired to have a BIER-specific context. Besides, defining a new BIER header's "proto" value to indicate a subsequent context label space should first be discussed in BIER WG; if that passes, then we come back to (or at least involve) BESS WG to enhance MVPN/EVPN signaling so that every PE knows where to allocate labels and where to install forwarding state.

Zzh2> Compared to existing method of using upstream assigned labels, what is the complexity? Upstream assigned labels are assigned from the assigner's main/default label space; the "dynamic" allocation scheme in option-3 allocates from a label block (of a context label space identified by a DCB label) assigned to the assigner. If the need to maintain that extra label block information is complicated, wouldn't it be more complicated to selectively install upstream-assigned labels based on UMH selection (forget about that it would not work all the time)?

Zzh> If that is not convincing enough, what is a better solution? I know you have proposed doing IP lookup - we discussed in a separate thread on the pros/cons of that and we're working together on a separate draft on that, right? I also have a short section 2.2.2.3 on that.

Zzh2> The use cases and problem domains are discussed in section 2.1, and more complicated scenarios are followed-up in section 2.2.
Zzh2> About "what it don't" - can you point out the areas that you think this draft should cover or explicitly declare out of scope?
Zzh2> Thanks.
Zzh2> Jeffrey

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: Xiejingrong <[email-masked]>
Date: Fri, 14 Dec 2018 07:10:20 +0000

Hi Jeffrey,

Please see xjr3>> below.

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Thursday, December 13, 2018 10:32 PM
To: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jingrong,

Please see zzh2> below.

From: BESS <[email-masked]<mailto:[email-masked]>> On Behalf Of Xiejingrong
Sent: Wednesday, December 12, 2018 9:24 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

From: Xiejingrong

Hi Jeffrey,

Zzh2> So I assume you're not objecting to the early allocation for DCB-flag at least?
XJR3>> I don't understand how a DCB-flag in PTA is necessary in opinion-1.  Does it used to do consistency check ?

Zzh2> Nowadays with the adoption of SR, allocating SAME SRGBs across routers is not difficult and is the preferred way. If you use DCB (could just be the SRGB itself) for non-segmented case, what's the concern with allocating a context label from the DCB/SRGB? See later comment about BIER-context.
XJR3>> OK for non-segmented case (mainly intra-area, at least intra-AS case).

Zzh2> There is no 3a. There could be multiple DCB labels for multiple context label spaces, either because of scaling requirement (in theory) or for whatever reason an operator wants to use multiple.
Zzh2> I don't think selectively installing upstream assigned labels based on UMH is good enough (and it introduces more complexity). The sources could be everywhere, and in case of EVPN, the forwarding could be (*,g) based, so you'll end up with the original problem.
XJR3>> OK. Thanks for the clarification.
XJR3>> For segmented case stated in this opinion, the section 2.2.2.1 stated that, it does not address the original scaling issue.

Zzh2> If one can do common SRGB for SR, then one can do DCB for MVPN/EVPN. If you're still concerned with that, you can have a separate context label space for EVPN/MVPN purpose, with the context label from the DCB/SRGB. I don't want to tie it to BIER only though, because the problem and solution equally applies to P2MP tunnels.
XJR3>> Yes, good enough to use in intra-AS/intra-area cases for DCB/SRGB. For Inter-area/inter-AS case, I hope it can to help non-segmented MVPN deployment but I am worrying about that.

Zzh2> Practically, operators strongly desire to use common SRGBs. Vendors had resisted the push for using common SRGBs but now have given up.
XJR3>> I guess the acceptance of SRGB may not occur if the "safety belt" is not invented. Anyway, I feel worried that, even a small DCB block can be difficult in case out of intra-AS/intra-area scope.

Zzh2> There is no need, and it is not desired to have a BIER-specific context. Besides, defining a new BIER header's "proto" value to indicate a subsequent context label space should first be discussed in BIER WG; if that passes, then we come back to (or at least involve) BESS WG to enhance MVPN/EVPN signaling so that every PE knows where to allocate labels and where to install forwarding state.
XJR3>> OK.  BIER has the proto field for easily extending, we can move this discussion to BIER or personally.

Zzh2> Compared to existing method of using upstream assigned labels, what is the complexity? Upstream assigned labels are assigned from the assigner's main/default label space; the "dynamic" allocation scheme in option-3 allocates from a label block (of a context label space identified by a DCB label) assigned to the assigner. If the need to maintain that extra label block information is complicated, wouldn't it be more complicated to selectively install upstream-assigned labels based on UMH selection (forget about that it would not work all the time)?
XJR3>> For non-segmented aggregrated-P2MP or MP2MP deployment, I was convinced to believe it is useful even introducing the extra protocol extension (see IANA part of the draft).
XJR3>> If I understand correctly, the data-plane also have some change too. A VPN need to be identified by a DCB-context-label (to identify the following label is not from a main/default space), and a following COMMON vpn label. It is not common in current MPLS world and may need some change in data-plane.

Zzh> If that is not convincing enough, what is a better solution? I know you have proposed doing IP lookup - we discussed in a separate thread on the pros/cons of that and we're working together on a separate draft on that, right? I also have a short section 2.2.2.3 on that.
XJR3>> I am not convinced to follow the DCB-context-label for BIER or for Segmented MVPN case.

XJR3>> the section 2.2.2.1 stated that, "it does not address the original scaling issue". I just feel that, the draft can remove the segmented case out of the DCB-context-label solution if it does not match well (though it may work).
XJR3>> So does the case of MVPN/EVPN using BIER.
XJR3>> Thanks.
XJR3>> Jingrong

Zzh2> Thanks.
Zzh2> Jeffrey

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: Xiejingrong <[email-masked]>
Date: Fri, 14 Dec 2018 07:19:38 +0000

Hi Stephane,

Thank you for raising the meaningful discussion on this draft.

I am not against the early allocation, because the allocation needed by the DCB-context-label can help the aggregated  P2MP/MP2MP for MVPN/EVPN as an extension to the current RFC6513.

I am not convinced to follow the DCB-context-label for BIER/SegmentedMVPN cases,  but this can be discussed later.

Thanks,
Jingrong.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 13, 2018 4:40 PM
To: Xiejingrong <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jingrong,

Thanks,

Stephane

From: BESS [mailto:[email-masked]] On Behalf Of Xiejingrong
Sent: Thursday, December 13, 2018 03:24
To: Jeffrey (Zhaohui) Zhang; LITKOWSKI Stephane OBS/OINIS; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

From: Xiejingrong

Hi Jeffrey,

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 14 Dec 2018 15:10:08 +0000

Please see zzh3> below.

From: Xiejingrong <[email-masked]>
Sent: Friday, December 14, 2018 2:10 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Please see xjr3>> below.

Hi Jingrong,

Please see zzh2> below.

From: Xiejingrong

Hi Jeffrey,

Zzh3> If you don't carry that flag, how do you know if the label is upstream assigned or from the DCB?

Zzh3> Let's walk through these steps:
Zzh3> 1) Even in the non-segmented case, you're concerned that it may not be easy to allocate a common DCB across all routers. If that's a real concern, you can have a separate context label space (or even a few of them) shared by all PEs (instead of one context label space for every ingress PE). Those context label spaces can be identified by the context labels allocated from a smaller DCB. That's the rational for the "Context Label Space ID" Extended Community. While using a few context label spaces still requires a router to implement infrastructure for context label spaces, it is better to only need to support a few context label spaces than having to scale to thousands of context label spaces.
Zzh3> 2) In segmented case, while you still need one label for each S-PMSI, using a few context label spaces is better than having to scale to thousands of context label spaces - see 1) above.

Zzh3> It's not intra-AS/area vs. inter-AS/area. It's non-segmented vs. segmented. When there is no segmentation, you don't need to allocate different labels for each S-PMSI so DCB may be large enough. When there is segmentation you have to allocate different labels for different S-PMSI, so if DCB is not big enough, you can use context label spaces identified by DCB labels.
Zzh3> I would not worry about allocating DCB across AS boundary in case of non-segmentation - if you do not need to segmentation across AS boundary, most likely the ASes belong to the same operator or the operators are friendly enough to work out a DCB.

Zzh3> Common SRGB is a fact nowadays.
Zzh3> What better "safety belt" do you need/envision than using a few context label spaces? If you worry about the practicality of a small DCB block across many PEs, do you not worry about PEs scaling up to thousands of context label spaces (that are needed for upstream assigned labels)?

Zzh3> There is nothing special here. In the upstream assigned case, the base tunnel label (from the data-receiving router's main/default label space) tells you which context label space to look up the next label (that identifies the VPN/BD/ES in our case). Here, the DCB context label (also from the data-receiving router's main/default label space) tells you which context label space to use for the next label lookup.

Zzh> If that is not convincing enough, what is a better solution? I know you have proposed doing IP lookup - we discussed in a separate thread on the pros/cons of that and we're working together on a separate draft on that, right? I also have a short section 2.2.2.3 on that.
XJR3>> I am not convinced to follow the DCB-context-label for BIER or for Segmented MVPN case.
Zzh3> I hope the responses above help.

Zzh3> We have to discuss the issue with the segmentation (otherwise one may ask "what about segmentation") and we give the best solution so far. I can add "better/other solutions are beyond the scope of this document" if you want J

Zzh3> The spec starts discussing the issue using the BIER example; it also points out the issue is not unique with BIER (though it's most acute with BIER). The solution works for BIER as well as P2MP tunnel aggregation (I also have alluded to the applicability for IR though the text has not been published). In particular, the specification/procedures part has nothing BIER specific. What's wrong with that?
Zzh3> Thanks.
Zzh3> Jeffrey

XJR3>> Thanks.
XJR3>> Jingrong

Zzh2> Thanks.
Zzh2> Jeffrey

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: Xiejingrong <[email-masked]>
Date: Mon, 17 Dec 2018 04:02:00 +0000

Hi Jeffrey,

Thanks for clarifying that there is nothing special on data-plane comparing to the Upstream-assigned label following a P2MP label as mentioned in RFC6513. It help me much.

About the case (maybe the worst case) when it is difficult to allocate a 'domain-wide unique' DCB-context-label,
do you think it helpful for an allocation of 'reserved' label (value from 0 to 15) to represent a 'Context-label' to make the interoperability mandatory ?

Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: Friday, December 14, 2018 11:10 PM
To: Xiejingrong <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Please see zzh3> below.

From: Xiejingrong <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 14, 2018 2:10 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Please see xjr3>> below.

Hi Jingrong,

Please see zzh2> below.

From: Xiejingrong

Hi Jeffrey,

Zzh3> We have to discuss the issue with the segmentation (otherwise one may ask "what about segmentation") and we give the best solution so far. I can add "better/other solutions are beyond the scope of this document" if you want :)

XJR3>> Thanks.
XJR3>> Jingrong

Zzh2> Thanks.
Zzh2> Jeffrey

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

---

From: <[email-masked]>
Date: Mon, 17 Dec 2018 10:46:44 +0000

Thanks for the clarification.

From: Xiejingrong [mailto:[email-masked]]
Sent: Friday, December 14, 2018 08:20
To: LITKOWSKI Stephane OBS/OINIS; Jeffrey (Zhaohui) Zhang; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Stephane,

Thanks,
Jingrong.

Hi Jingrong,

Thanks,

Stephane

From: Xiejingrong

Hi Jeffrey,

Thanks.
Jingrong

Jingrong,

Please see zzh> below.

Objection.

Jingrong

Hi WG,

Thanks,

Stephane

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Mon, 17 Dec 2018 13:22:22 +0000

Hi,

This poll is closed now.
It seems that some discussions are required on the document, however it has been confirmed that nothing blocks the early allocation request.
I'm requesting the approval from our AD now.

Brgds,

From: BESS [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, December 11, 2018 16:10
To: [email-masked]
Subject: [bess] Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi WG,

Thanks,

Stephane

Thank you.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 17 Dec 2018 13:18:15 +0000

Hi Jingrong,

Allocating a special label from the 0~15 block is super difficult. I don't think our use case is strong enough for that.

Thanks.
Jeffrey

From: Xiejingrong <[email-masked]>
Sent: Sunday, December 16, 2018 11:02 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: Poll for early allocation request for draft-ietf-bess-mvpn-evpn-aggregation-label

Hi Jeffrey,

Jingrong