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

[Keyur Patel <[e-mail]>]

Hi Haibo,

Many thanks for the detail review. Apologies for the delayed response. Our comments are attached #Keyur.

On 6/17/21, 1:38 AM, "Wanghaibo (Rainsword)" <[e-mail]> wrote:

    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.

#Keyur: While some of the attributes you listed above are not part of the bestpath selection, they are still used for loop detection and other functions of the protocol (including support of allow-same-as). 


    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.

#Keyur: That usually makes sense with GR enabled and it would be no different with bgp-spf (with GR enabled). Can you please elaborate more if you think otherwise?


    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.

#Keyur:  Good suggestion. We can definitely add text to cover this scenario for any non-ecmp case.


    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.

#Keyur: We will add text to clarify the use of unnumbered links.


    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.

#Keyur: Apologies. We don’t get the use case well. Can you please explain again.

Regards,
Keyur

    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