Minutes IETF100: bess
minutes-100-bess-00

WG Status
chairs, 10min

ALi (on inter-subnet-forwarding): still planning to update it. Might be no
sooner than January

Adrian: Yang model for representing L2VPN service developed in L2SM. Reaching
completion. Seeking for reviews especially from operators, but vendors welcome.
It is not how we build the service but how we describe it.

draft-liu-bess-mvpn-yang-05
Yisong Liu, 10min

Sue (idr chair hat on): have you looked at BGP model

Yisong: no. we followed network instance model

Sue: will send you some pointers

Sue (to BESS chairs): worth looking at tunneling part as we've progress on that
in IDR

Martin: will look into that.

Stephane: are you augmenting L3VPN model or new hierarchy.

Ysong: started as such but feel it is too tied.

Stephane: in my view mvpn is l3vpn+mcast

draft-zzhang-bess-mvpn-msdp-sa-interoperation-00
Jeffrey, 10min

Chairs: who have read? Approx 10p

draft-zzhang-bess-bgp-multicast-controller-00
Jeffrey, 10min

Jeff T.: we have BGP free cores for last 15 years, do you now expect to run BGP
on every P router?

Jeffrey: true for unicast. But BGP is popular and would be lightweight for mcast

Jeff: still, you'd have to use BGP everywhere

Jeffrey: true. Not ideal for those not wishing to deploy BGP everywhere

Ali, you still have a tree in the core. you only address two of the three
concerns you've listed at the begining. For IP I see the beneift. For MPLS I am
not convinved.

Jeffrey: agree, but there are operators which really want that.

Ali, but that's an interim solution until we have BIER, ins't it?

Jeffrey: yes

Ali: you should clarify this in the draft

Jeffrey: we have some text but indeed.

draft-lin-bess-evpn-irb-mcast-04
Jeffrey, 20min

?: how do you decide whther you need to send to source BD or supplementary BD?

Jeffrey: procedure is described in the draft

?: and in case of P2MP tunnel?

Jeffrey: same. in interest of time we can discuss offline

?: but do you send one or two copies?

Jeffrey: one

Jorge (as co-author): document is mature. I agree it's ready for adoption.
natural evolution of current evpn solution for unciast. will make deployment of
l3vpn mcast very simple

Ali (as co-author): definitly great improvement. would be nice to give some
time to people to read latest rev before adoption

Martin: who has read? out of these who thinks it's ready? same number, maybe
minus 1

draft-rabadan-sajassi-bess-evpn-ipvpn-interworking-00
Jorge, 15min

?: regarding gateway PE, have you considered the UC where they are share
between multiple domains?

Jorge: draft supports that UCs, simply not described.

draft-skr-bess-evpn-pim-proxy-01
Jorge, 5min

?: There is this draft and another one about Route Types 6 and 7. Why two
drafts for the same Route Types?

Ali & Jorge: same route types indeed but different applications.

draft-malhotra-bess-evpn-unequal-lb-00
Neeraj, 10min

Jorge: useful document. On BUM traffic we agreed on the way forward.
Regarding Link BW Extended Community it was defined as non transitive.
But we need to think about inter-AS

Ali: DF election goes through AS, so it should be transitive

Jeff: [missed]

Jeffrey: not sure how you can guaranty the proportion with flows

Neeraj: load balancing per flow is never exact indeed

Stephane: Link BW is the good solution indeed. We need to respin that draft.

Himanshu: if multiple remote PEs, how do you coordinate from ingress?

Neeraj: I don't see a problem here.

Himanshu: I disagree

Ali: can you clarify that mice and elephant flows are outside the scope of the
draft.

Stephane (in reply to Himanshu): this is distributed control. you can't acheive
the same than in case of centralized.

draft-malhotra-bess-evpn-irb-extended-mobility-01
Neeraj, 5min

no question