Skip to main content

Minutes IETF111: idr
minutes-111-idr-01

Meeting Minutes Inter-Domain Routing (idr) WG
Date and time 2021-07-27 23:00
Title Minutes IETF111: idr
State Active
Other versions plain text
Last updated 2021-08-03

minutes-111-idr-01
# IDR meeting at IETF 111

## Session 1: Tuesday, 16:00-18:00 (UTC -7), July 27, 2021

### 0. Agenda bashing and Chairs' Slides (10 mins)
 IDR will adopt draft-ietf-bgp-autoconf-considerations-01.txt
 IDR will welcome bgp autoconf protocol proposals.

 Interims on 8/23 (new drafts), 9/13 (flowspec-v2),
 9/21 (TBD), and 10/11 (TBD).
 Potential topics: Auto-configuration protocols, and
 error handling for embedded NLRIs, and proposed topics.

### 1. BGP YANG model [Mahesh Jethanandani] (5 mins)
  https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model/

Major issues to be discussed today: extended communities and large communities.
Jeff Haas: Explained the issues about large community , the extended
communities and YANG typedef in detail. Jeff Haas: Please take a look at the
open issues tracked at: https://github.com/mjethanandani/ietf-bgp-yang/issues.
The target is to get most of the work done by next IETF.

### 2. BGP Color-Aware Routing (CAR) [Dhananjaya Rao] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car/

There is ongoing effort to merge the two problem statement drafts.

Srihari Sangli: It says you can advertise different labels for different
encapsulations, are they still separate NLRI? As the labels in NLRI are non-key?

Dhananjaya: Confirm that labels are non-key.

Srihari: Raised the question about key/non-key on mail list. How will the NLRI
grow with the key and non-key? For new attributes whether put it the NLRI or in
the attribute would be a question.

Dhananjaya: THe non-key in NLRI is for per-route specific information rather
than generic attribute.

Aijun Wang: What is the advantage to define new NLRI? It can be done with the
existing color ext-community.

Dhananjaya: Did not get the question fully, the color ext-comm is used to
indicate the request for an intent. Can take to the list.

Kaliraj (from chat): Is CAR a service-layer family or a transport-layer family?

Ketan (from chat): they are two different SAFIs - one for transport other for
service, Plz check sec 8 of the v02 for the VPN CAR.

### 3. BGP Classful Transport (BGP CT) [Kaliraj Vairavakkalai] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes/

Linda Dunbar: Is the color consistent across all the nodes?Is this similar to
Flex-Algo?

Kaliraj: Flex-Algo is one approach for intra-domain. BGP-CT is for
inter-domain. The color is usually consistent in one domain, but may not be
consistent when cross domains. Border nodes can rewrite the route target.

Linda: Can Flex-Algo be used inter-domain?
Kaliraj: Even if it is the case, it can coexist with BGP-CT.

Swadesh Agrawal: About local convergence. You need to do import at ABR. When
advertising to the upstream, the same local label will be carried in different
CT routes. THis seems like a hack.

Kaliraj: The routes are collected into transport RIB. One reason is for service
mapping to tunnels of a certain kind. There is no such thing in BGP CAR.

Swadesh: BGP CAR can also provide the resolution based on the same color. What
is the advantange of 2 different routes with different RDs but the same local
label?

Kaliraj: The prefix allocation is on the scope of prefix:transport class. There
is nothing that stops you from announcing two routes with the same label. The
advantage is to tell the upstream ABR different nexthops.

Swadesh: This can have some problem.

Jeff: No time for further discussion. This is a interesting point. Please post
this to the mailing list for further discussion.

Haibo Wang: VPN routes use next-hop and color to match the transport tunnels.
The key in BGP CT route (RD, prefix) does not match with the key used for VPN
route resolution. Kaliraj: Didn't get the question. The service route asks for
a tunnel resoluation of a color, the tunnel can be either intra-domain
flex-algo or RSVP, or inter-domain BGP-CT. If there is no tunnel with the
color, it will use best effort. Haibo: It would good to have further discussion
of this on the list.

### 4. BGP MPLS-namespaces: Improve Scaling and Convergence in Seamless-MPLS
networks [Kaliraj Vairavakkalai] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels/
Swadesh: How many routes will be seen by the PE if the domain has 100 PEs and
1000 vrfs? Kaliraj: ... (some of response begun here)...

