Session 1: Tuesday, 13:00-15:00 CET (UTC +1), March 9, 2021

  1. Agenda bashing and Chairs’ Slides (10 mins)

  2. BGP Autoconf Design Team Report (15 mins)

Jeff Haas presenting.

Robin Li: Two questions. One is about scenario. Is it focusing on DC?

Jeff: The base scenario is clos-fabric topology.

Robin Li: About layer-3 and layer-2. What does switch fabric mean?

Jeff: Take EVPN as an example. In some cases you just want to talk to a peer on the other side of the link.

Aijun Wang: For BGP we must configure the peer address and the role. Then maybe there is little to do with BGP autoconf.

Jeff: Depends on what you want to do with BGP autoconf.

Aijun: If it can automate the configuration of AS number, it would be useful.

Jeff: Some of these may belong to ZTP.

Gyan:

Jeff:

Gyan: This may help with one layer of the autodiscovery in auto provisioning.

  1. BGP Flowspec Capability Bits [Jeff Haas] (10 mins)
    https://tools.ietf.org/html/draft-haas-flowspec-capability-bits/

Jeff Haas presenting.

Donald: Flowspec L2VPN has a different SAFI, which can solve this problem.

Haibo: What about this RR’s behavior? It will not reflect flowspec routes based on the capability of clients

Jeff: This is correct.

Haibo: RFC5575bis made some changes to treat unknown components as malformed, this change may cause incremental deployment problem.

Jeff: Yes, the working group consensus during development of 5575bis was to do that because it is impossible to confirm the unrecognized components are well formed.

  1. BGP FlowSpec Payload Matching [Philippe Bergeon] (10 mins)
    https://tools.ietf.org/html/draft-khare-idr-bgp-flowspec-payload-match/

Philippe Bergeon presenting.

Haibo: It may be useful, but will it make the implementation complex? Does it support multiple component combination to match the payload?

Philippe: the draft defines a single flexible match, for multiple match component, will need to send multiple NLRIs.

Bill: agree with Haibo this will add complexity to implementation, in particular multiple regular expression mechanisms.

Philippe:

Robin Li: It is like using BGP to implement P4.Will there be security issue?

Philippe: the idea is to reduce false positive.

  1. BGP Extension for SR-MPLS Entropy Label Position [Yao Liu] (10 mins)
    https://tools.ietf.org/html/draft-zhou-idr-bgp-srmpls-elp/

Yao Liu presenting.

Robin Li: what is this necessary to indicate the position? The controller can direcly add the entropy label to the SID list.

Yao: The assumption is the ingress node is responsible for the entropy label calculation.

  1. BGP-LS Extensions for Segment Routing based Enhanced VPN [Jie Dong] (15 mins)
    https://tools.ietf.org/html/draft-dong-idr-bgpls-sr-enhanced-vpn/
    Robin: For this draft, we would like to add one point.
    The network slicing work needs scalability. We feel this work will help to distribute netowrk slice information to the controller. While for the network slice information distribution to the network nodes, the scalability also needs to be considered. For this purpose we proposed a BGP-SPF based draft, which would reuse the TLVs defined here.

  2. BGP Classful Transport Planes [Kaliraj Vairavakkalai] (15 mins)
    https://tools.ietf.org/html/draft-kaliraj-idr-bgp-classful-transport-planes/

Kaliraj Vairavakkalai presenting.

Zafar: There are competing drafts on the agenda. WG should review all work before adopting any specific document.

Stephane: Need to clarify which WG this document belongs.

Haibo: A new SAFI is defined with RD + Prefix, and also use a TC extend community in attributes to classify the routes to different classes. Perhaps this method may cause users more complex tp plan the network? Because user would plan two new value, the RD and the TC extend community.

Further discussion from chat:

Ben Maddison: @Kaliraj what do you solve by using the new SAFI, instead of LU+Add-Path?

Kaliraj: @Ben, Addpath-ID is OK on a session scope. But this family needs more. Uses the RT to associate the Transport-route to correct Transport-RIB, and RD to uniquely identify the originating PE end-to-end.
so instead of retro-fitting RT semantics to LU, using ad-hoc communities, we just reuse RFC-4364 as-is.

Ben: OK, to paraphrase, you want the distinguisher to be preserved end-to-end (across ASBRs, RRs, etc), yeah?

Kaliraj: correct.

Jeff Haas: Generic observation: If route selection could cause a “pinch point” that removes path diversity, and path diversity is important, you need something in the flavor of an rd

Shunwan Zhuang: @Kaliraj Will the BGP CT Address Family Support SRv6 VPN in the future?

