WG Status Chairs, 10 min draft-ietf-bess-evpn-prefix-advertisement-03 Jorge, 10 min Ali Sajassi: I want to emphasize that this draft has been implemented by multiple vendors and has been around for a long time. Ali: The document is in a good shape. I fully support WGLC for it. It should go to the queue after the intersubnet forwarding document. Martin: we'll add it to the queue L2VPN, EVPN, L3VPN Yang update Himanshu, 10 min No comments and questions. draft-drake-bess-datacenter-gateway-02 Adrian, 15 min Acee Lindem: It seems that what you are describing is something completely new, but it is not. SR-te draft exists in IDR Adrian: Aware of it. We have not defined any new protocol extensions. Acee: Your draft did not reference it. Jorge Rabadan: The main justification of the draft seems to be path visibility. You are saying that ADDPATH is not working here - maybe it would make sense to fix it in IDR? Adrian: I said ADDPATH has scaling issues and not that it is broken. Jorge: Could be fixed. Lucy Young: It seems that your solution requires having MPLS end to end? Adrian: This set of slides presents the simple case which is MPLS/SR end to end. But the draft explains other scenarios too. Lucy: Does this apply only to the unicast traffic? Adrian: That is a good question. We did not look into multicast in detail yet. We need to address it. Ali: Clarification on the advertisement from the destination DC - when each gateway advertises the prefix it also advertises all other GWs. What happens in the case of failure - when one says you can reach this prefix over 3 GWs, the other says that it is reachable over 1 GW? Adrian: This is a transient scenario, eventually it will converge to the same view. This is TE and not per packet forwarding. There is a possibility of windows of such types of failures. Ali: Eventually it will become consistent? Adrian: Eventually yes. We are not talking about hours and days here. This is a controller implementation question too. If there is a mismatch this case can be dealt specifically. Ali: Maybe these clarifications could be added in to the draft. Jeff Tantsura: Given the amount of the labels that you are adding to the stack you may hit the platform limits. Adrian: The amount of labels that you can push at the source is very different than what you can push on the transit node. Adrian: Loose hop labels could be used to reduce the number of labels. Jeff Tantsura: Would be good to detail this operation. Keyur Patel: This seems to fall into the local implementation aspects on how the labels are pushed. Keyur: Also, seconding Ali, how will you discover discrepancy? Acee: Regarding SR-TE. Are you envisioning the same way for the tunnel colour and encapsulation advertisement? Adrian: Yes. Martin Vigoureux: It seems that you have an answer to one of your questions (regarding interest from BESS) Martin: We will discuss this on the list. draft-mackie-bess-nsh-bgp-control-plane-01 Adrian, 20 min Lucy: Each SFF is a BGP speaker, but the peer of that speaker is a controller. Adrian: No, wrong. When you are a forwarder, you need to know the next hop and where that next hop is - therefore you need to be aware of the underlay too. Lucy: Controller is the one who decides the actual path taken. Adrian: Yes. Stewart Bryant: You do not need to use the controller, you can use distributed system too. Adrian: Yes, it is possible, just it is not very clear what a service path is in that case. Stewart: It can look at the packet and make that decision. Adrian: Yes, you could do that. The classifier could be the controller. Acee Lindem: The assumption is the controller computes the complete path and it never changes through the lifetime of it? And SP and SIs are unique in the context of that path? Adrian: The controller is within its own overlay network. Martin: who has read? Approx 20p draft-sajassi-bess-evpn-vpws-fxc-01 Ali, 5 min Iftekhar Hussain: Is there a typo - you have a PW-ID there on the slides? Ali: Yes, it is a typo. Ifthekar: There is a confusion on what is presented here and what is described in the draft. Ali: In the draft there should be no mentions of PWs, there should be only service IDs. Iftekhar: Would be good to clarify the service tunnel notion. Ali: Service tunnel is a point to point tunnel, equivalent to a pseudowire. Iftekhar: Would be good to explain that in the draft. Ali: Please suggest text for areas that are not clear. Lucy Young: What is the purpose of the PE1 and PE2? It seems confusing? Ali: The service interface could be terminated into VRF. It is an example of backhauling the traffic from PE1 and terminating on PE2. Himanshu Shah: I have found it a bit confusing too after reading a couple of time, will suggest some text. Ali: Question to WG chair - will you poll the WG for adoption? Martin: Yes. draft-sajassi-bess-evpn-igmp-mld-proxy-01 Ali, 10 min Lucy Young: Join and leave messages to/from PE - do you need to advertise it to the whole domain? Ali: We are trying to exactly avoid it - you do not want to flood the whole network with those messages. You advertise only to the remote PE that you have the state synchronized in the redundancy group of PEs. If you read the draft it gives the reasoning for why we do the suppression. Lucy: What you are proposing is sending to the one PE in RG and supress the others? Ali: Yes. Jorge Rabadan: The comment on the join and leave synchronization route - I think I understand the logic here, you are trying to mimic the logic of IGFMPv2 in BGP. But that is extremely expensive. Ali: That is limited to the PEs in the RG. Jorge: Can you use the single route for both functions? Ali: Due to ambiguity we decided not to do that. Jorge: You need different flags to indicate whether that is a join or leave. Ali: Join and leave are independent and you cannot couple them together. Thus we cannot use the single route. Jorge: What is the leave group synchronization id of 4 octets? It is not explained in the draft. Ali: It is a form of sequence number. Robert Raszuk: The problem that you are describing is extremely useful, and the solution in my view should be extended beyond EVPN. BIER can use this functionality too. Ali: EVPN is agnostic to tunnel type, I can use any tunnel type including BIER. Your comment is applicable anyway. Himanshu Shah: If you have PE1, 2, and 3 in RG, if PE1 receives multiple joins, will it send multiple synchs? Ali: It will send one. When it receives the first join, it creates state and maintains it. draft-boutros-bess-vxlan-evpn-02 Sami, 5 min Jorge: For multihoming - you are using a multicast VTEP, but for BGP - are you using different next hops? Sami: Yes. Jorge: Maybe it would be worth clarifying those details in the draft? Lucy: for VXLAN to connect to EVPN - is the behaviour exactly the same as in VLAN multihoming in MCLAG? Sami: It is similar, but the blocking is different - with VXLAN we need to block in both ways. Martin Vigoureux: We have already polled for adoption of this draft, and due to lack of support we decided not to adopt. If we repoll in future, we need to ensure that there is interest in this work. draft-boutros-bess-evpn-auto-provisoning-02 Sami, 5 min Jeffrey: Which direction is the FSOL coming in this scenario? Sami: From AC side. Jeffrey: Why in that case PE2 not sent to the controller? Sami: If the FSOL is coming from the server, it will get forwarded to the controller. We could discuss offline the specifics of this particular use case. Jeffrey: Instead of encoding in in VSI, would using extended community be more flexible? Sami: we can discuss. Please send comments. draft-boutros-bess-evpn-vpws-service-edge-gateway-03 Sami, 5 min Not presented due to lack of time.