s/inter-area/intra-area/g
From: Xiejingrong
Sent: Thursday, December 13, 2018 10:22 AM
To: 'Jeffrey (Zhaohui) Zhang' <[email protected]>;
[email protected]; [email protected]
Subject: RE: Poll for early allocation request for
draft-ietf-bess-mvpn-evpn-aggregation-label
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 protected]]
Sent: Wednesday, December 12, 2018 10:42 PM
To: Xiejingrong <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Subject: RE: Poll for early allocation request for
draft-ietf-bess-mvpn-evpn-aggregation-label
Jingrong,
Please see zzh> below.
From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of
Xiejingrong
Sent: Tuesday, December 11, 2018 8:14 PM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
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.
I remember I have raised my concerns, but I didn't find the response.
Zzh> Sorry for missing those. Please see below.
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.
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 protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Tuesday, December 11, 2018 11:10 PM
To: [email protected]<mailto:[email protected]>
Subject: [bess] Poll for early allocation request for
draft-ietf-bess-mvpn-evpn-aggregation-label
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.
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
