Minutes IETF115: bess: Fri 09:30
|Meeting Minutes||BGP Enabled ServiceS (bess) WG|
|Title||Minutes IETF115: bess: Fri 09:30|
BESS IETF 115 meeting minutes
- Luc : authors working on comment. would be updated soon.
Sasha Vainshtein : whats happening in Yang in BESS working group.
Matthew : working group decided to park it year back
Stephane : we have to wait for some dependencies with other working
Sasha : will it be progressed some time ?
Stephane : it would be decided by WG when to start making progress
This draft under this usage case
1) Goes against the RFC 4456 requirement for a full distribution of
routes between Route Reflectors in IBGP mesh
2) specifies transitive optional Path Attribute (D-PATH) without an
Open Capability limitation, and
3) specifies changes to RFC4271 without an open Capability limitation.
- discussion among authros are in progress
- issues which were raised being already addressed for safi-1 and
authors would work with chairs to make progress.
- significent update after getting comments from sasha and Marek
- draft refreshed . new load balancing mode defined
- ARP procedure clarified based on WG comment
- defines route sync between peer in VRF context
- need more comments from working group.
- draft defines connecting different domain using gateway
- more review and comment needed from working group
- refresh draft
- defines use of D-path in EVPN internconnect Networks (RFC 9014)
- define method to protect loop
- alighned with 7432bis
- Susan : all changes are in single AS
- Jorge : it does not define AS restrctions
- Susan : same comment to D path. we need to make sure addition is
made about different AS . We can take discsusion offline.
- work is based on gap in existing specs in WG.
- waiting for working group feedback
- new co-author added
- more cases added from previous version
- WG adoption requested
- Ketan : is this expansion for all AFI/SAFI ?
- Gerg : yes, this is to make more generic. using existing attributes
but procedures are changed.
- Ketan : this is optional transitive, there have been discussion in
IDR about this. it may be good to check in IDR to prevent
information being leaked.
- Greg : will take this input and take feedback from IED
- Jeffery : Ketan points are correct. IDR general practice is to
provide detail about how attributes can lead to trouble. Optional
transitive may be wrong way to do it with security concern.
- Greg : to mitigate security issue is to use source IP so that
reflector can verify it.
- Gyan : is this for EVPN or L3VPN and mVPN as well ? it may be good
to say its specific to IP-VPN.
- Greg : clarification would be added .
- Ketan : follow up on Jeff comment, if putting security considiration
is good enough.
- Greg : will have offline discussion.
- Jie Dong: Some clarification may be good about where to use this and
have discussion with IDR.
- being discussed since IETF 112
- adoption requested earlier
- Jeffery : we had discussion over mailing list. but we have not
reached to agreement about solution. there is another draft already
presented in last IETF which solves most of issue. Third problem is
indeed problem related. We need more discussion in mailing list.
- new draft looking for comment .
- Susan: it would be good to present it in IDR as well.
- Swadesh : it can be presented in IDR and taken feedback
- Jorge: is some case are just for migration .
- Swadesh : for migration use safi4 which can carry label and SRv6
- looking for more comments
- new draft, more comments needed
- new draft. more comments needed
- Jorge: draft is straight forward. Long time ago group policy draft
was written and its expired. do we need to get it back ?
- Jeffery : not sure about old draft. Wen / john can answer this.
- Jorge: we decided not to extend VXLAN
- Matthew : preference would be GENEV
- Jeffery : This draft is about using ingress policy not the egress