Re: [Lsvr] WGLC extended for 2 more week [RE: WGLC for draft-ietf-lsvr-bgp-spf-13 (to end June 3, 2021)]

["Wanghaibo (Rainsword)" <[e-mail]>]

Hi authors,

         I have some comments about the draft.


1.       Section: 2 Base BGP Protocol Relationship
" Due to the changes to the decision process, there are mechanisms and
   encodings that are no longer applicable.  While not necessarily
   required for computation, the ORIGIN, AS_PATH, MULTI_EXIT_DISC,
   LOCAL_PREF, and NEXT_HOP path attributes are mandatory and will be
   validated."
These attributes are not use for path calculation but for routes advertisement.
For Fat Tree topology, most solution use same ASes for the spines in one POD,
So the spines cann't learn each other's BGP-SPF NLRI. It will cause the topology in spine is not same as in leaf.
I think it's not a problem ,  but a special feature for BGP-SPF. Traditional IGP protocol cannot do that.


2.       Section: 4.1.  BGP Single-Hop Peering on Network Node Connections

"  The simplest peering model is the one where EBGP single-hop sessions

   are established over direct point-to-point links interconnecting the

   nodes in the BGP SPF routing domain.  Once the single-hop BGP session

   has been established and the BGP-LS-SPF AFI/SAFI capability has been

   exchanged [RFC4760<https://datatracker.ietf.org/doc/html/rfc4760>] for the corresponding session, then the link is

   considered up from a BGP SPF perspective and the corresponding BGP-

   LS-SPF Link NLRI is advertised.  If the session goes down, the

   corresponding Link NLRI will be withdrawn.  Topologically, this would

   be equivalent to the peering model in [RFC7938<https://datatracker.ietf.org/doc/html/rfc7938>] where there is a BGP

   session on every link in the data center switch fabric.  The content

   of the Link NLRI is described in Section 5.2.2<https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-13#section-5.2.2>. "

In this model, the links is consider to corresponding to the session. So when the session goes down, the corresponding Link NLRI will be withdrawn.
              But for section : 6.5.1.  Link/Prefix Failure Convergence

     "    In order to avoid this delay, the originator of the Link NLRI SHOULD

advertise a more recent version with an increased Sequence Number TLV

for the BGP-LS-SPF Link NLRI including the SPF Status TLV (Section 5.2.2.2<https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-bgp-spf-13#section-5.2.2.2>)

indicating the link is down with respect to BGP SPF. "
             It seems conflict with the above one. Because in the signle-hop peering mode, the link down will cause the session down.
             Perhaps we may not use the ebgp-interface sensitive here or we may hold the session's corresponding Link NLRI for a few timer even the session is down.


3.       Section: 6.1 BGP NLRI Selection
BGP-SPF defined a simply selection rules instead of regular BGP.
But there is a scenario, if there two links between a couple of router, not use trunk, such as A === B
When we create two neighbors, A advertise its BGP-SPF NLRI to B, the B couldn't choose the best one according to the current rules.
So I think perhaps we may add a new rule, prefer the route with large neighbor IP as the last rule.


4.       Section: 6.3.  SPF Calculation based on BGP-LS-SPF NLRI

The SPF calculation describe the bi-directional connectivity check:

                    "    All the Link NLRI corresponding the Remote-Node will be
           searched for a Link NLRI pointing to the Current-Node.
           Each Link NLRI is examined for Remote Node Descriptors
           matching the Current-Node and Link Descriptors matching
           the Current-Link (e.g., sharing a common IPv4 or IPv6
           subnet). If both these conditions are satisfied for one
           of the Remote-Node's links, the bi-directional
           connectivity check succeeds and the Remote-Node may be
           processed further. "

But it doesn't describe how to do the check with the unnumbered link.


5.       Section : 6.5.1.  Link/Prefix Failure Convergence
The describe here is OK , but it may be still exist some problem during the convergence.
[cid:image003.jpg@01D76397.1DC01CA0]
Suppose a topology above. Router id is A > C > B > D.
For E's SPF NLRI info:
A: one learns from C
B: one learns from D, one learns from A(A select C's as the best route and advertise to B)
     B will choose A's route as the best( A router-id > D)
C: one learns from D
D: one learns from E, one learns from B(B select A's as the best route and advertise to D)
     D will choose E's route as the best(The route is originated by E)
F: one lears from C

When C-D link is down for a long time. C will withdraw all the BGP-SPF NLRI's learn from D(include E's SPF NLRI). Now E will have no E's SPF NLRI.
A & F will withdrawn E's SPF NLRI after receive C's withdrawn. Now the A & F will have no E's SPF NLRI.
Later A will send E's SPF NLRI withdraw to B.
B then withdraw E's SPF NLRI from A before and choose the one learns from D as the new best one, and resend it to A.
Then A learns E's SPF NLRI from B and send to C, C send to F. Then A\C\F will relearn the E's SPF, and can calculate the E's path.
This is the period that A\C\F will lose E's SPF NLRI. In fact, there may be more routers behind E, all the NLRI behind E will be lost during that period.

Regards,
Haibo

From: Lsvr [mailto:[e-mail]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Monday, June 7, 2021 9:21 PM
To: [e-mail]
Cc: [e-mail]
Subject: [Lsvr] WGLC extended for 2 more week [RE: WGLC for draft-ietf-lsvr-bgp-spf-13 (to end June 3, 2021)]

There was no feedback received.

We'll extend the WGLC for 2 more weeks and will now be finished on 17 June 2021.

G/

From: Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Thursday, May 20, 2021 4:09 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: WGLC for draft-ietf-lsvr-bgp-spf-13 (to end June 3, 2021)


Hi All,





The author team together with AD have been working hard on this document and made significant enhancements to this document.





The LSVR WG starts a working group last call for "draft-ietf-lsvr-bgp-spf-13". Please send your comments to the LSVR list before Thursday June 3, 2021.



https://datatracker.ietf.org/doc/draft-ietf-lsvr-bgp-spf/





This WGLC is cross-posted to IDR and LSR WG. All feedback and discussions should happen on the LSVR WG mailer.





Authors, please reply indicating if you're aware of any relevant IPR.



All, Please advice if you are aware of an implementation or are aware of relevant IPR.





Brgds,

Gunter & Victor

LSVR WG co-chairs