Kaliraj: @Shunwan, yes CT will interwork with SRv6 - as a transport-tunnel, as-well as srv6 on the inter-AS link. There is a draft that describes interworking of - interworking for SRv6 - MPLS dataplanes. That applies to CT also.

  1. BGP Color-Aware Routing(CAR) [Dhananjaya Rao] (10 mins)
    https://tools.ietf.org/html/draft-dskc-bess-bgp-car-problem-statement/
    https://tools.ietf.org/html/draft-dskc-bess-bgp-car/

Swadesh Agrawal presenting.wawa

Linda: don’t we already have RD to distinguish prefixes? What’s that “instance” thing then?

Swadesh: we don’t have RD in global routing. We’ve decided to use color as our distinguisher, represents different ways to reach the destination.

Linda: RD distinguishes between different prefixes, different clients.

Kaliraj: to elaborate on Linda: if it’s the same as SRTE, why do we need a new AFI/SAFI?

Swadesh: SR-TE is for controller to BGP speaker, this is for BGP hop by hop.

Kaliraj: you’re saying SRTE isn’t extensible enough, can’t be reused between BGP speakers?

Swadesh: yes.

Wim: it’s important to analyze this space in totality, I recommend we look at the different aspects of what we want to achieve and see how we can apply current tools to solve it. My understanding is there’s an ongoing discussion between different proposals, good to find common ground going forward.

Ketan Talaulikar
@kaliraj - SR-PCE based mechanism is “pull based model” while with BGP signaling we are introducing “push based model”. Both have their characteristics - we need to analyze them.

  1. Analysis of VPN Routes Control in Shared BGP Session [Aijun Wang/Gyan Mishra] (15 mins)
    https://tools.ietf.org/html/draft-wang-idr-vpn-routes-control-analysis/

Gyan Mishra presenting.

Sue: would like to have discussion on the problem statement.

[5 minutes for switching]

Session 2: Wednesday, 15:30-16:30 CET (UTC +1), March 10, 2021

  1. Agenda bashing (5 mins)

  2. BGP Flow Specification for SRv6 [Huaimo Chen/Zhenbin Li] (5 mins)
    https://tools.ietf.org/html/draft-li-idr-flowspec-srv6/

Huaimo presenting. Huaimo requested WG adoption of document.

Joel Halpern: Interpretation of a locator field in flowspec requires other protocols to … ?

Huaimo: explained with the format in the slides.

Jeff: How to interact with the SRv6 compression work in SPRING?

Huaimo:

Joel: How to determine where the func field is?

Huaimo: The information about the function field can be obtained via…

Joel: The routing protocol give the meaning of the SID, not information about the Func.

Dhruv Dhody (from chat): Maybe SID Structure is required?

Sue: Please take this to the list. It will be helpful for our flow specification next steps discussion.
I would request you have this discussion on the IDR list prior to starting the WG adoption call.

Jeffrey Haas (from chat): Perhaps also spring discussion. Are firewalls ever expected to generally interact with sids in the packet?

  1. BGP NLRI App Meta Data for 5G Edge Computing Service [Linda Dunbar] (10 mins)
    https://tools.ietf.org/html/draft-dunbar-idr-5g-edge-compute-app-meta-data/

Linda presenting.
WG adoption requested by Linda Dunbar and co-authors

  1. BGP UPDATE for SDWAN Edge Discovery [Linda Dunbar] (10 mins)
    https://tools.ietf.org/html/draft-dunbar-idr-sdwan-edge-discovery/

Linda presenting.
WG adoption requested by Linda Dunbar and co-uathors.

  1. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (15 mins)
    https://tools.ietf.org/html/draft-ietf-idr-sr-policy-ifit/

Giuseppe presenting.

  1. BGP Extension for Advertising IFIT Capabilities [Yali Wang] (10 mins)
    https://tools.ietf.org/html/draft-wang-idr-bgp-ifit-capabilities/

Yali presenting. WG adoption requested.

Jeff: Have concerns about security considerations, how widely the ifit information can be propagated.

Yali: IFIT domain was defined in another draft, could add reference in this draft.

Jeff: For destinations in another the IFIT information may be propagated to another domain.

Boris: Would be good to see implementation status of this draft.

Tony Li: Can this be served using management plane instead of using BGP?

Randy Bush (from chat): +1 to Tony.

Jeffrey Haas (from chat): As a further followup to Tony Li’s point, this stuff would make a lot of sense in BGP-LS.

Tony: Think the IFIT information is not related to routing.

Yali: This information may be used to select a path on which IFIT can be used.

Eduard V (from chat): SDN Controller (or NMS) is probably mandatory anyway to collect and analyze. Hence, this discovery could be moved to it too.

Tony Li (from chat): Exactly. This is a data plane capability discovery requirement.

Sue: Suggest to provide some more details about on why this should be included in BGP prior to WG adoptin call.

Tony Li (from chat): Exactly. This is a data plane capability discovery requirement.

Jeffrey Haas (from chat): It has a binding to routing state, so it makes some sense. but the scoping requirements are tricky.

[5 minutes for switching]