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

Pls see inline.. KV>

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

HI

Two more questions ...

8. I am not clear what are trying to describe in Section 8.

   Like any other optional transitive BGP attribute, it is possible that

   this attribute gets propagated thru speakers that don't understand

   this attribute and an error detected by a speaker multiple hops away.

   This is mitigated by requiring the receiving speaker to remove this

   attribute when doing nexthop-self.

First indeed, the attribute may be propagated by BGP speakers which do not understand it, but that in itself is not an error. In those cases partial bit is set but attribute is still valid.

KV> I agree, the attribute should be made ‘optional non-transitive’. Å receiving old-speaker cannot remove the attribute since he doesn’t understand it. I should correct this.

This is also completely orthogonal to setting the next hop self on the path when propagating for example across EBGP.

KV> a new-speaker that receives the MNH on a route should not propagate it as-is (received MNH must be stripped), if it readvertises with nexthop-self (new MNH can be added as required).  When the nexthop is left unchanged, the MNH should be propagated as-is.

9. You are providing a lot of analogy to Add-Paths. But in Add-Paths thx to capability negotiation it is mandatory for receiving speaker indicating support to act on it. Here you have chosen for some reason blind propagation as optional transitive which perhaps may be ok for networks which do end to end encapsulation, but I don't think it is going to work in pure IPv4/IPv6 hop by hop lookup - especially in the cases of mixed network elements some supporting the attribute and some not.

KV> I had chosen ‘optional transitive’ to be able to pass thru RRs that don’t support it. But we also need to scope it within an AS and not allow it to pass ebgp boundary. And I agree with you the only way to do it for old-speakers is to make it ‘optional non-transitive’. I will correct that.

KV> And yes, the proposal is intended for BGP-free cores that use tunneling. Use in hop-by-hop forwarding network scenario is out of scope of this document. Thanks.

Thx,
R.

On Fri, Jun 11, 2021 at 12:09 PM Robert Raszuk <robert@raszuk.net<mailto:robert@raszuk.net>> wrote:
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.

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 ?

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

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.

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.

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. 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.

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 and as being optional and transitive will be distributed to all routers all over the world.

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 ...

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!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLNQPUQl6$>

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!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLNUvhMBP$>

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!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLAMdHEi7$>

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!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLKxw4CKE$>

_______________________________________________
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!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLO4SnRRL$>
Internet-Draft directories: http://www.ietf.org/shadow.html<https://urldefense.com/v3/__http:/www.ietf.org/shadow.html__;!!NEt6yMaO-gk!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLGkuKZBP$>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt<https://urldefense.com/v3/__ftp:/ftp.ietf.org/ietf/1shadow-sites.txt__;!!NEt6yMaO-gk!V8NWgdDpCqZ3PhBo-vsbtyELsTm7DPfL_b0JOVvJlQSSVkgJ8InqCJdXLOheoCZF$>

Juniper Business Use Only