================================
9:30 - 11:30 (UTC+2) Monday session I
Room: Hidalgo
Notetaking: David Lamparter, Jie Dong
(10 mins) [Chairs]
09:43 (10 mins) draft-li-idr-flowspec-sr-policy-01 [Zhenqiang Li]
No questions/feedback.
[following comments made after next draft]
Yujia Gao: Is there any experimenthal verification of the SR Policy
action, about the effectiveness of this action? Is it for both FSv1
and FSv2, or just FSv2?
Zhenqiang Li: It is only for FSv2.
Yujia Gao: Thank you. We are also working on another FSv2 feature:
payload filter. Hope IDR WG can move FSv2 work forward with high
priority.
09:50 (10 mins) draft-li-idr-sr-policy-metric-01 [Zhenqiang Li]
Dhruv Dhody/Jeff Haas/Keyur Patel relayed from chat: The proposed
format for Metric Sub-TLV is not the best; work on common encoding
exists in other documents, should incorporate/reference. There's
also another draft on SR Policy with metric
(draft-ietf-idr-sr-policy-metric). Also, changing BGP route
selection is very problematic and we'll have careful discussion
about it.
Joel Halpern relayed from chat: This seems to assume that a path
with a better metric is always to be preferred. As I understand it,
the normal goal is to pick paths whose performance is "good enough".
Also, it is unclear if "delay" includes queueing delay (in which
case we have the congestion-chasing problem).
John Scudder: confused about the metric thing; isn't the metric
different from different points in the network? From whose
perspective is that metric being advertised? (John's follow up on
the mailing list: having reread the draft, my question was based on
a misunderstanding. I withdraw it, sorry for the noise. )
10:04 (5 mins) draft-lin-idr-bgpls-te-policy-pm-06 [Changwang Lin]
Zafar Ali: draft-ietf-idr-bgp-ls-sr-policy exists for SR segment
list metrics sub-TLVs, would be good to contrast / see what is
missing there. Also since SR Policy is unidirectional, not sure what
the link delay and bidirectional metrics mean here?
Changwang Lin: Bidirectional performance metrics can help the
controller in path optimization. When PTP/NTP are not enabled on
devices, the measured performance are bidirectional.
10:12 (10 mins) draft-zzd-idr-sr-policy-scheduling-09 [Li Zhang]
Zafar Ali: has this been discussed with the TVR working group? Have
they asked for this?
Li Zhang: No, not yet.
Zafar Ali: Do we feel that extending BGP is the right thing, or we
just use the YANG model defined in TVR?
Li Zhang: TVR only defines the data model. The usage of TVR YANG is
described in the TVR applicability draft. There's some relationship
with TVR's current work.
Ketan Talaulikar: as AD, there's an similar draft in PCEP and an
existing RFC in PCEP, and this might be going into multiple
protocls; work should be done to ensure consistency in encoding.
Jeff Haas: TVR doesn't own time formats across all IETF (yet),
normalizing them is certainly a good idea.
Joel Halpern from chat: Is the data model here aligned with the work
from TVR?
Dhruv Dhody from chat: There is also RFC 8934 in PCE WG, that is
worth looking at -
https://datatracker.ietf.org/doc/html/rfc8934#section-5.2.1
David Lamparter from chat: AFAIK, POSIX doesn't specify any width
for time_t, A4 is not technically correct, it might be 64bit by
implementation choice :)
Jie Dong from chat: This is to provide the BGP SR Policy mechanism
similar to what PCE already have.
10:24 (5 mins) draft-ali-idr-srv6-policy-sl-opt-distribution-01 [Zafar
Ali]
10:29 (10 mins) draft-wang-idr-bgp-nof-nlri-03 [Rui zhuang]
Jeffrey Haas from chat: Do we have any bess chairs monitoring this
presentation for nvme over rocev2? The question will be whether this
work is better suited for bess.
Keyur Patel from chat: or LSVR as its DC specific.
Jeff Tantsura: Why do we need reachability on the network layer
here? There is enough machinery in RDMA, why do we need this
information at layer-3?
Rui Zhuang: hadn't considered that yet, can discuss it by email.
Stephane Litkowski/BESS chair: If there is interest to work on this,
this is probably more suitable for the BESS working group.
Ketan Talaulikar from chat: For starters, we need to understand the
use-case or requirements for NVMe or RoCE perspectives. Then we can
work out the BGP parts.
Ketan Talaulikar from chat: IOW for the authors of
draft-wang-idr-bgp-nof-nlri, is there a draft that captures the
motivation or analysis for doing this with BGP vs however this is
done already today?
10:38 (10 mins) draft-xu-idr-fare-03 [Xiaohu Xu]
Stephane Litkowski: we should not introduce a new BGP extended
community to do this; some assumptions on other work may have been
true but aren't anymore, we have all the tools now with the existing
attributes. There are implementations based on existing attributes.
Concern what will happen if we have multiple ways to encode the same
thing. We have a community container for bandwidth, What's encoded
is really up to local behavior, cf. accumulation in the bess-DMZ
draft. It is fine to define it as a new use case, but not a new
standard.
Tobias Fiebig: +1 to previous comment, also very IPv4 centric,
really need to consider IPv6.
Zhaohui Zhang: The attribute may change quickly & generate a lot of
updates; have been considering another UDP based protocol to carry
this information.
Yao Liu: Regardng the switch chips, is this a software function or
related to chip design question? Can all switches do this?
Xiaohu Xu: We are doing per-packet ECMP, needs some support from
chips for certain types of RDMA traffic.
Yao Liu: Usage for AI inference has different packet type/size
characteristics, is this applicable?
Xiaohu Xu: It can apply to both training and inference traffic.
krishnaswamy ananthamurthy from chat: There is already a similar
work being adopted in BESS - "Cumulative DMZ Link Bandwidth and
load-balancing"
Jeffrey Haas from chat: There is strong overlap with some of the
plumbing for the bess dmz case, but this was, iirc, about
discovering the floor of the bw. Also that the semantics are
slightly different and maybe shouldn't overload the same attribute.
Ketan Talaulikar from chat: I see that there are implementations
from multiple vendors and deployments being claimed. At the same
time, there is no code point allocated. This worries me that we
don't have a codepoint squatting situation here for the attribute.
10:53 (10 mins) draft-xu-idr-neighbor-autodiscovery-12 [Xiaohu Xu]
10:56 (5 mins) draft-ietf-idr-bgp-generic-metric-01 [Srihari Sangli]
Xiaohu Xu: have read the draft and compare it with my draft
(performance aware routing), major difference is this one wants to
simplify the BGP CAR/CT by using a existing attribute for specific
metric type based path selection. not sure if it can support generic
metric based route selection and original route selection
simultaneously.
Srihari: This is not just for CT/CAR address family, it can be
attached to any address family.
Xiaohu Xu: My use case is want to support both original route
selection and performance metric based route selection for different
customers/traffic types.
Srihari: Still think that can be achieved by attaching generic
metric to the routes you need performance based selection.
11:01 (5 mins) draft-lin-idr-refresh-enhance-00 [Changwang Lin]
technical/audio issues for presenter during presentation
Krishnaswamy Ananthamurthy: there is a draft for route refresh
options (draft-idr-bgp-route-refresh-options-03), is there anything
here that draft isn't handling?
Changwang Lin: Didn't notice the existing draft. Think the mechanism
is similar. Why the old draft didn't move forward?
Krishnaswamy Ananthamurthy: Has refreshed the draft and will move it
forward.
Jeff Haas: There is substantial overlap between the two drafts.
People were concerned (on not adopting the previous work) about the
churn that refresh mechanisms could cause on BGP. Can reopen the
discussion.
11:10 (10 mins) draft-ietf-idr-performance-routing-04 [Xiaohu Xu]
Jeff Tantsura: think it's fundamentally a bad idea, sorry; highly
volatile metrics don't belong in protocols in general. Don't want
really dynamic things to trigger best path selection. Two things
contribute to latency: fiber lentgh and queue occupancy. Could be as
bad as triggering events every time the buffer utilization on some
device changes. And you may need to do it per traffic class.
Jeff Haas: previous discussions during adoption call have all
insisted on some sort of hysteresis or dampening for this kind of
work
Xiaohu Xu: Believe centralized controller is not needed for this,
Flex-Algo can be used for path computation.
Joel Halpern from chat: It would be helpful if folks discussing
latency were clear as to whether they are interested in link latency
or link+queue latency.
Jeff Tantsura: The IANA section needs to be added.
Jeff Tantsura: For the FARE drafts, need more technical details to
properly evaluate and discuss them. Think about the attributes you
are using.
Ketan Talaulikar: Regarding IANA thing in the load balancing draft:
there are implementations/deployments but no codepoint allocations?
Should ask for it.
Xiaohu Xu: We are using experimental code points for now. There is
no interopeartion issue.
Jeff Haas: Things always leak, don't ship codes that have code
points not allocated by IANA.
Jeff Haas: Suggest to have discussion about the recharter on mailing
list.
11:23 no further questions/feedback; session ends.
11:30 - 13:00 (UTC+2) Friday Session II
Room: Castilla
[Chairs]
[John Scudder]
Jeff Haas: This work will be editor-driven. Nobody's name besides
the editors will go at the top of the draft. And this work will
likely be heavily done on github.
Luuk Hendriks: This work is very helpful. 4-byte ASN should be a
must. About upgrading SHOULDs to MUSTs, it makes sense, what about
introducing new SHOULDs? One example, should we advise to put IPv4
unicast prefixes into MP_REACH instead of the end of the PDU?
John Scudder: Using all capital keywords can cause a lot of debate.
It would be easier by using lowercase words. But I get your point we
should introduce advice for people to produce best implementation if
they were starting today.
Maria Matějka: Please include the 4-byte ASN. Please take out
AS_SET. Should be able to put v4 prefixes in MP_REACH. And it
would be fine if the MP_REACH are always at the end of the
attributes set.
John Scudder: The MP_REACH should be at the beginning actually, and
we should make that a MUST. It should be at the known position.
Maria Matějka: MRAI needs to be reviewed, no implemented for 20
years. And best route selection taking MED into consideration, there
is no implemenation doing it right by default. Last thing, are we
going to run into a brick wall by not having a YANG model?
Ketan Talaulikar: In the proposed charter, it allows the YANG model
to go through without two implementation requirement. Hopefully the
YANG model has become RFC before this work is done.
Rüdiger Volk: Very happy with the presentation. It covers most
things came to my mind. One thing I wonder is what is the expect
time frame for this work to be completed?
John Scudder: Have no expectation to have WGLC by next meeting, but
think we may approach it by a year from now.
Jeff Haas: Will have concerted mailing list discussion after this
IETF.
Sriram Kotikalapudi: About RFC 9234, BGP Role and OTC. Wonder will
BGP role part go into 4271bis, while The OTC part stay in RFC 9234?
John Scudder: This is a good example. Confederation was invented
between 1771 and 4271, then 4271 provides pointers to the relevant
specifications. We may do something like that.
Yingzhen Qu: Support this work. FSM has been updated by a few RFCs,
may talk about whether we should include those in the bis/STD.
John Scudder: Patching FSM is more difficult than patching other
pieces.
Alvaro Retana: Happy to help with the work. Surprised not seeing
Route Reflector, communities, extended messaging. We are not to
invent anything, but we have to change some things. Would like to
see a plan rather than a timeline.
John Scudder: For RR, it is an important element. RR was nicely
architected and doesn't change the base spec， allows it to stand
alone but move into the STD.
Alvaro Retana: No problem working on github, while suggest not to
exclude people who are not in github. Can follow the approach of
quic, also use mailing list to track the issues.
Jeff Haas: We will look for people to be assistant maintainers on
the reporsitory, to help people who cannot submit patches by
themselves.
Tony Li: Heard people say "let's make this change". We want to avoid
that. If you want to make a change, let's do it seperately in
independent documents.
Jie Dong: Fully support this work. For RFC 6608, it may be an
example of a series of RFCs which introduced new error
codes/subcodes for BGP session maintenace and troubleshooting.
Suggest to make them part of the bis/STD.
John Scudder: Are you talking about published RFCs on error
codes/subcodes and we should roll that into our base specs to have a
complete table? Or are you saying we can do better with error codes
and introduce new ones?
Jie Dong: Not new ones, just review the existing ones.
Ketan Talaulikar: Do you need a project manager for this?
John Scudder: Let's take that offline.
Jeff Haas: Let's continue the discussion on the mailing list.
draft-haas-idr-path-attribute-filtering-00
[Jeff Haas]
Bruno Decraene: Does it allow the peer to either filter the
attribute or the route?
Jeff Haas: Currently it allows to no block the route, and discard is
also a possible implementation detail, block is the expected
behavior rather than escape.
Bruno Decraene: I think it is not clearly reflected in the abstract.
Jeff Haas: We can clarify it in the abstract.
Bruno Decraene: Think the two semantics are very different, prefer
to have single semantic. For me, filtering is much more aggresive.
Nan Geng: Consider a case both sides have been upgraded to support
the feature, and one side wants to send and receive path attribute
one, and the other side doesn't want to send and receive this path
attribute, so the negotiation would fail. How do we handle this
case? Just stop the negotiation or we can just negotiate part of the
attributes?
Jeff Haas: There are two points. One is assuming that we have the
mechanism to update the filter. Then the changes from -00 to -01 is
that we're unilaterally declaring what each side wants to filter,
there's no longer a negotiated version, it is now unidirection. You
can make unidirectional choices.
David Lampater: On the site that receives the filter and then
sending updates, it is too open in what it should do. But I'm not
sure I want to put lots of requirement on it. Think this feature is
more useful as a debugging aid. When there is implementation issues
which generate attributes they shouldn't, cannot rely on the buggy
implementation to apply this filter correctly.
Jeff Haas: The advertising site is promising to filter this. It is
asking the sender to take part in this, much like an ORF much like
RT constraint, just simply because there is benefit if a sender
doesn't waste its bandwidth sending things that know will be thrown
away.
David Lampater: I think it's currently a must on the sender, I would
rather have that a should and allow the sender to still send the
attribute, especially if we do some kind of batching or grouping in
outgoing updates.
Jeff Haas: OK, I understand the implementation motivation let us
continue on the list.
Alvaro Retana: As coauthor of the OAD draft, think these are
complementary. OAD is a type of external peering, if this is
external peering, then they can complement to each other. Consider
the case where in the capability I say no, but at the same time I
negotiated the SAFI. What should take precedence?
Jeff Haas: In that case things can break very rudely. Can add
clarification to the draft. It is open to discussion.
Alvaro Retana: Would prefer the other way around.
Maria Matějka: Can we drop aggregator from the list? And would like
to see everything default on.
John Scudder: What do you mean by default on? Do you mean by default
everything will be blocked or permitted?
Maria Matějka: By default permit.
Acee Lindem: You have bits for mandatory attributes, how do you
filter mandatory and remain backward compatible?
Jeff Haas: This part needs further clarification. It is to make it
easier for decoding, but some of these should never be used for
filtering.
Tony Li: A small point: aggregation does not depend on AS_SET. you
can aggregate routes with identical attributes without AS_SET.
Jeff Haas: Looking forward to more feedbacks on the list.
John Scudder from chat: By the way here is some related work (that
has not gained traction).
https://datatracker.ietf.org/doc/draft-keyupate-idr-bgp-attribute-announcement/
draft-ietf-idr-dynamic-cap-17
[Srihari Sangli]
Krishnaswamy Ananthamurthy: Thanks for adding clarifications to the
draft. One point is can we leave the ACK mandatory only for the
dynamic capability itself, rather than requiring ACK for enforcing
every capability? Or let's even not making it mandatory.
Jeff Haas: Suggest to work through some examples of the state
machine in the mailing list.
Srihari Sangli: We have examples both in the draft and in this
presentation. We can look at it and discuss in the list.
Jeff Haas: No time for further discussion on the meeting.
draft-mohanty-idr-secondary-label-01
[Mankamana Mishra]
draft-he-idr-bgp-flowspec-ifit-00
[Xiaoming He]
draft-krierhorn-idr-upa-00
[Jakub Horn]
John Scudder: Don't like UPA in IGP either. Routing always struggle
between aggregation for better scalability and deaggregation for
timeliness. As for the solution, think option 2 is better and no
danger.
Jakub Horn: It may be propagated further by a speakder which doesn't
understand UPA.
John Scudder: It should be an unresolvable MP_REACH.
Jakub Horn: If it is sent via RR, it will be propagated everywhere.
Jeff Haas: About Option 3, MP_UNREACH is a way to delete states, it
is problematic to turn it into a mechanism of injecting states.
Suggest to look at something besides this option.
Speaker Shuffling Time/Buffer: 5 minutes
Total Time: 85 minutes