Minutes IETF115: idr: Mon 13:00
minutes-115-idr-202211071300-00

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

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

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

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

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)

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

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

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

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

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

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.