Chairs:
Susan Hares <skh@ndzh.com>
Jeffrey Haas <jhaas@pfrc.org>
Keyur Patel <keyur@arrcus.com>
Secretary:
Jie Dong <jie.dong@huawei.com>
=============================================================
Materials:
https://datatracker.ietf.org/meeting/124/session/idr/
Meetecho:
1st session: https://meetecho-or.ietf.org/client/?session=34607
2nd session: https://meetecho-or.ietf.org/client/?session=34606
Collaborative Note Taking：
https://notes.ietf.org/notes-ietf-124-idr
Chat room:
https://zulip.ietf.org/#narrow/stream/idr
=============================================================
14:30 - 16:30 (UTC-4) Tuesday session III
Room: Viger
[Chairs]
Ketan (as responsible AD): During the charter update, people commented
about the suggestion on IDR focusing on core bgp and moving other work
to a different working group. The question is whether there is overlap
between folks working on these two topics. Is there benefit to allow
each group of folks focus on the work they are interested? Feedbacks are
welcome.
Susan: We tried to use this split for this IETF.
(from chat）
John Scudder: Seems to me (about the charter) that if you feel you might
only attend one of the proposed two WGs maybe the split would be of
benefit to you. If you feel you would need to attend both then maybe the
split is bad for you.
Robert Raszuk: @John ... Not necesarily .. Single WG will get 1-2 slots
of meetings - Two or more WG will get 2 or more times of that
Jeffrey Haas: The secretariat already has a struggle to schedule the
groups we have. We have WGs that don't consistently meet that contend
for the spaces. This doesn't necessarily mean "no more WGs", but it does
mean "these aren't a free thing".
John Scudder: @Robert I don’t think you can count on that. The meeting
room resource is finite.
Jeffrey Haas: There is plenty of opportunity to do interim meetings to
advance the work. Prior experience shows they're not well attended. This
perhaps comments on the urgency of the work.
draft-ietf-idr-bgp4-rfc4271bis-00
[John Scudder]
Stephane: It would fine if we have a pointer to the plan, to let readers
to understand what we are doing.
Keyur Patel (as WG member): Think ISO-10747 is unreadable, hope we are
not going there.
Jeffrey Haas: We are using github to track the process. You can also
send mail to chairs, or the editor for anything you want to address.
draft-ietf-idr-rfc4360-bis-01
[Nat Kao]
Rüdiger Volk: I was tracking the 32-bit ASNs, it took so long to update
the communities to use 32-bit AS space. People may not get 16-bit ASNs
and have to use 32-bit. Not sure if this is a practical problem.
Jeffrey Haas: The current draft does not cover the 32-bit ASNs, there is
a separate draft (RFC 5668) for it. Consider this is not a problem for
VPN use of extended communities. But agree this document should mention
it.
(Note:
https://github.com/ietf-wg-idr/draft-ietf-idr-rfc4360-bis/issues/20)
draft-ietf-bess-ebgp-dmz-08
[Stephane Litkowski]
John Scudder: For clarification, are you saying there is 1 Tera bps
available? Should it be 900 Mbps available?
Stephane Litkowski： It depends on what is the source of the bandwidth
information.
Jeff Tantsura: Implementation-wise the bandwidth is mutiplied by the
number of next-hops. As both implementor and user would like to see it
making progress as standard track. This has been deployed in large scale
networks.
Jeffrey Haas: There is open question between BESS chairs and IDR chairs
about where this document belongs to. Think it is co-owned by both WGs.
BESS is drving the current use case, and potential future use cases
which may need a different encoding. Hope to advance it to WGLC shortly.
draft-litkowski-idr-rtc-interas-03
[Stephane Litkowski]
(from chat)
Robert Raszuk: @Stephane On the RRs just use ADD-PATHS or DIVERSE-PATH
and you are done :)
Jeffrey Haas:
https://datatracker.ietf.org/doc/draft-ietf-idr-rtc-hierarchical-rr/ -
the add-paths solution is deployed by one, possibly two implementations.
Jeffrey Haas: The changes are a minor change to advice on ebgp and
otherwise implementation and operations choice.
Keyur Patel: wondering without the fix how would the current rtc
influence (or rather break) DMZ computations ;)
draft-vroonen-idr-bgp-bestpath-nh-selection-00
[Stephane Litkowski]
Keyur Patel: This is important work, should fasttracking it. Need to be
careful the algorithm should be uniform inside a domain.
Stephane Litkowski: Yes, each time you tune the path selection, you may
create some loop.
Keyur Patel: For tunnel encaps, should have common IGP metrics or they
need to be normalized. For VPN over RFC3107, if there are multipaths to
the loopback address, the normalization would have resulted in some
similar problems.
(from chat)
Robert Raszuk: draft-ietf-idr-bgp-bestpath-selection-criteria-12
Olivier Vroonen: @Robert, it's partially addressed the issue, it doesn't
answer about suboptimal path.
Robert Raszuk: I think Stephane is just highlighting one specific vendor
implementation
Jeffrey Haas: Consider whether that belongs as a 4271-bis consideration.
It's widely implemented, even though it never reached RFC.
Robert Raszuk: To the substance of the issue IMO we should actually use
real performance data plane measurements to BGP NHs (ex: TWAMP) as input
to best path selection. No static local data in this or that inet
draft-decraene-idr-nlri-error-handling-01
[Bruno Decraene]
Jeffrey Haas: There was good discussion on the list, and very strong
opinions. Please take a look at -01 version, then have debate on whether
this can be seen as a resiliency feature.
(from chat)
Keyur Patel: @John Scudder - should this be folded in 4271-bis?
Jeffrey Haas: The "key" term, I'm certainly hoping so.
Jeffrey Haas: Or something similar for long term terminology use.
Jie Dong: One quick question on the non-key topic: Is this mainly for
the existing AFI/SAFIs with non-key information? And do we also consider
to give some suggestion to future design of NLRIs with non-key so that
to have better chance to parse the key part?
Jeffrey Haas: An interesting question Jie is where do we put such
advice?
Jeffrey Haas: If we discuss keys in 4271-bis, this may become useful in
that document.
Robert Raszuk: Non-key objects should not be placed in the NLRIs to
start with ...
draft-scudder-idr-nhc-00
draft-scudder-idr-elc-00
[John Scudder]
No comment or discussion during the meeting.
draft-chen-idr-enhanced-dynamic-cap-01
[Srihari Sangli]
No comment or discussion during the meeting.
draft-ietf-idr-next-next-hop-nodes-00
[Jeff Haas/Kevin Wang]
No comment or discussion during the meeting.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 110 minutes
=============================================================
11:30 - 13:00 (UTC-4) Friday Session II
Room: Laurier
Jeffrey Haas: Emphasized the IETF principle of collaborative document
progress, urging authors and participants to provide cross-review of
proposals, both editorial and technical.
draft-lp-idr-bgp-ls-sr-policy-supplement-03
[Yao Liu]
Zafar Ali: Suggested aligning the backup path discussion with the PCE
working group's work, think it violates the SR architecture. And need to
clarify the administrative shut state of segment list in relation to the
SR policy data model.
Yao Liu: Thanks for the pointer to the PCE discussion, will follow that.
There is already admin shut state for candidate path, and in real
networks, sometimes we do shut the segment list.
Zafar Ali: Or you can also remove segment list.
Susan Hares: We already have an adopted draft on reverse path segment.
How does this work with the PCE multipath work?
Yao Liu: Don't think this draft is related to the reverse path segment
draft. But will take look at it.
Susan Hares: Suggest to post the analysis how it is not related to the
list. Suggest to take a look at the whole reverse path segment related
work.
Jeffrey Haas: Suggest to align the protocol encodings with the subject
matter experts in the Spring Working Group rather than being debated
solely in IDR.
draft-zzd-idr-sr-policy-scheduling-10
[Minxue Wang/Li Zhang]
Zafar Ali: Is the requirement from TVR? This can be done using
controller. This brings a lot of complexity.
Acee Lindem: How would you position this versus schedule YANG model that
actually controls the link, does this advertise what is got from the
YANG model to PCE?
Minxue Wang: One of the use cases is TVR.
Li Zhang: This draft is not only for the TVR requirement. It can be for
the use case described in RFC 8934. So it is more general. The reason of
this extension is described in the draft, in some scenarios the
connection between the headend and the controller may not be stable. It
is needed to adertise the path for a period of time.
Jeffrey Haas: Dhruv had suggested to use the format used in PCE RFC
8934. Suggest to refer to that RFC. There is no big problem in the
encoding, while the use case may be more important. Is this just another
way to do the same thing as other
Susan Hares: Need to have a clear use case for this. If we have use
case, we can make progress. And need to consider do we need multiple
ways for the same functionality.
(from chat)
Jeffrey Haas: For the scheduling draft, I believe the primary bit of
prior feedback was that the scheduler encoding wasn't aligned with other
forms in ietf. @dhruv weren't those comments yours?
Dhruv Dhody: Yes, I was just checking what are the difference, I would
have prefereed if they just refer RFC 8934
Jeffrey Haas: Note for minutes: scheduling draft requesting adoption
Dhruv Dhody: But the present are asking a bigger question to use TVR
instead?
Dhruv Dhody: Another note is PCE RFC does scheduling at CP level only
and this one is also proposing at per-SL.
Jie Dong: Yes, this is about the scheduling of BGP SR Policy
Jeffrey Haas: The contentious discussion seems (from my perspective) to
be about "there is more than one way to schedule things". The question
is whether the mechanisms are discordant.
Keyur Patel: @jie - quick question... how do we enforce if these
policies are enforced by the routers? Seems like it is a best effort in
sense that the controller sends it and hopes to get accepted by the
router?
Jie Dong: @Keyur, I think it would be similar to the provisioning of SR
Policy today.
Keyur Patel: basically what your saying is newer extensions don't have
anything that says what controller sends is what router will program...
(ie what if router doesn't have the extension)
Boris Khasanov: @Jie - yes, and the same problem, that we cannot be sure
that those SR Policies were actually accepted. No feedback, only
possible via LS - if vendor supports that.
Jeffrey Haas: I think this is a broader concern with sr policy as a
mechanism rather than this extension in particular?
Boris Khasanov: It's just a drawback of BGP SR usage for that purpose.
draft-jiang-idr-sr-policy-composite-path-03
[Changwang Lin]
Susan Hares: Tunnel encaps can have color in it, how does it interact
with the color of consitituent SR Policy?
Changwang Lin: The consistituent SR Policies have the same endpoint, can
use the color to find the sub policy and form the relationship with the
parent policy. Can add some text in the draft.
Susan Hares: My question is what is the precedence between the different
colors? Will send the question to the list.
(from chat)
Jeffrey Haas: note for minutes, request for adoption on changwang's
draft.
Jeffrey Haas: The broad concern about the constituent colors is that
more granular policies may make sense, but they need to work in harmony
with the prior use cases. How do they work with each other?
Dhruv Dhody: Sue - were you asking for relationship between this color
https://www.rfc-editor.org/rfc/rfc9012.html#section-3.4.2, and SR policy
color, and now color in the composite SR-policy?
Jeffrey Haas: That is at least part of my observation, @dhruv
Jeffrey Haas: Our "routes with color" discussions of recent years have
made us very cautious about chasing "where is the color for this?"
Susan Hares: @dhruv - Yes, it could interact with RFC9012 Color TLV,
Color community
Jeffrey Haas: In particular for these SR activities, we need a well
understood hierarchy where color lives. The same thing is true where
various topology identifiers live. MT, NRP, etc.
Jeffrey Haas: Perhaps our authors could consider documenting this
intended hierarchy in the wiki?
Dhruv Dhody: the relationship between SR policy color and composite
candidate path color ought to be what is set in RFC 9256 -
https://www.rfc-editor.org/rfc/rfc9256.html#section-2.13; the color in
RFC9012 and its relationship to color should be as set in
https://www.rfc-editor.org/rfc/rfc9830.html#section-2.3 - may be i am
missing something....
Jeffrey Haas: Framed slightly differently Dhruv, if 9256 is clear about
color... why another draft?
Dhruv Dhody: @jeff - i see this as RFC 9830 BGP extn for SR-policy does
not define how to encode composite SR policy in BGP and the proposed
extensions are doing just that...
draft-li-idr-bgpls-sr-policy-composite-path-08
[Changwang Lin]
Susan Hares: Reiterated the same questions regarding the Color and
Weight as the previous draft, specifically asking about their source
(e.g., head-end, candidate path, link) and the inheritance/precedence
rules. Sue noted the need for specificity in the draft.
Changwang Lin: Let's continue the discussion on the list.
draft-cui-idr-content-filter-flowspec-03
[Yujia Gao]
Maria Matejka: Concerns about the maintainability of P-type/O-type
fields for different tunneling mechanisms (suggesting an IANA table) and
the lack of security considerations, especially regarding potential
oscillations or BGP control plane disruption if misused across AS
boundaries.
Yujia Gao: For the tunneling protocols, maybe don't need to use this
approach. This is used for detecting DDOS attacks on TCP or UDP traffic.
Jeffrey Haas: What Maria mentioned is generic operational consideration
for BGP Flowspec. It does cause some outages, while it is also a
powerful tool helping operators in network deployment and operation. You
are encouraged to pick this up for Flowspec v2 as operational and
security considerations and contribute to documents. And to address
Robert's comments to the chat, need to discuss the scaling
considerations for this feature, given FlowSpec's deployment on both
security appliances and edge internet routers.
Jonathan Senecal: Suggested that the document define or suggest the ways
to implement this, as some ASIC hardware might not support such complex
filters, potentially leading to traffic flooding to routing engines
instead of being filtered in hardware.
Yujia Gao: Will consider it, and can continue the discussion on the
list.
(from chat)
Robert Raszuk: This functionality is available since day 1 of RFC5575 -
you redirect to VRF and in the VRF you can have predefined action to
capture packet, header whatever you imagine
Jeffrey Haas: The protocol request here is to do a packet match based on
payload. The request here is not to redirect the traffic to something
that does that matching.
Jeffrey Haas: note for minutes, request from author for adoption of
payload filter for fsv2.
Robert Raszuk: @jeff ... Cool packet match based on payload ... at what
rate ? You want to look at each packet payload at 800 Gbps ???
Susan Hares: @robert - good point that scaling should be included.
Jeffrey Haas: There are multiple vendor features that cover such filters
already. However no standardized flowspec mechanism for them.
Robert Raszuk： @Jeff - Thank You for voicing my comment. The main issue
is that once even one such rule is installed to match on payload the
game is over for those forwarding engines it is enabled on。
Jeffrey Haas：There is a conversation on "where can you apply fs(v2)
filters" that has happened over fsv2 discussions, especially covering
inconsistently deployed new features. This scaling discussion is a good
input toward the deployment considerations.
draft-cui-idr-flowspec-feedback-binding-00
[Yujia Gao]
Jeffrey Haas: The proposal is a good idea aligning with ongoing FlowSpec
V2 discussions, on how to do feedback loop for installation of FS rules.
Look forward to discussion and further presentations on this. Cannot use
large BGP communities for this, as there is no standardized code points.
Suggest to use community container as the preferred mechanism for
encoding such information in FlowSpec V2.
(from chat)
Jeffrey Haas: This draft covering "is this installed" is one such
example of the deployment discussion.
John Scudder: I don't love using BMP as a feedback channel, it seems
like mission creep.
Jeffrey Haas: we need some back channel. BMP isn't lovely, but it's not
the worst example.
Jeffrey Haas: it has some niceness that streaming yang telemetry doesn't
have.
Reshad Rahman: On the fence on using BMP for this, it's a great tool but
I see John's point.
Jeffrey Haas: There is room to have BMP as the channel, even if it's not
in the same stream as other bmp applications. That's been part of the
motivation for the filtered feeds discussion in grow.
Jeffrey Haas: That said, BMP has become our BGP "does this go into BGP
or DNS" joke.
Maria Matějka: i'm very much scared about the feedback across AS
boundaries, i'm almost leaning to mandating to not propagate across AS
boundaries unless explicitly allowed by operators
Jeffrey Haas: That is already the current operational practice, Maria.
Reshad Rahman: Or "the answer is BMP! What was your question?"
John Scudder: At the very least if we're looking at using BMP for more
than its current purpose, we need to liaise that with GROW sooner rather
than later. But I still think it's a mistake. It would potentially have
knock-on effects for the ability of the BMP spec to be iterated quickly.
Which IMO is one of the strengths of BMP.
Jeffrey Haas: inter-as flowspec is deployed, but under controlled
circumstances. It's also where some of more terrifying outages
originate.
Yujia Gao: BMP is just a example; we'll have more options to do that. We
welcome all comments and need more feedback :)
Maria Matějka: well the section 6 says quite explicitly that the
feedback action must be propagated unchanged across AS boundaries …
Boris Khasanov: @Yujia - would be good to know other options too
Jeffrey Haas: @john I don't speak for the authors on that fsv2 draft,
but prior discussion is that such "telemetry" becomes either a statistic
type (already defined) or route monitoring message.
Jeffrey Haas: but i think we're at the point where concrete proposals
are needed for specific hate mail rather than general idea hate.
Jeffrey Haas: note this also overlaps the "router capabilities"
discussion kicked off by Tony Li a while back.
John Scudder: Sure, if it can be cleanly fit into the existing model I'm
less worried. And point taken.
Jeffrey Haas: @boris YANG streaming telemetry is a similar idea. That
one is mostly just a matter of defining the schema.
Robert Raszuk: For feedback I recommend to think about Operational
Message proposal ...
https://www.ietf.org/archive/id/draft-ietf-idr-operational-message-00.txt
Jeffrey Haas: The challenge for op message, @robert, is that this status
is likely needed by a controller that is not directly connected.
Robert Raszuk: Well if we are considering BMP I presume there could be a
session to such controller too
Jeffrey Haas: That's more the typical deployment model already for bmp
or streaming telemetry, hence the likely fit for purpose discussion.
Boris Khasanov: @Jeffrey Agree, Yang-telemetry with proper scheme could
work. @Robert - thanks for pointing this Op Message info.
Maria Matějka: what if we allowed propagating the op messages
transitively
Maria Matějka: of course we have to create a subtree with something like
rtfilters or so
Jeffrey Haas: @maria consider current vpn-orf discussion. I think you'll
find the propagation discussion is somewhat similar.
Maria Matějka: gonna check, thanks!
draft-sa-idr-bgp-srv6-mpls-transport-iw-00
[Swadesh Agrawal]
Keyur Patel: Suggest to add explicit error handling procedures to the
draft for cases where a receiving router does not support the new TLV.
Swadesh: Yes I will update the error handling procedures.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 60 minutes