Jeff: Suggest to take the discussion to the list.

### 5. Generic Metric for the AIGP attribute [Reshma Das] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-ssangli-idr-bgp-generic-metric-aigp/

Swadesh: The metric type is decided by the original domain?I am not sure what
benefit you are gaining over the IGP domain.

Reshma: If you are low cost in one route in one domain, and delay in the metric
in another domain.

Shraddha: Can carry different metric types in different routes. Only metric of
the same type can be accumulated.

Swadesh: Is the metric type used to represent the intent? Try to understand the
advantage. Shraddha/Reshma: We should discuss this on the list.

### 6. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-ifit/

No questions on the meeting.

### 7. Advertising p2mp policies in BGP [Hooman Bidgoli] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy/

Gyan Mishra:

Huaimo: We don't have BGP sessions to P nodes. P2MP SR Policy needs to send
instructions to P nodes.

Hooman: Does not require BGP sessions for each node, can use P2P Policy between
nodes. If need replication segment Hop by Hop, will need BGP session to each
node.

Gyan: Is SRv6 and inter-domain covered?

Hooman: It is covered in the drafts.

Gyan: There is a mechanism in PCE WG.  How does this interact with this
mechanism? Hooman: The PCE mechanisms are a second mechanisms.

Jeff: The draft also presented in BESS, the content will be developed in IDR.

### 8. BGP-LS with Multi-topology for SR based VTN [Cong Li] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-xie-idr-bgpls-sr-vtn-mt/

Ketan (from chat): this is an informational document with really no signaling
or protocol extensions for BGP-LS. Do we need such a draft? Note that consumers
and use-cases for use of BGP-LS is outside the scope of BGP-LS. Best case,
considering adding necessary text to the corresponding LSR draft ... which is
also informational.

Jie (from chat): Yes this is an informational document. Comparing to the LSR
draft, it also covers the distribution of inter domain topology and TE
attributes for a VTN.

Les Ginsberg (from chat):
@Jie +1 to what Ketan has said. The draft simply describes what is discussed in
other drafts - I see no need for it. Time would be better spent in making sure
all the drafts referenced in draft-xie-idr-bgpls-sr-vtn-mt are themselves
complete.09:00:43 Jie Dong (from chat): @Les we had similar discussion about
the LSR draft, the consensus was it is useful to document the usage of MT for
VTNs.

### 9. Deterministic Route Redistribution into BGP [Enke Chen] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-chen-bgp-redist/
  Note: Enke requested WG Adoption after -03.txt is posted.

  John Scudder (from chat):
I'm pretty sure this is a rerun (with different details) of a presentation Rich
Woundy gave around IETF-30 or so, plus or minus. Same problem (ish). Same
solution (ish). It even was implemented in early GateD, but poorly documented
and nobody understood it. Maybe we can make the fix stick this time.08:50:43

### 10. Update and Discussion on RD-ORF Solutions [Gyan Mishra/Aijun Wang] (10
mins)
  https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf/
  https://tools.ietf.org/html/draft-wang-idr-vpn-routes-control-analysis/

No comments or questions on the meeting.

### 11. (If time allows) Connecting IPv4 Islands over IPv6 MPLS using 4PE [Gyan
Mishra] (5 mins)
  https://tools.ietf.org/html/draft-mishra-v4-islands-v6-mpls-4PE/

No time to present.

[5 minutes for switching]

# IDR meeting at IETF 111

## Session 1: Tuesday, 16:00-18:00 (UTC -7), July 27, 2021

### 0. Agenda bashing and Chairs' Slides (10 mins)
 IDR will adopt draft-ietf-bgp-autoconf-considerations-01.txt
 IDR will welcome bgp autoconf protocol proposals.

 Interims on 8/23 (new drafts), 9/13 (flowspec-v2),
 9/21 (TBD), and 10/11 (TBD).
 Potential topics: Auto-configuration protocols, and
 error handling for embedded NLRIs, and proposed topics.

### 1. BGP YANG model [Mahesh Jethanandani] (5 mins)
  https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model/

Major issues to be discussed today: extended communities and large communities.
Jeff Haas: Explained the issues about large community , the extended
communities and YANG typedef in detail. Jeff Haas: Please take a look at the
open issues tracked at: https://github.com/mjethanandani/ietf-bgp-yang/issues.
The target is to get most of the work done by next IETF.

