Skip to main content

Minutes IETF116: idr: Thu 00:30
minutes-116-idr-202303300030-00

Meeting Minutes Inter-Domain Routing (idr) WG
Date and time 2023-03-30 00:30
Title Minutes IETF116: idr: Thu 00:30
State Active
Other versions markdown
Last updated 2023-04-10

minutes-116-idr-202303300030-00

0. Agenda bashing and Chairs' Slides (5 mins)

[Chairs]

Sue: Drafts in adoption poll needs further feedback, please provide your
opinion this week.

Keyur: We will continue the discussion of some topics on the upcoming
interim.

1. BGP Color-Aware Routing (CAR) (10 mins)

draft-ietf-idr-bgp-car-01
[Dhananjaya Rao]

No comments.

2. BGP Classful Transport Planes (10 mins)

draft-ietf-idr-bgp-ct-01
[Natarajan Venkataraman]

Dhananjaya Rao: IOS-XR does not support BGP-CT. Probably not refer to it
in the CT interop slides.

Jeff: Please continue the discussion on the list.

Sue: I'm sending calls to the WG to solve the open issues on CAR and CT
drafts.

(from chat)

Ketan Talaulikar: @Natrajan Venkataraman, a suggestion. Saying there was
an interop of your CT implementation with Cisco is a misrepresentation.
You are right to call it an "experiment" in sending CT faked as SAFI
128. Would you please care to update/clarify on this to the list and
wherever this is posted?
It is interesting that you choose Cisco implementation for this
"experiment" instead of some open source implementation. Could you share
your reasons behind such a choice?

Kaliraj Vairavakkalai: @Ketan Talaulikar, It is indeed mentioned as an
"interop experiment" in the ietf "hackathon" where it was presented.
https://github.com/IETF-Hackathon/ietf115-project-presentations/blob/main/ietf-115-bgp-ct-junos-ios-xr-hackathon.pptx

pls go thru the link, and demo video - where we clearly mention this is
an 'interesting experiment'.
This experiment shows how the procedures of BGP-CT can be implemented
easily on another implemention, one step at a time.

Kaliraj Vairavakkalai: partial interop (and even End-to-end intent based
forwarding) can be achieved even with a device not supporting CT as one
of the BNs in the forwarding path. Ofcourse this hackathon experiemnt
is done with some hacks (like using SAFI-128).
That just shows the power of re-using RFC-8277 and 4364 procedures!

draft-ietf-idr-bgp-ls-sr-policy-00
draft-ietf-idr-bgp-ls-te-path-00
[Ketan Talaulikar]

No comments.

4. BGP YANG Model (10 mins)

draft-ietf-idr-bgp-model-16
[Mahesh Jethanandani & Jeff Haas]

Keyur: Jie will be the shepherd to provide the shepherding report.

5. Advertising In-situ Flow Information Telemetry (IFIT) Capabilities in BGP (5 mins)

draft-ietf-idr-bgp-ifit-capabilities-02
[Bruno Decraene]

Sue: This document refers to draft-ietf-idr-sr-policy-ifit is waiting
for implementations, would be helpful if you could provide
implementations information, so that that document could go to WG LC.

6. BGP SR Policy Extensions for Template (10 mins)

draft-zhang-idr-sr-policy-template-02
[Ka Zhang]

Jeff Haas: Note that Template number is local and not coordinated. If it
is used for something out of SR Policy, there may be globally-issues to
be further considered.

(from chat)

Shraddha Hegde:
Sorry for the microphone issue. My question was can you use template
name instead of template ID?

Ka Zhang: @Shraddha Hegde, I think template name may be ok, but template
id is enough, and it is shorter and simple to use in this case.

Shraddha Hegde: @KaZhang names are more operationally friendly than the
IDs. Also allowing a regular expression for names instead of exact names
can be helpful

Aijun Wang: For template ID draft, because there are many parameters in
the SR policy, so there will be many combination of the possible policy
template. The controller and the headend need also synchronize the
contents of so many policy templates?

Ka Zhang: There won't be too many templates on the headend, different SR
Policies can share the same template. And in application, we may use one
template for all the primary paths of all policies and another template
for backup path. And all configurations can be synchronized by
netconf/yang.

Jeff Haas: One consideration for names vs. ids is that text strings in
the names introduce internationalization considerations. That might make
some forms of vendor neutral behavior challenging, even if it's a
preferable operational model.

7. BGP SR Policy Extensions for Segment List Identifier (10 mins)

draft-lin-idr-sr-policy-seglist-id-02
[Mengxiao Chen]

