Thursday, 7 November 2024, Session III, 15:30 - 17:00 PT
1.1 Administrivia, Agenda Bashing (Chairs, 5 min) [5/90]
1.2 WG Document Status (Chairs, 5 min) [10/90]
BGP-SPF base document has been sent to IESG for publication.
The WG LC for LSVR applicability has ended this week, if there is no
further comment, will send it to IESG soon.
BGP-LS YANG model has expired, the authors shared status on mail list.
Some remaining challenges need to be handled. Welcome to review, comment
and join this work.
L3DL is waiting for WG recharter, then will start WG LC.
2.0 LSVR Applicability (Jie/Acee/Keyur, 15 min) [25/90]
No further comment on this document.
3.0 Proposed Update to BGP Link-State SPF NLRI Selection Rules (Jie
Dong, 10 min) [35/90]
Acee: What does is it avoids? Extra path computation? What does this new
rule save?
Jie: It saved duplicate advertisement, not computation.
Acee: How do you know the other guy has that one for sure? Because you
have advertised the previous one?
Jie: The NLRI with same sequence num has been selected and advertised,
then it receives the others with the same NLRI and sequence num but some
attributes being different, e.g. router ID, but not necessary for SPF
computation.
Acee: Ok.
Ketan: If there is some difference in the attribute, I would expect that
the sequence number is updated by the originator?
Jie: The difference is caused by the propagation, e.g. AS Path.
Ketan: So you are saying the BGP-LS attribute is unchanged, which is
where the sequence number is, but some other attributes has changed.
Jie: Yes.
Jeff Haas: I'm treating this one as in terms of existing procedure in
RFC 5004. It has procedures for basically keep the oldest route,
basically the most stable route instead. .... If you're willing to look
at RFC5004 and use the oldest drought thing, I think most of this falls
out as a proper behavior.
Ketan: As a WG member, I think sequence number will not bump up during
propagation, I don't think there will be a loop, but there may be
probably unnecessary flooding.
Jeff: My vague concern is when the originator want to regenerate the
route for some strange reason.
Ketan: The last third point is there because only the best one that is
flooded or propagated further, and this allows some sort of a
deterministic thing, without that thing, the BGP-LS attribute is the
same, but the rest of BGP attributes may be different. It does not
affect the functionality but what you would expect normally in case of
bgp you may not see it.
Keyur：In any case as Ketan said earlier that the functionality is not
going to be impacted, but minimally you could always have suggest
implementations law some kind of message to analyze and say I have seen
this kind of behavior which I probably should not be seeing because any
time you change any IGP characteristics the sequence number has to get
bumped up.
Jie: In this case, the router will receive an NLRI with the same
sequence number as it have installed and advertised. So we add this rule
to avoid additional advertisement. Some other attributes may not be the
same, while there should be no impact to the BGP-LS SPF computation.
Keyur: The sequence number is used to detect loop and drop packets, I
don’t think we have put in a clause in there that says don’t advertise.
As long as updates are different, attributes are different, we will
advertise. But Acee and I can go to look at the text.
Ketan: BGP-SPF base document is with our AD, so in case there are any
changes required, let’s do that soonish.
Jie: I suggest to make this document as an optional optimization to
bgp-ls-spf selection rules, it could be useful for some scenarios.
Keyur: One more quick comment, redundant advertisement of updates has
never been a problem for BGP. There were papers working on this. It
could be a good optimization to have and could be at implementation
level.
4.0 Applying BGP-LS Segment Routing Extensions to BGP-LS SPF (Li
Zhang, 10 min) [45/90]
Keyur: BGP-SPF has not defined extensions for MPLS. To chairs, is label
extensions considered in LSVR? SRv6 may be a little bit different.
Ketan: Good point, not 100% sure this fits in the current charter. It is
about adding MPLS and SRv6 capability into BGP-SPF.
Keyur: SRv6 should probably fit in as is, it is IPv6. MPLS is something
bigger to discuss.
Jie: (as WG member) According to Keyur's comments, it seems the SR-MPLS
and SRv6 applicablity in this draft should be splitted? Seems SRv6 is
more straightforward, for SR-MPLS, need to first consider whether to
introduce MPLS to BGP-SPF.
Ketan: (as WG member) The range TLV was for SRMS, the source router
identifier TLV was for OSPF, they may not be applicable to BGP-SPF.
Li: Maybe they can also be useful in BGP-SPF for the collection of such
information to the controller? We can discuss their applicability on the
mailing list.
Acee: We need to worry about mapping server. It was a hack in IGPs. We
could still do mapping, but for BGP-SPF we may do it differently, such
as with individual prefixes. IMO that TLV should not be put into BGP-LS
SPF.
Jeff Haas: Is this intended to go for informational status?
Jie: (as WG member) There is no new TLVs, while it extends the
functionality of BGP-LS SPF, so perhaps standard track makes more sense?
Jeff: If there is normative changes to the behavior, it should be
standard track.
Ketan: For SRv6, the peernode SID TLV was for BGP EPE case, for
link-state there is End.X SID, do we need to use it in BGP-SPF?
Li: Will check offline and give feedback.
Ketan: Suggest to introduce and discuss this on the mailing list, and
also let SPRING know this is happening in LSVR.
Jim: This document is currently not in charter. Should this be added to
the recharter discussion?
Ketan: We can check with the WG about whether to include it in the
recharter.
Keyur: Having an SR extension to LSVR is good, it allows source based
routing and per-packet spraying in the Clos networks. Suggest to
consider it in the charter.
5.0 Any other topics ... (Open Mic, 15 mins)