### 2. BGP Color-Aware Routing (CAR) [Dhananjaya Rao] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-dskc-bess-bgp-car/

There is ongoing effort to merge the two problem statement drafts.

Srihari Sangli: It says you can advertise different labels for different
encapsulations, are they still separate NLRI? As the labels in NLRI are non-key?

Dhananjaya: Confirm that labels are non-key.

Srihari: Raised the question about key/non-key on mail list. How will the NLRI
grow with the key and non-key? For new attributes whether put it the NLRI or in
the attribute would be a question.

Dhananjaya: THe non-key in NLRI is for per-route specific information rather
than generic attribute.

Aijun Wang: What is the advantage to define new NLRI? It can be done with the
existing color ext-community.

Dhananjaya: Did not get the question fully, the color ext-comm is used to
indicate the request for an intent. Can take to the list.

Kaliraj (from chat): Is CAR a service-layer family or a transport-layer family?

Ketan (from chat): they are two different SAFIs - one for transport other for
service, Plz check sec 8 of the v02 for the VPN CAR.

### 3. BGP Classful Transport (BGP CT) [Kaliraj Vairavakkalai] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-bgp-classful-transport-planes/

Linda Dunbar: Is the color consistent across all the nodes?Is this similar to
Flex-Algo?

Kaliraj: Flex-Algo is one approach for intra-domain. BGP-CT is for
inter-domain. The color is usually consistent in one domain, but may not be
consistent when cross domains. Border nodes can rewrite the route target.

Linda: Can Flex-Algo be used inter-domain?
Kaliraj: Even if it is the case, it can coexist with BGP-CT.

Swadesh Agrawal: About local convergence. You need to do import at ABR. When
advertising to the upstream, the same local label will be carried in different
CT routes. THis seems like a hack.

Kaliraj: The routes are collected into transport RIB. One reason is for service
mapping to tunnels of a certain kind. There is no such thing in BGP CAR.

Swadesh: BGP CAR can also provide the resolution based on the same color. What
is the advantange of 2 different routes with different RDs but the same local
label?

Kaliraj: The prefix allocation is on the scope of prefix:transport class. There
is nothing that stops you from announcing two routes with the same label. The
advantage is to tell the upstream ABR different nexthops.

Swadesh: This can have some problem.

Jeff: No time for further discussion. This is a interesting point. Please post
this to the mailing list for further discussion.

Haibo Wang: VPN routes use next-hop and color to match the transport tunnels.
The key in BGP CT route (RD, prefix) does not match with the key used for VPN
route resolution. Kaliraj: Didn't get the question. The service route asks for
a tunnel resoluation of a color, the tunnel can be either intra-domain
flex-algo or RSVP, or inter-domain BGP-CT. If there is no tunnel with the
color, it will use best effort. Haibo: It would good to have further discussion
of this on the list.

### 4. BGP MPLS-namespaces: Improve Scaling and Convergence in Seamless-MPLS
networks [Kaliraj Vairavakkalai] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-kaliraj-bess-bgp-sig-private-mpls-labels/
Swadesh: How many routes will be seen by the PE if the domain has 100 PEs and
1000 vrfs? Kaliraj: ... (some of response begun here)...

Jeff: Suggest to take the discussion to the list.

### 5. Generic Metric for the AIGP attribute [Reshma Das] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-ssangli-idr-bgp-generic-metric-aigp/

Swadesh: The metric type is decided by the original domain?I am not sure what
benefit you are gaining over the IGP domain.

Reshma: If you are low cost in one route in one domain, and delay in the metric
in another domain.

Shraddha: Can carry different metric types in different routes. Only metric of
the same type can be accumulated.

Swadesh: Is the metric type used to represent the intent? Try to understand the
advantage. Shraddha/Reshma: We should discuss this on the list.

### 6. BGP SR Policy Extensions to Enable IFIT [Giuseppe Fioccola] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-ietf-idr-sr-policy-ifit/

No questions on the meeting.

### 7. Advertising p2mp policies in BGP [Hooman Bidgoli] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy/

Gyan Mishra:

Huaimo: We don't have BGP sessions to P nodes. P2MP SR Policy needs to send
instructions to P nodes.

Hooman: Does not require BGP sessions for each node, can use P2P Policy between
nodes. If need replication segment Hop by Hop, will need BGP session to each
node.

