Skip to main content

Minutes IETF98: bess
minutes-98-bess-00

Meeting Minutes BGP Enabled ServiceS (bess) WG
Date and time 2017-03-27 14:00
Title Minutes IETF98: bess
State Active
Other versions plain text
Last updated 2017-04-12

minutes-98-bess-00
Minutes taker: Jay Karthik
Completed with chairs notes

Audio/Slides/Video recording at https://www.youtube.com/watch?v=9kvTvpskBTQ

BESS / IETF 98

9:03 - WG status

9:07 Patrice - L2VPN + EVPN YANG

Martin: We had decided to wait till FXC be adopted as a WG to integrate it in
yang model. Patrice: OK. we'll make a suggestion on possible ways to integrate
it and will effectively do when fxc is adopted. Patrice: pending comments on
L2VPN to be addressed soon

9:13 Jorge - draft-ietf-bess-evpn-optimized-ir-01

Thomas: Ok for WGLC to happen soon

9:18 Jorge - draft-rs-bess-evpn-attr-prop-00

Jorge: [insists on need for fedback]
Ali: Another EVPN draft existing focusing on interop - use cases may overlap -
Overlap should be minimized Jorge: Agreed and open for discussion

Chairs: who has read the draft (6 hands)

9:26 Jorge - draft-rabadan-bess-evpn-pref-df-02

Jeff Haas: What happens when routing partition happens ?  when 1 or more RR
exist how does  DF election work ?  Say BGP fails/ RR goes down, have you
thought about DF election failing ? Jorge: Issue outside scope of this proposal
(already a possible question without this proposal). Redundancy in place for RR
- This could be a matter of local implementation Jeff: yes, split-brain already
an issue, but issue could be worse when adding this proposal

Thomas: Having range configured - allocation of EVI should be consistent via
automation of config for better load balancing (why not use a modular base
mechanism) Jorge: Agreed to consider this option

Patrice:  Does this mechanism work on DCI/Gateways  ?
Jorge: Should work
Patrice:  Lets have an offline discussion

Chairs polling the room about whether doc is suitable for adoption, half a doen
in favor, none against.

9:39 Ali Sajassi - draft-sajassi-bess-evpn-fast-df-recovery-00

Tony: Sounds like PAXOS. Do you need to receive all the acks before recovered
PE takes ownership/action. Ali: Not really. The recovered PE takes action per
PE. Once it receives Ack from one PE, it changes the forwarding state of the
VLANs for that PE.

Jorge: Good draft. Similar question like Tony -  The routes are missing the
originating ip Ali: Next rev will address it. Already received same comment
from John.

Jorge: When does PE send NACK ? Flag exists in draft
Ali: Will cover this in the next rev if there is a use case, otherwise will be
removed. Jorge:What about the "Init" flag. Ali: Will remove in the next rev
Jorge: The draft gives the impression that there may be loops. Ali: Single
failure will not create a loop  - In case of double failure - 2 segments -
which is rare - loops may be possible

Himanshu: Will clock sync really work ? Can we predictably determine when
switchover can happen ? Ali: Yes, even if not at micro/pico seconds level,
within milli sec level it is possible. Jeff Haas: Comment to Himanshu - Sync
better than messaging through BGP. Patrice: To Himanshu - already implemented
in code today

John Scudder: What happens when the recovered PE after sending DF request, it
fails. Ali: If that happens there is a transient blackhole condition. This is
because, when the receiving PE receives the DF request, it places the affected
VLANs in blocked state and once it finds out the recovered PE has failed, it
will place the VLANs back in 'Forward' state

Thomas: Which approach would you recommend?
Ali: if DC is capable of clock sync use that otherwise use handshake

Thomas: Why not specify single mechanism that works
Ali:  if DC has additional capabilities the operator should take advantage of
that.

Thomas: In reference to a similar draft presented in Dallas, it might be needed
and interesting to have a short comparison. Ali: this was handshacking per EVI.
Does not scale. In this work, HRW is leveraged and handshaking is per PE
(regardless of number of service instances).

10:08 Ali - draft-keyupate-bess-evpn-virtual-hub-00

Jorge: For IP Tunnels the procedures are similar to what is specified in
Optimized IR. Suggest adding a reference to that ID . This draft should focus
on MPLS Ali: Agreed

Jorge: ID mentions the use of PE D label attribute signaled from the vSpoke.
Need clarification on why this attribute is signaled ? Ali: mentioned that was
needed for Split Horizon

(Jorge/Ali about DF election being only used for mLDP not in the case of
ingress replication)

Jorge: How to determine if the label of vSpoke is unique ? Who distributed
vSpoke labels ? Jeffrey: PE D label is needed for multi homing. This is the
best way to achieve split Horizon ? Jorge: Need an offline discussion for local
bias / vspoke

Chairs: who has read ? (6 hands)

10:30 Jeffrey Zhang - draft-lin-bess-evpn-irb-mcast-03

Ashutosh Gupta: Are the tunnels being talked in draft BUM tunnels? If yes then
it would mean all BUM traffic to go to all the Tunnel Endpoints even if some of
them will not have BD configured on it. If no, that means all nve's will form
two tunnels per BD. Jeffrey: Not mentioned in the ID - distributed anycast
gateway Ashutosh Gupta: Draft doesn't talk about Distributed Anycast Gateway (a
deployed feature for asymmetric IRB for unicast). Jeffrey: Anycast is
irrelevant here. Additional ip address configured on IRB will address this for
df election. Ashutosh Gupta: Why not use MVPN for EVPN multicast routing since
it solves all the use-cases? Jeffrey: MVPN will be used where applicable. If
MVPN used TTL gets decremented twice, and the source IP address changed and
takes a longer path (extra hop). Using MVPN in EVPN space adds additional
complexities that could be avoided.

Eric Rosen: Dozens of issues present with reusing MVPN. No much credibility to
claim that things are working with MVPN. MVPN functionality does not apply to
EVPN.

11:00 Yisong Liu draft-liu-bess-mvpn-yang-03

No question asked at the meeting
Chairs: who has read ?  (4-5 hands)

11:05 Jeffrey - draft-zzhang-bess-bgp-multicast-01

Robert Raszuk: Extremely useful. Have you considered using segment routing
"spray" ? To simplify data plane. Jeffrey: Intermediates states in mcast
anyway. Single protocol simplifies and consolidates operation. An alternative
to reduce state is BIER. Robert Raszuk: SR spray is good to replicate on spine

Thomas: Maybe relevant to MBONED.
Leonard Giuliano: Best place is here (BESS Working Group). MBONED could
contribute as operations - more so with Bess than PIM. Have a joint meeting
planned.