### Distribution of Traffic Engineering (TE) Policies and State using BGP-LS {#distribution-of-traffic-engineering-te-policies-and-state-using-bgp-ls} draft-ietf-idr-te-lsp-distribution Ketan Talaulikar Updates since IETF 114: Implementations already done or ongoing for this draft. Key change is to use separate NLRI types for each TE Policy type. Also, removal of reference to IP-based tunnels. Finally, various clarifications and updates. Work in progress: Getting feedback from ongoing implementations/reviews. Expecting a few more minor updates. All feedback relates to SR Policy, which suggests that's the only thing that's implemented. Proposal for splitting the draft: * SR Policy advertisements (where implementations exist) * Other types of TE policies. Chairs indicated that a split would be possible. Next stage is to put forward the split. ### BGP YANG Model for Service Provider Networks {#bgp-yang-model-for-service-provider-networks} draft-ietf-idr-bgp-model Mahesh Jethanandani Status: done a lot of work in the model in terms of updating the transport security. Worked with the TCP Yang authors on TCP-AO/MD5 aspects. These moved into their model. Cleanup. Updates to policy model. Issues: Some regular expression cleanup remains. Side-meeting later today. Extended communities continue to be one of the more challenging pieces. ### Deprecation of AS\_SET in BGP {#deprecation-of-as_set-in-bgp} draft-ietf-idr-deprecate-as-set-confed-set Jeff Haas Motivation: BGP4 was the first inter-domain protocol for carrying CIDR. Therefore the BGP RFCs contain various information/definitions for aggregation. An AS\_SET is part of the aggregation rules defined in RFC 4271, Section 9.2.2.2. Current best practices is to use null routes on your own internal address space at the borders. Route Origin Validation needs a deterministic origin AS. AS\_SETs, typically at the right-hand side of the AS\_PATH, make that ambiguous. RFC 6472 says "don't create AS\_SETs or CONFED\_AS\_SETs". AS\_SETs aren't common, but aggregation still remains quite common (~10% of the routing table). What needs to change in core BGP procedure? * If you receive an AS\_SET, you SHOULD do RFC 7606 "treat-as-withdraw". * Implementations SHOULD NOT create them when aggregating. CONFED\_AS\_SETs do not cause issues with RPKI-ROV. Removing CONFED\_AS\_SETs becomes "a good idea". Updating -10 to say recommend this. What's next? * Refine text vs RFC 4271 changes * "Don't do that" in RFC 6472 is not the best text * Get vendors to implement new AS\_PATH procedure for aggregation Randy Bush: Of the 300 aggregates in the current global routing table, almost all of them are singletons. Don't think there's any damage to actually removing. Job Snijders: A number of years ago, operators removing private ASNs in the default free zone -- purpose of this was to promote some attribution capabilities. Please could implementors make it easy to allow all routes with AS\_SETs to be rejected. Alvaro: Document says you're deprecating/obsoleting, but in fact you're saying "really don't use this". Can you to clarify the language a bit. (from chat) Zhen Tan: Performing a treat-as-withdraw while AS\_SET was still partially implemented might cause failure of service, how venders would be willing to do this? Jeffrey Haas: @zhen tan for the routes that still use it, it's the upstream as's option to continue propagating them. This is why it is a SHOULD. However, rpki pressures are already causing many providers to simply reject such routes. Jeffrey Haas: For example, a set of aggregated stub ASes may still be allowed to receive the as-sets - or policy may be used to simply send them their contributing routes. It's the Internet at large outside of the stub that doesn't want to see AS\_SET Jeffrey Haas: If you have specific operational concerns, we'd invite you to email idr@ietf.org with them so we can discuss them or incorporate the resolution in the draft. ### BGP Extension for 5G Edge Service Metadata {#bgp-extension-for-5g-edge-service-metadata} draft-dunbar-idr-5g-edge-service-metadata Linda Dunbar Scenario where the edge router propagates some property of the site. eg "Site Capacity Index": egress router can tell the ingress router that the capacity is reduced if the site goes dark. Want to allow edge service metadata to influence the decision of the best route. How do we insert this into the decision chain to integrate with other attributes to create the best path? In this scenario, the next hop doesn't represent the router's capacity, but the attached site's capacity. This attribute only affects the service instances that are directly attached. Proposing a new Metadata Path Attribute to represent the service metadata. Next step: solicit more comments from the WG. Asking the community whether we can create a different name for this next hop. (eg "Next Hop Transit", "Next Hop iBGP exit point"). Acee Lindom: Don't see why we need to rename the next-hop just for this attribute. Linda: Asking for this because lots of drafts associated with next-hop talk about propagation. Acee: Could just associate this new different behavior with this attribute type? ### BGP SR Policy Extensions for metric {#bgp-sr-policy-extensions-for-metric} draft-zhang-idr-sr-policy-metric Ka Zhang BGP can be used to propagate SR Policy candidate paths to the headend nodes in the network. By using BGP SR as the Policy NLRI, controllers may deliver different SR policies which satisfy the constraints of VPN services. *Jie Dong took over presenting* Document proposes to add the Metric Sub-TLV to the BGP SR policy. When SR Policy headend gets the SR Policy segment list with metric, local policy dictates how to process the metric. Updates: * New metric types, eg minimum unidretciontal link delay * Codepoints for metric types (?) * Text about candidate path metric calculation Ketan Talaulikar: Why not have the metric at the candidate path level? Is there value in doing it per segment list? Jie: It's possible for different segment lists for the metric to be different. For the candidate path can choose the maximum metric of the segment lists. Ketan: Do you have a use-case or requirement in mind? *agreed to discuss further offline* Jeff Haas: Have you had discussion in SPRING about this document? Jie: Not yet. Jeff: Encourage you to take it to SPRING to discuss. Gyan Mishra: Reiterated the point about SPRING. ### Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) {#connecting-ipv4-islands-over-ipv6-core-using-ipv4-provider-edge-routers-4pe} draft-mishra-idr-v4-islands-v6-core-4pe Gyan Mishra IETF standard exists for connecting IPv6 islands over IPv4 core (RFC 4798), but not the other way round. This draft provides this: IPv4 islands over IPv6 core: "4PE". 4PE routers exchange IPv4 reachability transparently tunneled over an IPv6 core using MP-BGP IPv6 RFC 2545, using BGP next hop field to convey the IPv6 address of the 4PE router. Draft is extensible to SR-MPLS. Would like feedback from the WG and queue up for adoption. ### BGP Flowspec for IETF Network Slice Traffic Steering {#bgp-flowspec-for-ietf-network-slice-traffic-steering} draft-dong-idr-flowspec-network-slice-ts Jie Dong BGP Flowspec provides a mechanism to distribute the flow specifications and flow forwarding actions to the matched traffic. IETF network sliced traffic needs to be steered into an NRP (a collection of networking resources in the underlay network) to meet the connectivity and performance requirements. This document defines the flowspec extensions for steering traffic into an NRP. Existing flowspec components can be reused to match network slice service traffic -- RFC 8955 and RFC 8956. A new flowspec attribute is defined to match the NRP ID. Network slice traffic steered into an NRP can be forwarded using: * Shortest path in the NRP * TE paths associated with the NRP Document defines a new Encapsulate-NRP-ID action if dataplane NRP ID is used for NRP-specific forwarding. For TE steering case, IETF network slice traffic can be steered using draft-ietf-idr-ts-flowspec-srv6-policy. ### Problem statement of Inter-domain Traffic Redirection Risks {#problem-statement-of-inter-domain-traffic-redirection-risks} draft-cheng-idr-redirection-risks-ps Weiqiang Cheng Operators have deployed redirection technologies such as BGP Flowspec at scale. This draft describes the risks of these redirection mechanisms in operators' networks. Risk 1: Traffic detour and exposure. Violation of valley-free principle (i.e. traffic in provider's network is redirected to the customer's network). Risk 2: Traffic black hole. Risk 3: Traffic loop. Risk 4: O&M risks. The traffic owener expects the traffic to be transmitted along the AS path carried in the route, but the actual transmission path is different to the AS path. If the network O&M control system doesn't obtain traffic redirection information, unpredictability may occur during traffic optimization, eg network congestion. Jeff Haas: What is your intention for the future of this document? Weiqiang: We found some risks but haven't explored solutions. Hope that members of IETF can provide solutions/ideas in the future. Jeff: Suggest this might be better work for the grow working group. Acee Lindom: Elephant in the room with flowspec is that it isn't being used for its original purpose, but instead is being used like Openflow to decide routing. The examples presented here imply this is happening. ### BGP for Mirror Binding {#bgp-for-mirror-binding} draft-chen-idr-mbinding Huaimo Chen Binding SID associated with segments. We send via BGP a Binding SID for N (see Protection Sub-TLV below) and SL with backup path (green one on the slide) towards P1 (PLR), when node N fails, PLR (P1) finds out that N is failed, extracts SL from that Binding SID, and replace the binding SID with that backup path (gree one) list of SIDs. *(note-taker: this is a very high-level summary of what was presented)* BGP is extended to send a binding with a node id of N. When node N fails, the adjacent node can provide fast protection for node N. Define a Binding Protection sub-TLV containing the node id of node N. Andrew Stone: General question: when you program to the neighboring routers, are you informing the neighbors of the entire SID list? Huaimo: No, just the binding, and the node. Andrew: In the example presented, if P1 is protecting N, how does it know it needs to reroute to P6? Huaimo: When P1 receives the packet, that packet contains the whole segment list. Local adjacency is also included in the SR header. Andrew: If label is local to p6 like an adjacency-sid, then P1 doesn't know who's advertising that label. Andrew (cont): Think there's a gap here. Andrew (cont): Another observation: the actual label stack of the BSID could have nested binding SIDs. *Andrew will follow up on the list on both of these questions*. ### Extended Communities Derived from Route Targets {#extended-communities-derived-from-route-targets} draft-zzhang-idr-rt-derived-community Jeffrey Zhang General example: say you have a VPN with 10 PEs. Have a route target RT1 which is an extended community EC1 with sub-type 0x2. RT1 == EC1. When we say "route target", we emphasize that it is an EC used to control the propafation and import of routes. When we only say "extended community", we don't imply these semantics. Say we need to send one route to PE1 only and PE1 needs to know that the route is related to the VPN. Want to use a different route target RT2. RT2 != EC2 != RT1. Draft presents RT-derived EC. For any RT, an EC can be derived by changing the sub-type to a new value 0x15. Documents three example use cases. Next steps: This document only specifies the derivation of an EC from an RT by changing the subtype. Don't specify how it will be used. Acee Lindom: Do you still need to document the specific usage? Jeffrey: The draft includes three use cases. A new use case would need another draft. ### BGP MultiNexthop Attribute {#bgp-multinexthop-attribute} draft-kaliraj-idr-multinexthop-attribute Kaliraj Vairavakkalai Background: Thinking about how we express next hops in BGP. Nexthop information is extracted from various portions of the route. Can be categorized in terms of where we forward to. Addpath and multipath are used to express multiplicity. These mechanisms have organically grown, and information is spread across different portions of the BGP route, and local configuration. Problems: * Can't advertise more than one nexthop in a route. * Not easily extensible to newer endpoint types. * Can't express relationship between the different nexthops (even with addpath). * Can't signal encap information uniformly for different address families (eg can't signal labels for SAFI 1 routes). * Can't express multiple labels in a route. * Semantics of a downstream allocated label not known to the receiver. MultiNexthop attribute attempts to solve these problems. It's an optional nontransitive attribute. Usage negotiated with BGP capability. Can carry 1 or more nexthop instructions. Propagation scope: * Nontransitive, will not unintentionally leak. * Carries Advertising BGP Protocol Nexthop (do we need this any more, since the propagation scope is more conservative now?). * Even amongst speakers that understand MNH, advertisement is controlled by a Propagation scope checker. MNH TLV types: * Type 1: Upstream signaled primary forwarding path * Type 2: Upstream signaled backup path. * Type 4: Downstream signaled label descriptor. * Type 3: Domain Local Preference. Used during Path Selection in place of LOCAL\_PREF attribute. Unknown types are propagated if MNH is propagated (perhaps add a "partial" indication bit?) Error handling: * Follows the 'Attribute discard approach' (RFC7606) * Try to deal gracefully with errors: ignore unknown TLVs, ignore extraneous arguments in forwading action, ignore Fwd-Instruction TLV if not enough arguments. * More details in Section 6. Keyur Patel: Comments: * Attribute discard might be too gentle. Might want to take the path out completely. * Is non-transitive correct? * May want better naming. Jeff Haas: To the WG: would encourage everyone to look at this draft because we're hitting a theme within idr about what do we do about carrying next hop and forwarding information within a PDU. This draft is a good place to start in discussing scope, propagation, forwarding behaviors, security properties. We're entering a space where we want to decide what we want to be carrying inside BGP. Meeting adjourned.