Gyan: Is SRv6 and inter-domain covered?

Hooman: It is covered in the drafts.

Gyan: There is a mechanism in PCE WG.  How does this interact with this
mechanism? Hooman: The PCE mechanisms are a second mechanisms.

Jeff: The draft also presented in BESS, the content will be developed in IDR.

### 8. BGP-LS with Multi-topology for SR based VTN [Cong Li] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-xie-idr-bgpls-sr-vtn-mt/

Ketan (from chat): this is an informational document with really no signaling
or protocol extensions for BGP-LS. Do we need such a draft? Note that consumers
and use-cases for use of BGP-LS is outside the scope of BGP-LS. Best case,
considering adding necessary text to the corresponding LSR draft ... which is
also informational.

Jie (from chat): Yes this is an informational document. Comparing to the LSR
draft, it also covers the distribution of inter domain topology and TE
attributes for a VTN.

Les Ginsberg (from chat):
@Jie +1 to what Ketan has said. The draft simply describes what is discussed in
other drafts - I see no need for it. Time would be better spent in making sure
all the drafts referenced in draft-xie-idr-bgpls-sr-vtn-mt are themselves
complete.09:00:43 Jie Dong (from chat): @Les we had similar discussion about
the LSR draft, the consensus was it is useful to document the usage of MT for
VTNs.

### 9. Deterministic Route Redistribution into BGP [Enke Chen] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-chen-bgp-redist/
  Note: Enke requested WG Adoption after -03.txt is posted.

John Scudder (from chat):
I'm pretty sure this is a rerun (with different details) of a presentation Rich
Woundy gave around IETF-30 or so, plus or minus. Same problem (ish). Same
solution (ish). It even was implemented in early GateD, but poorly documented
and nobody understood it. Maybe we can make the fix stick this time.08:50:43

### 10. Update and Discussion on RD-ORF Solutions [Gyan Mishra/Aijun Wang] (10
mins)
  https://datatracker.ietf.org/doc/html/draft-wang-idr-rd-orf/
  https://tools.ietf.org/html/draft-wang-idr-vpn-routes-control-analysis/

  Jeff: Will have an interim on Auguest 23 to discuss this topic.

### 11. (If time allows) Connecting IPv4 Islands over IPv6 MPLS using 4PE [Gyan
Mishra] (5 mins)
  https://tools.ietf.org/html/draft-mishra-v4-islands-v6-mpls-4PE/

  No time to present. May move to the second idr session.

  Sue: Will send out the draft adoption list.

[5 minutes for switching]

## Session 2: Friday, 14:30-15:30 (UTC -7), July 30, 2021

### 0. Agenda bashing (5 mins)

### 1. BGP over Quic [Zhenbin Li/Shuanglong Chen] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-chen-idr-bgp-over-quic/

Sergey Fomin: Useful and interesting work. Comment 1: The delay in BGP
connection establishment may not be an issue. It is a minor benefit. Comment 2:
Not clear how the certificate management could be simplified with BGP over Quic.

Jeff Haas: The certificate part will be an interesting work. TLS can provide
integrity and privacy, but cannot protect the session agaisnt some types of
attacks. Something in TCP-AO is not seen in the TLS implementations.

Robin Li: For the delay part, in scenarios where a large amount of BGP sessions
are reestablished, the session setup time may become an issue.

Sergey Fomin: If consider the overall time for BGP session establishment, the
route exchange and the installation, the session setup time is really
negligible. Can discuss further offline.

(From chat)

Tom Hill:
Robin - have you measured any improvement in seeding a full DFZ table? I recall
some time ago that there was a lot of excitement over 9000b MTU for BGP
convergence speed. Does QUIC help here?

Jared Mauch:
@Jeff - w/ TLS, what if the certificate expires in the middle of the session?
(worried)

Tom Hill:
In reference to Sergey's point, I guess that if QUIC were to 'make BGP better',
it may be there.

Jared Mauch:
P-MTU for iBGP works well for BGP.. i've not seen the transport be the slow
part of BGP in a very long time

Tony Li:
Typically, BGP is not transport limited.

Tom Hill:
If it doesn't help, so be it. Curious to hear if any testing has been
undertaken.

