Minutes IETF97: bess
minutes-97-bess-00

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.