13:00-15:00 (CET) Tuesday session II
Room: Ballroom
[Chairs]
Sue introduced the status of documents in IDR.
draft-lin-idr-sr-epe-over-l2bundle-03
[Mengxiao Chen / Changwang Lin]
No comment.
draft-zzd-idr-sr-policy-scheduling-03
[Li Zhang]
Duruv: The PCE RFC is for RSVP-TE, there are also documents in TEAS
talks about scheduled resources, also focusing RSVP-TE now. The encoding
is a little different, suggest to have consistency between protocols.
Fang Gao: A simple question. SR Policy is controller based computation.
Are you proposing a data plane (device based) solution? Do you have a
use case?
Li: The data plane is the same. It is still SR Policy.
Fang Gao: Can the controller trigger the path switch on time?
Ketan: Do we need the protocol encoding here? Why couldn't controller
run a scheduler and download the path when it is the time?
Jie: With the tidal usecase the scheduling is predictable, so that the
policy sheduling can be pre-provisioned to the headend and take effect
at the specific time precisely.
Ketan: Maybe need to see what is in the TVR architecture.
Jie: Agree.
Jeff: what is the format of the 32-bit time value in the encoding?
32-bit Unix time value will stop working in 2038.
Andrew: Make sure TVR is aware of this work. It could have some impact
there.
Li: The tidal network use case has been documented in TVR use case
draft. Think the protocol work belongs to IDR.
draft-liu-idr-bgp-sr-policy-cp-threshold-00
[Yisong Liu / Changwang Lin]
No comment.
draft-smn-idr-inter-domain-ibgp-02
[Krzysztof Szarkowicz]
Keyur: As WG chair. The draft tries to move Option A/B/C to IBGP. Option
A/B/C are standardized for VPN and now belongs to BESS WG, please go to
BESS WG.
Without chair hat, there is a RFC in BESS about IBGP PE-CE, you need to
have a section about the pros and cons of PE-CE or stocking IBGP.
David Lamparter: Can you make the draft title more specific? It is about
interconnecting VPNs.
draft-wang-sidrops-fcbgp-framework-00
[Zhuotao Liu]
Keyur: As WG chair, suggest to present in SIDROPS also. As WG member,
you may think about decentralize this to solve different kinds of dos
attack. In term of scale and convergence performance, need to consider
router's CPU are different from computer CPUs.
Jeff: The procedure in the draft is incomplete. Need to talk more about
what goes into the path attributes. This is close to SoBGP, while replay
and spoofing could be easier.
Zhuotao: For the replay attack, plan to add timestamp. And think with
pathlet it still can secure the entire path.
Jeff: Then it means you need to rely on the immediate upstream to tell
you the truth.
Andrew: As operator without AD hat, have great concern about RIR based
route invalidation.
Randy Bush: We are in the condition now with ROV, nobody complains about
serious breakage.
Andrew: It does not mean it will not happen. Take a look at the number
of routes being signed in Africa and ask why.
draft-geng-idr-bgp-savnet-01
[Nan Geng]
David Lamparter: Disagree with the security considerations in the draft,
need to have more text there for eBGP. The presented mechanism on slide
6 is not clear to me.
Nan Geng: Brief explanation of slide 6.
Antoin: How to validate the prefixes which are not routed? It needs more
clarification.
Keyur: As WG chair, most of this work belongs to SAVNET WG. As WG
member, you may need to consider more complex cases, such as when fast
convergence is enabled.
draft-liu-sidrops-community-authentication-00
[Jessie Hui Wang]
Jeff: This needs to be reviewed by SIDROPS. The computational complexity
of securing communities would be higher than BGPsec. The encoding of the
new attribute proposed needs some more work.
David Lamparter: Need a real example to show the attack is on the
community itself.
draft-cheng-idr-inter-domain-consistency
[Shengnan Yue]
Keyur: As WG chair, suggest to present in SIDROPS also. Without chair
hat, suggest to run comparison against BGPsec and ASPA to see how this
is better.
draft-hares-idr-flowspec-v2-05
draft-hares-idr-flowspec-v2-ddos-00
[Susan Hares]
No comments.
draft-shen-idr-flowspec-traffic-compress-action-01
[Ming Shen / Shuanglong Chen]
Jeff Haas: This feature does not require Flowspec V2, only new BGP
extended community. When the document is stable, can ask for early code
allocation to advance this document soon.
draft-zzd-idr-flowspec-path-scheduling-00
[Li Zhang]
Jeff Haas: This is straightforward, look for more discussion on the
list.
====================================================================
Second IDR Session: November 10, 2023
09:30-11:30 (CET) Friday Session I
Room: Berlin 1/2
[Chairs]
draft-kaliraj-idr-multinexthop-attribute-10
[Kaliraj Vairavakkalai]
Sue: Will start the adoption call on this document on the list.
Satya Mohanty: The capability negotiation may not be needed. This
attribute is defined as non-transitive, which is diverging from the
next-hop capability.
Kaliraj: Agree with the capability part, while think non-transitive is
good to provide additional protection to the network, just need to get
the RRs upgraded.
Jeff: The non-transitivity of this attribute needs to be visited. The WG
needs to review carefully how multi-nexthop attribute behave on the
hop-by-hop base.
Kaliraj: It nexthop is changed to self, this attribute is not
readvertised. Only when nexthop is not changed, the attribute is
reflected as it is.
Keyur: This is more than non-transitive, at eBGP boundary this may needs
to be filtered. Suggest to make it optional-transitive. There are
multiple ways to do the filtering. There are multiple ways to signal
label/SIDs, suggest to provide text on how to coordinate with other
label/SIDs signaling approaches, e.g. prefix SIDs.
Kaliraj: Yes will consider it.
draft-sheng-idr-advertising-saas-path-performance-00
[Hang Shi]
Mankamana: Is BGP the right place for this information? These attributes
can change dynamically. These performance metrics are share fate by many
applications. Why not making it independent?
Hang: The use case is SDWAN, where BGP is used as the control plane.
Keyur: With chair hat on, will you present this in CATS?
Hang: This is a different problem from CATS.
Jeff Haas: There seems to be trend to inject dynamic information to BGP,
may cause problem to BGP convergence. The WG needs to analyse each
proposal. Another question is how many path attributes code points we
end up burning for these. May need to look for a generic mechanism,
which may overlap with the work in CATS.
Louis Chan: Does the use case requires multi-vendor interop? Or suggest
to make it proprietory?
Andrew: Without AD hat, this seems to be related to CATS. Bringing more
and more things to BGP can cause problems for operators.
Keyur: Feedback to Luis, for proprietory implementations, you may want
the TLVs to be registered to avoid conflicts.
draft-ietf-idr-5g-edge-service-metadata-11
[Linda Dunbar]
Jeff Haas: Would like to have more stable document to be ready for code
point allocation.
Ketan: Suggest to use experimental code point in the draft before it is
allocated.
Jeff: Suggest to not ship the code before the code point is allocated.
Abdussalam Baryun: Consider to use RFC 7454 in security considerations.
Loa (from chat): Isn't an upcominf wglc a counter indication for early
allocation?
Jeff Haas: @loa for chat as well minutes, the draft has received enough
changes that early allocation and wglc are probably premature. we'll
continue iterating.
draft-fu-idr-computing-info-notification-domain-01
[Yuexia Fu]
Keyur: As WG chair, need to take this to CATS for further discussion.
Yuexia: This draft focuses on inter-domain, CATS is on single domain for
now.
Jeff Haas: Suggestion to AD, CATS may needs to be recharted for
inter-domain also. This draft is more abstract than the prior two
presentations. Suggest to continue the discussion in CATS.
Sue: BGP-LS can support distribution of a lot of information, what else
is needed?
Yuexia: This draft focuses on computing information notification among
routers. BGP-LS is not in our consideration.
John Scudder: As RTG AD, this is supposed to be in scope for CATS. It is
premature to develop solutions before the cats architecture is finished.
As individual participant, don't think BGP is the right protocol for
this.
draft-ietf-idr-rtc-hierarchical-rr-03
[Jie Dong]
Keyur: As WG member, existing RTC implementations do the override the
attributes on RR.
Jie: That rule was not for the hierarchical RR case. The Cluster_LIST
ID was not covered in the RTC RFC.
Jeff Haas: There are implementations of using add-path mechanism to
solve this problems, not aware of implementation of another option. Was
hoping to considedr WG LC. Now it is time to restart the conversation.
Krishnaswamy: Can't this be treated similar as AS loop? Could use policy
to allow the loop for RTC AFI/SAFI.
Jie: That may be one option, but in some cases you may want to detect
the real loop.
Keyur: If you do that, you definitely need to carry NO_EXPORT to break
the propagation. And confirm that for hierarchical RR case, the
implementations use add_path.
draft-mohanty-idr-rtc-hierarchical-rr-01
[Satya Mohanty]
Keyur: Whatever you do, NO_EXPORT is something you should consider. If
there is link between lowest and highest level, need to consider how to
break a loop. There is a draft on route oscilation in hierarchical RR
scenarios, please take a look.
Satya: The use case is for canonical networks. Think you mean
NO_Advertise community.
Jeff: BGP is not a flooding protocol, we cannot get the properties of a
flooding protocol. Juniper has one similar solution to overwrite some of
the CLUSTER_LIST, but there is concern about loop in some cases.
No-export or No-advertise has limitations in inter-domain cases.
John Scudder: The first solution of editing the CLUSTER_LIST scares me,
it is probably a bad idea, need careful analysis. Solution 2 only uses
the received route for filter programming, it seems good.
Satya: The second solution was the original solution.
Jie: There are two potential issues with the rewrite mechanism. The
first one is the loop in specific topology. The second is when the
higher level RR only receives the RTC route from one client, advertising
it back to the sender would create unncessary distribution tree for the
VPN route.
Jeff: The document Jie presented is the WG adopted work. Can you refresh
it Jie? We can do further analysis based on Satya's proposal.
draft-xie-idr-mpbgp-extension-4map6-07
[Chongfeng Xie/Xing Li]
Nan Geng: Thanks for the update. One suggestion: the security
consideration can be refined further about the potential risks with this
extension.
Ketan: Had some discussion offline with the authors. There are two
scenarios covered, one is connecting IPv4 host to IPv4 host via IPv6
only network, there is existing encapsulation solution in RFC 5449,
think no need of translation solution for that. Another use case is
connection between IPv6 host and IPv4 server. Need to read the draft
further. Mapping may be needed, while not sure something is needed in
BGP for this.
Chongfeng: This solution is compatible with both translation and
encapsultion. This has been disussed in previous meetings. Can talk
about it more offline.
Gyan: Is there any processing overhead on the PE for the mapping?
Chongfeng: This is stateless mapping, do not need to maintain port level
or user level mapping information. The scalability can be improved.
Jeff: Please continue the discussion offline and look for an update
version.
Jeff (from chat): This is a flavor of interdomain provisioning for
cgnat. I agree with ketan that the ability to carry the v4 piece is
covered by rfc 5549. The encapsulation and translation is the piece that
seems to need further discussion.
draft-mishra-idr-v4-islands-v6-core-4pe-06
[Gyan Mishra]
No time for comments.
draft-ssangli-idr-bgp-generic-metric-aigp-05
[Srihari Sangli]
No time for comments.
draft-ietf-idr-bgp-bfd-strict-mode-11
[Albert Fu]
Tony P: 2 recommendations. 1: is there any deviation between OSPF and
BGP behavior? 2. There is another unclear behavior, which in deployment,
was causing havoc. You can flip on the remote side, the BFD up and down.
This document may be a good place to document that.
Jeff: The BFD admin downstate, which you're talking about, is explicitly
called out of this draft.
Keyur: Keeper lives were used from what I recall, for a really good,
buffering point against Kernels that could not generate Fin when a
process in the user plane crashed. Because you delay the keepalive till
BFD is up, but the user plan crashes and the kernel cannot generate a
FIN, how to solve that? That would delay 180 seconds.
Jeff: There is a deadband timer for exactly that reason. We will not
linger in there forever.