Re: [Idr] I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt

Hi Robert,

Thank you for the questions and comments. Apologies - I somehow missed these emails with your questions, hence the delay in response.

Please see my response inline.. KV>

From: Robert Raszuk <robert@raszuk.net>
Date: Friday, June 11, 2021 at 3:10 AM
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>, Minto Jeyananth <minto@juniper.net>
Cc: idr@ietf. org <idr@ietf.org>
Subject: Fwd: I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt
[External Email. Be cautious of content]

Dear authors,

I have read yr draft with interest as some perhaps recall we have discussed this topic in the past number of times.

Cosmetics:

1. First nit - why do you say label must be 3107bis label ? (3.4.2.  Labeled IP nexthop) MPLS label is a label and I am not sure how one method of label distribution matter here.

KV> The intent was to say use the same label-encoding as specified in 3107bis (now rfc8277). But yes, I can just say it is an mpls-label, and specify how it is encoded.

2a. What is PNH ? It first occurs in section 3 as "PNH-Len" or "PNH-address", but it is never explained in the draft. Is this Path Next Hop ?

KV>  “Protocol Next Hop” The nexthop-ip-address received in a BGP-update. I will add it to the terminologies.

2b. Would it be better to call this new attribute MNH MultiNextHop ?

KV> sure, we can abbreviate it as MNH.

Tech:

3. In section 3.1.1 you describe how to assure that NH in MP_REACH is also part of MultiNext Hop Attribute. But I do not see any discussion on how to treat or ignore next hops in MP_REACH when a new attribute is present and is valid.

KV> Sure, I will add some text reg that. Basically, a new-speaker will use the information received in MNH attr to install forwarding state. The PNH received in attr-code 3 or 14 will be used only to validate the MNH, and not for installing forwarding state. If the MNH is not valid then the MNH will be ignored and the PNH received in attr-code 3,14 will be used for forwarding. An old-speaker that does not understand MNH will also use the PNH received in attr-code 3,14.

4. In section 3.1.2 you define behaviour of RR advertising paths from non MultiNexthop paths and those which carry new attributes ... But you should make it clear that this is only about 9.1.2.2 step in best path selection (or candidate selection). There can be other criteria before we even get to that step.

KV>  3.1.2 is actually not about path-selection. It is about add-path candidates selection. Multiple routes with same PNH are not advertised as add-path advertisements. Similarly when the routes contain MHN, we want to compare the MNH to decide whether the route is a candidate to be included in add-path advertisement or not; the decision should not be only based on PNH in attr-code 3, 14

5. Now the most important question - how do you plan to handle atomic withdraws ? I assume the plan is to readvertise the path with MNH - the removed next hop. So by implicit withdraw this next hop will be removed. The draft is silent on this.

KV> that is right. The bgp-update(implicit withdraw) will replace the MNH. I will add text describing it.

Now if the removed next hop was selected by some receivers as best (due to 9.1.2.2) and it was not arriving as part of MP_REACH this proposal require significant implementation changes on how BGP best path selection is triggered, how it runs, how it populates results to the RIB/FIB. I think a new section is needed in detailed discussing the withdraws.

KV> the path-selection selects a best-route. Not a best-nexthop. If the best-route contains MNH, section 3.1.3 specifies how to compute the effective IGP-cost of the route which will be used for best-route path-selection. All resolved(reachable) legs of the MNH will be installed to FIB.

KV> The path-selection will be re-run whenever the effective IGP-cost of a route changes. Any AIGP-attribute will also carry this effective-IGP-cost instead of the igp-cost to the PNH in attr 3,14.

6. How do you envision max-prefix safety knobs to work here ? On the surface it may seem orthogonal - but it is not. Today folks use this to protect infrastructure from for example operator's mistakes. Here one received path may fill the MNH attribute with 100s of next hops

KV> Let us say the max-num-ECMP supported by a router is 16. Then it will install the first 16 nexthops (as per the ‘Relative-preference’ field) received in the MNH. It will not install all the nexthops. So the same existing ecmp-limit safeguards can be used. The only difference is how the nexthops are received. Instead being received in 100 routes, it is received in 1 route.

and as being optional and transitive will be distributed to all routers all over the world.

KV> and I agree, I realize it may be better to make this attribute ‘optional non-transitive’.

7. Observe that metric to next hops is dynamic. So some implementations capable of next hop tracking register with RIB all next hops and each time metric changes they get a call back. Here we are effectively talking about exploding this 10x or 100x or more ...

KV> they could potentially get called-back when effective-igp-cost of the route changes. Pls note, this proposal does not increase number of unique PNHs in the system/network, for e.g. that is a function of how many PEs exist in the network. Just what changes is how those PNHs are conveyed in bgp-updates as ecmp/pic nexthops for a bgp-prefix. Number of routes required to convey that relationship is greatly reduced, while providing more control to the advertiser on signaling the ecmp/pic relationships. Thanks.

Many thx,
Robert

---------- Forwarded message ---------
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Fri, Jun 11, 2021 at 10:56 AM
Subject: I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt
To: <i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>>

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : BGP MultiNexthop attribute
        Authors         : Kaliraj Vairavakkalai
                          Minto Jeyananth
        Filename        : draft-kaliraj-idr-multinexthop-attribute-01.txt
        Pages           : 12
        Date            : 2021-06-11

Abstract:
   Today, a BGP speaker can advertise one nexthop for a set of NLRIs in
   an Update.  This nexthop can be encoded in either the BGP-Nexthop
   attribute (code 3), or inside the MP_REACH attribute (code 14).

   For cases where multiple nexthops need to be advertised, BGP-Addpath
   is used.  Though Addpath allows basic ability to advertise multiple-
   nexthops, it does not allow the sender to specify desired
   relationship between the multiple nexthops being advertised e.g.,
   relative-preference, type of load-balancing.  These are local
   decisions at the receiving speaker based on path-selection between
   the various additional-paths, which may tie-break on some arbitrary
   step like Router-Id.

   Some scenarios with a BGP-free core may benefit from having a
   mechanism, where egress-node can signal multiple-nexthops along with
   their relationship to ingress nodes.  This document defines a new BGP
   attribute "MultiNexthop" that can be used for this purpose.

   This attribute can be used for both labeled and unlabled BGP
   families.  For labeled-families, it is used for a different purpose
   in "downstream allocation" case than "upstream allocation" scenarios.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC7g463XU$>

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-01<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-kaliraj-idr-multinexthop-attribute-01__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC-8LAzIb$>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-kaliraj-idr-multinexthop-attribute-01<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-kaliraj-idr-multinexthop-attribute-01__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC91WiRjG$>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC-RWSEME$>

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/i-d-announce__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC6XAC-1q$>
Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.com/v3/__http:/www.ietf.org/shadow.html__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC35gi1-A$>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.com/v3/__ftp:/ftp.ietf.org/ietf/1shadow-sites.txt__;!!NEt6yMaO-gk!SJ7yfFqQyEkq_YkuCGs7lDpAL_dkijADLgFM7qCDZlGE_sn2mBkcG3EgC8P5Eax-$>

Juniper Business Use Only