Jeffrey Haas:
Jared, bgp works fine over all sorts of things so on one part I'm not worried.
On another part, my work in tls libraries has shown they're buggy and may not
be up to bgp sessions staying up for months to years. ia Sergey Fomin: QUIC
could be an interested application as a replacement for some current BGP over
IPSec connectivity usecases. Think like SDwan, cloud peerings, etc

Jared Mauch:
Yes, i share your concern about long lived sessions.. by the time one bounces
the TSV/Q people may have rev'ed it a few times (Keep in mind many networks may
see TCP/BGP sessions up in times measured in years)

### 2. BGP Dissemination of FlowSpec for Transport Aware Mobility [Linda
Dunbar] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-dmc-idr-flowspec-tn-aware-mobility/

Sue:Encourage authors to indicate whether this is for flowspec v1 or flowspec
v2. Is this for flowspec v1?

Linda: Yes this is for flowspec v1.

Jeff: The indirection ID part is compatible with flowspec v1. Authors are
encouraged to talk about the interaction with other actions today. The
interaction and control of multiple actions is one major motivation for v2. The
application of the matching criteria belongs to v1, encourage authors to
consider the ordering with other flowspec rules.

Linda: Will add text to address the ordering issue.

Tianji Jiang: UPF+PE is confusing. To which node the Flowspec rules are sent
from the controller?

Linda: The flowspec control goes to PE. More information in the RTGWG
presentation on Wed.

Kausik: Another draft in RTGWG has more information covering the UPF.

Sue: Please send further comments to the list. Will have longer discussion
about Flowspec on an interim.

### 3. Flowspec TTL (Time to Live) Match [Philippe Bergeon] (7 mins)
  https://datatracker.ietf.org/doc/html/draft-bergeon-flowspec-ttl-match/

Sue: Is this for both v1 and v2?

Philippe: Yes.

Jeff: This is ddos related, while it requires a new component type, which need
to be done in V2. draft-haas-flowspec-capability-bits proposed to try to carry
new things in v1.

Philippe: Does it mean adding new component without that draft is impossible?

Jeff Haas: The consensus from the interim was to not work on the capability-bit
draft for v1 and do this kind of extensions in v2.

Sue: The feedback from the intrim was to move v2 quickly forward. Appreciate to
put this feature in V2.

(From chat)

Robert Raszuk:
Well TTL could be added to v1 only if we define that it is single match in
MP_REACH. So it would not impact any of other MP_REACH fields. Even without
adding capabilities

Jeff Tantsura:
only range would be meaningful.

Jeffrey Haas:
you cannot add flowspec component types without causing session resets.

### 4. Extended Communities Derived from Route Targets [Jeffrey Zhang] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-zzhang-idr-rt-derived-community/

  https://datatracker.ietf.org/doc/html/draft-zzhang-idr-tunnel-encapsulation-label-stack/

4.1 label stack in Tunnel Encaps

Ask for WG adoption on label-stack draft.

Jie Dong (from chat):
@Jeffrey, can BGP SR policy provide the steering functionality you want?

4.2 RT derived Extended Communities

Ask for WG adoption of this informational draft.

### 5. BGP for BIER-TE Path [Huaimo Chen] (10 mins)
  https://datatracker.ietf.org/doc/html/draft-chen-idr-bier-te-path/

Jeff Tantsura (from chat):
@Huaimo - requests BIER-TE path over BGP?

Sue: Please take comments to the list. May take a look at the interation
between PMSI tunnel attribute and this work.

Tony Przygienda (from chat):
Pmsi signaling doesn’t encode the path normally just Id.

### 6. (If time allows) BGP Peer Auto-Configuration [Venkata Shiva] (5 mins)
  https://datatracker.ietf.org/doc/html/draft-minto-idr-bgp-autodiscovery/

Acee: This is similar to Xiaohu's autodiscovery draft, with different encoding.

Jeyananth: This is simple protocol without two-way mechanism.

Jeff Haas: The lack of state machine is the biggest changes comparing to
Xiaohu's draft, which is with LDP thinking. The design team's consideration is
not to prefer the session based approach, but more prefer the annoucement based
like the L2 solutions.

Acee: We certainly need more auto discovery proposals.

Jeff Haas: The design team have agreed on the requirements and the contents, we
will work on the PDU encodings. Please provide proposals and comments to the
list.

Sue: Today is the deadline to send the comments on the BGP autoconf
requirements.

[5 minutes for switching]