Wang Aijun: Difference between the path-id and New defined Segment-List
Identifier?

Answer by Mengxiao: The purpose are different. Path ID is similar to the
Path ID in PCEP and YANG. Path segment is mainly for path measurement
and correlation. One coauthor is also the author of the path segment
draft, discussed this issue and think there is no contrdiction between 2
drafts.

(from chat)
Aijun: There is the Path ID (segment) defined for SR policy, so what's
the reason/scenario to define the segment list identifier then?

Cheng Li: Path segment can be used in control plane I think. Btw, I
think we see some drafts defining some similar terms...

Liu Yao: @mengxiao we defined the sid list id in
draft-lp-idr-sr-path-protection you may want to check that.

Changwang Lin: The path-seglist id is used to identify the forwarding
plane, not the management plane.
In the case that both PCE and YANG are identified by ID and name, it is
suggested that the seglist should also have the identification of the
management plane. The application scenario is statistics reporting and
configuration delivery

Aijun: It's better to add some descriptions that why the Path ID can't
be used in the the mentioned scenario.

Jeffrey Haas: The seglist id chat is looking interesting. May the chairs
ask that the conversation be summarized and continued on the idr mail
list?

Ka Zhang: There is Segment List that is configured in the headnode, and
Segment List that is ceated by controller, no matter which method, there
may need a segment ID, then how to process the conflict?

8. Advertising SID Algorithm Information in BGP (10 mins)

draft-peng-idr-segment-routing-te-policy-attr-04
[Yao Liu]

No question or comment.

9. Loop Prevention for Route Import Between Protocols (10 mins)

draft-li-idr-inter-protocol-anti-loop-00
[Wenyan Li]

(from chat)

Randy Bush: it's a little unusual to import from bgp into igp.

Jeff Haas: I suspect you have good wisdom to share on this, Randy.

Randy Bush: no wisdom, just many bad events over decades, remember 7007
incident?

Ketan Talaulikar: and those events still happen :-(

Keyur Patel: hmm redistributing/importing bgp routes in igp and then
back into bgp. Fun!!

Haibo Wang: The dual-egress scenario occurs from time to time.

Fang Gao: Many IGP instance may bind to the same VPN ID. Should add some
description about this scenario.

David Lamparter: This may be better fit in RTGWG.

Jeff Haas: Have you presented this in LSR WG? Suggest to do that. Please
take a look at RFC 1403/1364 (and 1925(2.11)) on a related idea.

10. Generic Metric for the AIGP attribute (10 mins)

draft-ssangli-idr-bgp-generic-metric-aigp-04
[Srihari Sangli]

Linda Dunbar: If one of the domains does not run IGP (for example
overlay), what type of metrics to use for propogation? New ones or still
the one in RFC 7311

Srihari: For example for BGP-LU based network, there will still be a
metric type used in the underlay.

Linda: Can I define other metric types?

Srihari: Yes it is definable.

David Lampater: Evern the metric types in different domains are the
same, they may have different decisions in how to implement the metric,
then the metric may not be interchangable. Does it require some
agreement on the meaning of the metric?

Srihari: To have an end-to-end intent path across domains, the
translation or normalization of metrics is based on domain or operator's
policy.

Louis Chan: Suggest to add unusable type of matrics.

11. MP-BGP Extension and the Procedures for IPv4/IPv6 Mapping Advertisement (10 mins)

draft-xie-idr-mpbgp-extension-4map6-00
[Xing Li]

Guozhen Dong: As coauthor of this draft, welcome comments.

Jeff Haas: The new path attribute has not only the information of addrss
mapping, but also the bgp path attributes of the original BGP message.
RFC 6368 provides a feature of carrying tunneled BGP attributes. Suggest
to check whether that mechanism can be used for the tunneled attributes.

Jeff Haas: https://www.rfc-editor.org/rfc/rfc6368.html - this is the RFC
for tunneling path attributes mentioned during the second to last
presentation of draft-xie-idr-mpbgp-extension-4map6.

12. Connecting IPv4 Islands over IPv6 Core using IPv4 Provider Edge Routers (4PE) (5 mins)

draft-mishra-idr-v4-islands-v6-core-4pe-03
[Gyan Mishra]

Keyur: This is IDR WG (draft asked for WG adoption in BESS).

Stephane: These are building blocks which are already defined. How about
have a draft more informational on the architecture? For data plane
mechanisms in this draft, not sure IDR is the right place.

Ben Maddison: We run 6PE in the network. Having such information
documented is helpful.