Hi Antoni, Regarding ETAG value for IMET route, it is set the appropriate VID value (if ETAG is VLAN Tag) just as before. In other words, the ETAG value you use the IMET route is the same as the one you use in MAC/IP route – nothing has changed in this regards.
Cheers, Ali From: Antoni Przygienda <[email protected]<mailto:[email protected]>> Date: Monday, February 2, 2015 at 8:52 AM To: John E Drake <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [bess] suggested AUTH48 changes on EVPN draft John, understood clearer now. As far I thought that through it may be an unnecessary restriction but I see the ‘uniformity’ argument. My (now tad unrelated to this) question as what ETAG the IMET carries still stands (albeit the way I outlined it seems the only logical way to advertise multiple ETAGs on an IMET) --- tony From: John E Drake [mailto:[email protected]] Sent: Monday, February 02, 2015 5:37 AM To: Antoni Przygienda; [email protected]<mailto:[email protected]> Subject: RE: suggested AUTH48 changes on EVPN draft Tony, The change you mention in your email below is editorial, clarifying what was already supported in the encodings but not explicitly described. The technical change is in the last paragraph and deals w/ VLAN Aware Bundle service w/ VID translation. Previously the ingress PE translated from ingress VID to Ethernet Tag and the egress PE translated from Ethernet Tag to egress VID. The change is that the ingress PE does not translate but rather sends the ingress VID and the egress translates from ingress VID to egress VID. This is makes the data plane behavior consistent across all services and both MPLS and VXLAN encapsulations. It requires the egress PE to advertise an MPLS label w/ a granularity of at least [EVI, broadcast domain]. Yours Irrespectively, John From: BESS [mailto:[email protected]] On Behalf Of Antoni Przygienda Sent: Monday, February 02, 2015 1:50 AM To: [email protected]<mailto:[email protected]> Subject: [bess] suggested AUTH48 changes on EVPN draft Having seen Adrian’s email on the suggested changes (mux’ing VLANs on the same IMET) here’s a nit-pic _or_ a clarifying question depending how one sees it: Let me see whether I parse it correctly: a) we are talking about BUM P-Tunnels b) the text clarifies that multiple VLANs can be mux’ed onto same P-Tunnel c) The rule that multiple EVIs can be mux’ed onto a P-tunnel in case of p2mp per 16.2.1 still stands. My question would be: What is the ETAG is multiple VLANs are multiplexed onto a P-Tunnel. I assume it’s max-ET? I assume that the choice (each VLAN distinct or all VLANs on same P-Tunnel) is a binary decision; otherwise we’d have to deal with the situation where we advertise for an EVI 1 EVI1;ETAG=MAX-ET, PMSI1 EVI1; ETAG=100, PMSI1’ with the semantics of „all VLANs _except_ 100“. Probably not intended. As well, I was always lost how ETAG can be used once multiple EVIs are mux’ed onto a P-tunnel. It would mean “VLAN 100 for EVI1 _and_ EVI2” which does not seem particularly useful. • tony
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
