Chairs:
Susan Hares <skh@ndzh.com>
Jeffrey Haas <jhaas@pfrc.org>
Keyur Patel <keyur@arrcus.com>
Secretary:
Jie Dong <jie.dong@huawei.com>
https://datatracker.ietf.org/meeting/125/session/idr/
1st session: https://meetecho-sin.ietf.org/client/?session=35067
2nd session: https://meetecho-sin.ietf.org/client/?session=35066
https://notes.ietf.org/notes-ietf-125-idr
https://zulip.ietf.org/#narrow/stream/idr
14:00 - 15:30 (UTC+8) Tuesday session III
Room: Grand Ballroom 1
[Chairs]
draft-ietf-idr-bgp-model-19
[Jeff Haas]
draft-wang-idr-dpf-00
[Kevin Wang]
Nan Geng: Is there any influence to existing routing policies?
Kevin: In DC, the intent is to minimize the policy. And policy precedes
the color.
Sandy Zhang: Do you consider to just color the routes, not to color the
BGP session?
Kevin: The routes are mapped to the color of the sessions.
Jeff Tantsura: In the primary and backup case, where is the backup paths
implemented, how are they installed in the FIB?
Sue: Need to take the discussion to the list.
Sue: Why use open capability for this instead of all the color
mechanisms?
Jeff Tantsura: Need to be specific about the implemenation.
(from chat)
Susan Hares
14:25
For Kevin - there are a number of ways to set color in BGP. In Extended
Communities, in Tunnel Encapsulation, and in NLRIs. Why is it critical
to have color on a BGP session?
Jeffrey Haas
14:28
DC topologies follow routing topologies. So this is the bgp
approximation for "coloring the link".
draft-zhang-idr-portid-ec-00
[Rui Zhuang]
Kireeti Kompella: Should not use BGP for this.
Jeff Tantsura: Explain how to aggregate routes with port-specific
communities, there can be scalability issue.
[Xiaohu Xu]
Stephane: Why not reusing the existing link bandwidth ext. community?
Xiaohu: For 5 stage clos network, a single link bandwidth ext. community
is not enough.
Stephane: The ext. community is just a carrier. THinks this is just
another use case of the link bandwidth ext. comm.
Jeff T: The link bandwidth ext. comm has been deployed widely. Need to
be careful and consider how they interact with each other.
Stephane: Is this in the charter of IDR? This is not BGP.
Susan: This was part of the work when we were doing BGP auto
configuration. Would like to see people's opinion. Can take this into
the charter discussion.
draft-gong-idr-inter-domain-srv6-flex-algo-00
[Liyan Gong]
Krishna: With RFC 9723, color can be mapped to an algorithm. Do we
really need an ext. community to carry the algorithm?
Liyan: Think they are different. RFC 9723 is mainly for SR policy.
Krishna: The color can be mapped to any algorithm.
Yujia: If two domains uses the same algorithm ID with different meaning,
do you think some coordination or translation policy at the AS boundary
is needed?
Liyan: It can be the algorithm type, not just the ID. It is for networks
under the same administration. But mapping is possible.
Stephane: That is the reason why CPR was done. CPR is more generic for
multi-domain cases. This one only work in specific case. Need to clarify
that this one is not alternative to CPR, it is just for one simple use
case under the common administration.
(from chat)
Joel Halpern
14:55
I presume there is an unstated restriction that this is only for use
among AS under a common administration, sinc eotherwise this would
violate the rules for SRv6.
draft-zzhang-idr-mpte-signaling-00
[Jeffrey Zhang]
No comment or dicussion during the meeting.
draft-ali-idr-srv6-policy-sl-opt-distribution-02
[Zafar Ali]
Susan: For SR related drafts, need to add this to the queue, please
comment to other drafts to help moving forward.
Susan: Will ask SR related drafts to add one section about which SPRING
function this draft is mapped to.
draft-guo-idr-bgp-security-policy-community-01
[Yangfei Guo]
Stephane: Does it belong to SIDROPS?
Susan: Discussed this today, it should go to SIDROPS.
Stephane: It may be misused and create new security issues.
Yujia Gao: It mentons out-of-band mechanisms such as RPKI may be a good
fit, then how should we position this large community based approach? Is
it mainly for incremental deployment or a long-term security mechanism?
Susan: Please bring this to SIDROPS for standardization.
(from chat)
Jeffrey Haas
15:17
The "downstream intent" for what to do about validation failures is
nice, but problematic because it can be manipulated in a hop by hop
fashion
Jeffrey Haas
15:18
Also, there is no such thing as a "reserved large community". The large
community authors made that imossible.
[Chairs]
Susan: Need feedback on the charter. The BGP auto-configuration goes to
LSVR.
Ketan: All the work are explicitly listed out. If anything not captured,
please let us know.
Susan: We are trying to process things effectively.
Jeff Haas: Channeling some comments that IDR is too wide and need to
move some work elsewhere. It may make IDR move smoother, but it does not
address the problem as this is shared technology.
Stephane: Is there any deadline for the charter update?
Ketan: Sooner would be better.
Stephane: Suggest to give a deadline to collect feedback.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 90 minutes
9:00 - 11:00 (UTC+8) Friday Session I
Room: Guangdong
Susan Hares: Highlight the early allocation rules.
draft-ietf-idr-sr-policy-metric-05
[Ka Zhang]
Susan Hares: Suggest to talk to IANA desk about the registry
allocation/update.
Zhenqiang: As discussed this should be merged with another draft.
Ka Zhang: Will discuss it offline.
draft-ietf-idr-bgp-ls-bgp-only-fabric-04
[Aravind Babu MahendraBabu]
Susan: Is there anything we need to check before early allocation?
Ketan: As coauthor we will ask for code point allocation soon, while it
will be normal allocation process with expert review.
Keyur: As WG member, should cross-reference this with LSVR, as this is
mainly for DC use case, which is handled by LSVR.
Kireeti: Think this draft does what I need. Will read the draft and talk
to the authors. May need to add node capability information. There is
one draft in LSR for the advertisment of nodes' MPTE capability. This
can also be done in BGP-LS.
Aravind: We can consider to add further extensions.
draft-lin-idr-interface-index-capability-00
[Changwang Lin]
Kireeti Kompella：In the theme of using BGP as IGP, this is useful.
Acee Lindem: This would help for one of the cases in BGP-LS-SPF as well，
to disambiguate unnumbered links in BGP-LS-SPF.
Susan Hares: Encourage people to think carefully about this draft,
whether it worths the risk.
Kireeti Kompella：Want to know why IGP is not used in DC.
Tony Li: OSPF was used for DC, and some issues was found due to unmature
implementation. later someone suggested to use BGP for DC.
Jeff Haas: There are several proposals about exposing link endpoint
information in different WGs. Would suggest the WG to pick a consistent
solution.
(from chat)
Andrew Stone
00:30:41
I'm a bit unclear in the BGP EPE case why you need a reverse correlation
check when it's meant for "Egress" steering? i.e you don't need a
reverse EPE SID to steer out your egress peer SID
Vishnu Beeram
00:30:45
Given the many use cases proposed that require topology acquisition in
DCs, it is time to revisit RFC 7938.
Jie Dong
00:33:57
Is this part of the BGP peer discovery?
And it seems DC would be the major use case?
Acee Lindem
00:36:38
@jie We could also learn the interface index via any of the single-hop
BGP discovery mechanisms.
draft-li-idr-bgp-nrp-00
[Zhenqiang Li]
Zafar: The color extended community can be used to express the intent
with BGP route. New extension is not needed. Think the concept of NRP is
loosely defined, can be control plane or data plane instances.
Clarification is needed.
Susan: Will need to talk to SPRING about this.
(from chat)
Vishnu Beeram
09:47
You can use existing service-mapping mechanisms/protocol-extensions
(e.g., service "color") to map the service to an NRP policy at the
head-end. I don't see the explicit need to carry the NRP ID as a
Community.
draft-li-idr-bgp-sr-policy-bfd-extension-01
[Song Liu]
Jeff Haas: As IDR and BFD chair, it is not necessary to put all BFD
stuff into BGP. Suggest only to pass the minimal information.
Implemenations which pass this information in control plane are not used
to setup the timer for BFD session, suggest to remove those.
Zafar: This may be quite chatty. Maybe some profile related design could
be used to avoid frequent change of the parameters. This is supported by
PCEP.
Zhenqiang: This is to align BGP and PCEP in SR Policy. PCEP has been
extended for BFD parameter configuration.
Susan: Suggest to
(from chat)
Jeffrey Haas
00:56:02
Repeating in chat for @song Liu, only pass the minimal information BFD
needs. Discriminator. Maybe end point. The timers should not be sent in
the state.
I agree this use case can't use RFC 9026 encoding - this is per SR path.
Andrew Stone
00:56:51
+1 to Zafar. If the attributes are often common or similar amonst many
tunnels - use a policy/profile.
Zafar Ali
00:58:37
Yes indeed that also enables sharing of profiles with Policies.
draft-liu-idr-sr-segment-list-optimize-02
[Yisong Liu]
Susan Hares: Is there some deployment experience which indicate this
would be helpful for SRv6?
Yisong Liu: Yes, SR Policy with explicit path and loose path need to be
distinguished.
Susan Hares: Suggest to share the experience information with the WG.
draft-lp-idr-bgp-ls-sr-policy-supplement-06
[Yao Liu]
Zafar: For the S flag, is there any implementation that allow admin shut
of SL in a policy?
Yao Liu: It depends on the operators' choice, e.g. for energy saving or
traffice replanning.
Susan: Do you have implementation of this draft?
Yao: Only the S flag is implemented. There is no implmentation of MNA
AFAIK.
(from chat)
Ketan Talaulikar
01:13:33
@Yao Liu, consider if setting weigth of the SL to 0 achieves the same
objective?
draft-tong-idr-bgp-ls-sav-rule-04
[Jing Zhao]
(from chat)
Jeffrey Haas
01:15:36
IGP folk should decide if they want this much state in the IGP for this
use case. :-)
Jeffrey Haas
01:16:01
customer cones are per-interface.
draft-smm-bess-alt-label-00
[Mankamana Mishra]
draft-lll-idr-flowspec-filter-qp
[Jinming Li]
Jeff Tantsura: Think this does not need to be done centrally. Devices
can do hashing based on 6-tuple including the QP.
Jeff Haas: How is the traffic steered? Based on 5-tuple or something
else?
Jinming: It has two steps. Steering to SR Policy, then hashing based on
the 6-tuple to different SLs.
Jeff: If you don't do the steering based on the tuples, a Flowspec match
rule is not helpful.
Jeff Haas: Another question is how fast do you need to program? Flowspec
is not a fast mechanism.
Aijun: Similar to Jeff's comments. QP is in the payload, which is
difficult for device to match.
(from chat)
Jeffrey Haas
01:15:36
IGP folk should decide if they want this much state in the IGP for this
use case. :-)
Jeffrey Haas
01:16:01
customer cones are per-interface.
draft-cui-idr-flowspec-feedback-binding-00
[Yujia Gao]
Susan Hares: We will have an interim discussion on Flowspec in April or
May.
Zhenqiang: This is useful. Can work togehter on the framework and figure
out the suitable solutions.
draft-wang-idr-flowspec-dip-origin-as-filter-12
draft-wang-idr-flowspec-sip-origin-as-filter-00
draft-wu-idr-flowspec-dip-community-filter-01
draft-wu-idr-flowspec-sip-community-filter-00
[Yang Huang]
Susan Hares: There is many work to do on Flowspec.
Aijun: See the benefit of adding the new filters. Flowspec should not
limit its filters to the fields in packets.
(from chat)
Jeffrey Haas
01:50:06
Perversely, FIB state is often already decorated by BGP information for
flow telemetry protocols like IPFIX
But it's not in the forwarding state usually
draft-li-idr-bgp-failure-propagation-convergence-01
[Yuhang Li]
Susan Hares: Is there requirements for BGP convergence optimization in
today's scenarios, either in DC or edge, etc.? Please give the authors
your feedback.
Acee Lindem: Link failure is easier than node failures. This problem was
addressed in section 6.5.1 of BGP-SPF [RFC9815] by advertising the
link as down rather than withdrawal.
Aijun: Think this is about BGP convergence problem in inter-AS cases.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 120 minutes