Subject: Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

From: Robert Raszuk <[email-masked]>
Date: Fri, 1 Mar 2019 16:50:20 +0100

Hey Rafał,

Just do not set BGP NH to ANH in export policy.

In your Junos cfg example (slide 28) ANH is applied to EBGP peers so I am
not sure how I can send something different to any IBGP peer:

[edit protocols bgp group PeerAS2]
type external;
egress-te {
install-address 1.1.1.2;
rib {
inet.0;
}
}
peer-as 2;
neighbor 11.1.1.1;
neighbor 11.1.1.5;

[RJS] I agree. Memory footprint at RR is not an issue. Convergence at scale
> is.

Convergence is not a problem .. in fact no one should be counting on
protocol *convergence* for fast connectivity restoration at any event of
failure these days.

Let assume at site 1 I have 4 ASBRS connected to AS_2 each with 1 sessions,
> and this ASBR learns 300k prefixes form AS_2 and all of then are best from
> each ASBR POV. So 300k path per ASBR, 300k pfx per ASBR, 1 path per prefix
> per ASBR.
>
> The RR gets 4 x 300k pfx with BGP NH set to ASBR1-2-3-4 loopbacks. And
> send it w/ ADD-PAT to on-site CR
>
> When eBGP session of one of ASBR (say ASBR1) fails, it has to withdraw
> 300k path from RR, and RR need to withdraw 300k path form CR. Untill this
> is done CR will keep sending ¼ oftraffic to ASBR1, and BGP NH == loopback
> is reachable.
>
> Now if ANH is used, CR sees 4 path per prefix with BGP NH == ANH1-2-3-4
> respectively. When eBGP session of one of ASBR (say ASBR1) fails, it
> removes ANH1 form IGP and start to withdraw 300k path from RR, and RR need
> to withdraw 300k path form CR. As soon as CR sees IGP update (ANH1
> unreachable) it can mark all 300k path that have BGP NH == ANH1 unusable.
> And stop forwarding to ASBR1. If CR runs BGP PIC EDGE it could be
> sub-second.
>

All of this works fine today out of the box if you do not set next hop self
on your ASBRs (typical cfg in non MPLS networks :).
And if you do set nhp there as mentioned you can control when it is
redistributed into IGP (or removed from it) by tracking any object (or set
of objects) you define. Very simple.

>  The inter-site operation – advertising only one path w/ BGP NH
> representing “set of eBGP sessions from set of ASBRS” is just one more
> optimization. Let call this SP_ANH (Site-Peer ANH in contrast to above
> discussed ASBR-Peer ANH).
>
>
>    - If RR advertise to other sites only one path and BGP NH is loopback
>    of one of ASBRs (or ASBR-Peer ANH), then what is convergence in case of
>    this ASBR failure?  RR has to send 300k path w/ new BGP NH. Until this is
>    done, remote sites will send traffic somewhere elsw. Not best egress site.
>
> Advertise not one but two paths each coming from different ASBRs.

>
>    -
>    - If RR advertise to other sites only all 4  path and BGP NH is
>    loopback of one of ASBRs (or ASBR-Peer ANH), then IGP update removing this
>    address will allow for quick restoration (as other 3 path are available
>    everywhere). But in multi-path scenario, we just sreated 2-3 level of ECMP
>    structure on remote BGP speakers:
>    prefixà (*list of 4* BGP NH) à each BGP NH à *list of IGP* ECMP
>    neighbours. That costly to manage in S/W and in HW
>
>
If you advertise ANH per ASBR you will still have 4 different next hops so
exactly the case as above.

If you however proposing to advertise all paths from all ASBRs with the
same next hop (in your case AS-WIDE ANH) - brilliant - but how are you
assuring that all EBGP peers send you symmetric routes ? If you get some
EBGP sessions giving you partial BGP reachability for whatever reason - and
you are still using anycast ANH from all 4 ASBRs the packets which IGP
sends towards said ASBRs would be either dropped or looped between ASBRs
till TTL expires as next hop is still ANH so anycast.

>
>    -
>    - If RR advertise to other sites only one path and BGP NH is Site-Peer
>    ANH as in this proposal, then Site-Peer ANH is not removed form IGP (as
>    other ASBRs has session with Peer). Re,mote sites keep sending traffic
>    using pre-failure data until BGP update from RR comes. End when it comes,
>    it will have same BGP NH as pre-failure path. So there will be no need to
>    update FIB. Also FIB structure will be simpler and less costly
>    prefixà one  BGP NH à *list of *IGP ECMP neighbours.
>    Some merchant chips have really limited ECMP capability…
>
> See above.

See when we worked on concept of virtual BGP paths we did a lot of analysis
of this and reached the conclusion that while possible the application of
given abstract or virtual next hop to consistent union of  prefixes
reachable over N EBGP sessions from single or multiple ASBRs must be
automated as you can not assure eBGP symmetry.

So even in your simplest case of ANH per ASBR per PeerAS there is zero
guarantee that you get identical paths from all peers. That means that
since you are going to keep the ANH in IGP till last session goes away you
are going to attract traffic to such ASBRs until BGP withdrawn all affected
non symmetrical paths. Trust me much faster would be not to set nh on ASBR
and just remove peer's address in IGP in one shot. Then BGP can take
however long it takes to "converge" without affecting any data plane.

Many thx,
R.

---

From: Rafal Jan Szarecki <[email-masked]>
Date: Mon, 4 Mar 2019 17:46:19 +0000

Robert,

--
Rafal Szarecki

From: Robert Raszuk <[email-masked]>
Date: Friday, March 1, 2019 at 7:50 AM
To: Rafal Szarecki <[email-masked]>, Natrajan Venkataraman <[email-masked]>
Cc: “[email-masked]” <[email-masked]>
Subject: Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

Hey Rafał,

In your Junos cfg example (slide 28) ANH is applied to EBGP peers so I am not sure how I can send something different to any IBGP peer:

[RJS] above config conditionally install ANH (1.1.1.2) in RIB (inet.0 in JUNOS) depending of state of two sessions with OR logic.
On same slide (http://www.cvent.com/events/nanog-75/custom-116-948222eca5834bc2b7a679399063e724.aspx) you have policy “SET-AP-ANH” atha set next-hop to 1.1.1.2 and is attached as export policy to group “to-RR”

[protocols bgp group to-RR]
    export [ ... SET-AP-ANH ]
    neighbor 11.0.0.6

[policy-options policy-statement SET-AP-ANH term 10]
from {
    as-path fromAS2;
    }
then {
    next-hop 1.1.1.2;
    }

[RJS] I agree. Memory footprint at RR is not an issue. Convergence at scale is.

Convergence is not a problem .. in fact no one should be counting on protocol *convergence* for fast connectivity restoration at any event of failure these days.
[RJS] Let me rephrase connectivity restoration is a problem. To do this fast we need:

  1.  Backup information available on all devices across network. Ideally pre-programed in data-plane
  2.  Ability to switch multiple 1000’s of prefixes form primary to backup as result on ONE event (unreachability of BGP NH address == BGP PIC). To exercise this BGP NG may not be ASBR loopback as it stays in IGP as long as ASBR is UP.

Let assume at site 1 I have 4 ASBRS connected to AS_2 each with 1 sessions, and this ASBR learns 300k prefixes form AS_2 and all of then are best from each ASBR POV. So 300k path per ASBR, 300k pfx per ASBR, 1 path per prefix per ASBR.
The RR gets 4 x 300k pfx with BGP NH set to ASBR1-2-3-4 loopbacks. And send it w/ ADD-PAT to on-site CR
When eBGP session of one of ASBR (say ASBR1) fails, it has to withdraw 300k path from RR, and RR need to withdraw 300k path form CR. Untill this is done CR will keep sending ¼ oftraffic to ASBR1, and BGP NH == loopback is reachable.
Now if ANH is used, CR sees 4 path per prefix with BGP NH == ANH1-2-3-4 respectively. When eBGP session of one of ASBR (say ASBR1) fails, it removes ANH1 form IGP and start to withdraw 300k path from RR, and RR need to withdraw 300k path form CR. As soon as CR sees IGP update (ANH1 unreachable) it can mark all 300k path that have BGP NH == ANH1 unusable. And stop forwarding to ASBR1. If CR runs BGP PIC EDGE it could be sub-second.

All of this works fine today out of the box if you do not set next hop self on your ASBRs (typical cfg in non MPLS networks :).
[RJS] I have impression that NHS is quite popular in non-MPLS as well. I heard it for few customers:

  *   Less losses if external interface flaps and backup exist (typical ASBR has bunch of peers + 1-2 transit/uplink providers)
  *   Peer address may belong to peers IP space. Caring it inside IGP is perceived as operationally problematic - harder to audit/secure network. Not that I personally buy it fully, but I see the point.

And if you do set nhp there as mentioned you can control when it is redistributed into IGP (or removed from it) by tracking any object (or set of objects) you define. Very simple.

[RJS] I do not get this. You mean set BGP NH to peer_IP or loopback?

  *   Peer_IP –  There is more than one way to skin the cat. To get this address into IGP you can:

     *   Configure inter-AS interface under IGP w/ passive option. Then if “object” is tracked, this configuration need to be altered in case of object is unavailable/fault-state.
     *   Redistribute  interface subnet to IGP via policy/route-map. Then if “object” is tracked, this policy configuration need to be altered in case of object is unavailable/fault-state.
     *   The issue with Peer_IP is that it is inherently 1:1 assotiated with session, so if I want to group sessions (see slide 14, where ASBR1.1 has 2 link/sessions to AS2, and slide 12 which explain that peer_AS may have also scale-out topology w/ multiple ASBR @ site) and remove BGP NH address form IGP if given ASBR loose all sessions in group?

  *   Loopback_IP

     *   Let say we may have multiple IP on loopback (or multiple loopbacks) and IP1 used for managing is different from IP2 used to source iBGP sessions which is different form IP3-IPn used to be BGP NH. This way, we may redistribute  IP3-IPn to IGP conditionally w/ tracking of some “object”
     *   This allows me 1:1 as well N:1 assotiation of eBGP sessions to BGP NH
     *   And this is just another way of implementing ANH. It is exactly the same

  *   The question now what is tracked “object” and how we can do this locally.

     *   In draft we track state and EoR of set of sessions. So if session is ESTABLISHED but still in initial learning, ANH is not in IGP. This is to prevent:

        *   Prevent churn when max-prefix is enabled on session and is exceeded. To session will be turn down.
        *   Give some delay to data-plane be programmed before make given ASBR available exit for rest of network.

     *   The other option could be waiting for first BGP keep-a-live after session enter ESTABL state. Yet another will be monitor some “lead” prefix we know could be learned over sesession from set associated with given ANH only.  This is local implementation. In Junos we choose one way, we believe is good, but other implementation can do this it own way (e.g. I know IOS-XR monitors 1st keep-a-live)

 The inter-site operation – advertising only one path w/ BGP NH representing “set of eBGP sessions from set of ASBRS” is just one more optimization. Let call this SP_ANH (Site-Peer ANH in contrast to above discussed ASBR-Peer ANH).

· If RR advertise to other sites only one path and BGP NH is loopback of one of ASBRs (or ASBR-Peer ANH), then what is convergence in case of this ASBR failure?  RR has to send 300k path w/ new BGP NH. Until this is done, remote sites will send traffic somewhere elsw. Not best egress site.
Advertise not one but two paths each coming from different ASBRs.
[RJS] This will work as well to a degree. It obviously requires ADD-PATH among sites.

  *   what if I have 8 ASBRs and by bad luck 2 of them have lost their sessions – the 2 RR choose to re-advertise? I have still 6 ASBR capable to send traffic out, but RR need to remove BGP NH form IGP for both of them. And re-advertise all path with yet another BGP NH. As result traffic will be lost or sent to sub-optimal exit by time needed for BGP to converge.
  *   The other issue is that

·

· If RR advertise to other sites only all 4  path and BGP NH is loopback of one of ASBRs (or ASBR-Peer ANH), then IGP update removing this address will allow for quick restoration (as other 3 path are available everywhere). But in multi-path scenario, we just sreated 2-3 level of ECMP structure on remote BGP speakers:
prefix--> (list of 4 BGP NH) --> each BGP NH --> list of IGP ECMP neighbours. That costly to manage in S/W and in HW

If you advertise ANH per ASBR you will still have 4 different next hops so exactly the case as above.

[RJS] No. My RR is doing:

  1.  Toward CR and ASBR in same site: ADD-PATH with BGP NH unchanged (per ASBR ANH)
  2.  Toward other sites – another BGP NH replacement w/ Site-Peer ANH (Area-Wide)
This way other sites sees BGP NH as it would be anycast for all ASBRs. But inter-site path have ASBR-specific BGP NH. There is hierarchy of abstraction.
When packet arrives on CR of egress site, there is N path with per-ASBR specific NH.

One may ask what if MPLS is used and CR is LSR only. I this case BGP advertisement and BGP NH manipulation is exactly same as above. However Inter-site LSP FEC is Site-Peer ANH, an it must be inserted to IGP/LDP from some node that has full routing – let say from all ASBR (as anycast). It is in addition to ASBR-Peer ANH insertion to IGP.
In this case traffic may indeed leave tunnel on ASBR, hows best route is not external (due to asymmetry you described below and discussed in draft). However as ASBRs get routes form other ASBRs of same site from RR with ASBR-Peer ANH (ASBR specific) it will U-turn traffic to correct ASBR via intra-site infrastructure. It is suboptimal routing, but not cause loop. It is tradeoff – Full IP lookup on CR (or possibly “spine”/aggregation device sitting between ASBR and CR) or intra-site suboptimal routing but only ASBRs need to have Full IP FIB.

I do not pretend that this solution is holy grail of networking and solves world hunger problem. It is Just a tool/solution that may help, and network owner is to judge if it serves him well.

If you however proposing to advertise all paths from all ASBRs with the same next hop (in your case AS-WIDE ANH) - brilliant - but how are you assuring that all EBGP peers send you symmetric routes ? If you get some EBGP sessions giving you partial BGP reachability for whatever reason - and you are still using anycast ANH from all 4 ASBRs the packets which IGP sends towards said ASBRs would be either dropped or looped between ASBRs till TTL expires as next hop is still ANH so anycast.

·

· If RR advertise to other sites only one path and BGP NH is Site-Peer ANH as in this proposal, then Site-Peer ANH is not removed form IGP (as other ASBRs has session with Peer). Re,mote sites keep sending traffic using pre-failure data until BGP update from RR comes. End when it comes, it will have same BGP NH as pre-failure path. So there will be no need to update FIB. Also FIB structure will be simpler and less costly
prefix--> one  BGP NH --> list of IGP ECMP neighbours.
Some merchant chips have really limited ECMP capability…
See above.

See when we worked on concept of virtual BGP paths we did a lot of analysis of this and reached the conclusion that while possible the application of given abstract or virtual next hop to consistent union of  prefixes reachable over N EBGP sessions from single or multiple ASBRs must be automated as you can not assure eBGP symmetry.

So even in your simplest case of ANH per ASBR per PeerAS there is zero guarantee that you get identical paths from all peers. That means that since you are going to keep the ANH in IGP till last session goes away you are going to attract traffic to such ASBRs until BGP withdrawn all affected non symmetrical paths. Trust me much faster would be not to set nh on ASBR and just remove peer's address in IGP in one shot. Then BGP can take however long it takes to "converge" without affecting any data plane.

[RJS] If above is what operator want, it can simply assign ANH to eBGP session on 1:1 basis. We are not discussing now how to do this is CLI of given implementation. Some could be simple some more complex. I just say ANH is assigned to set of eBGP sessions, and nothing prevent operator to make set size == 1.
Indeed in spatial case of 1:1 assignment, use of peers interface IP ( w/ /32 mask) is logical choice. But this is up to AS operator. One big Cloud guys like to give their own IP even in this case, as they do not want IP form other AS address space in IGP.

Many thx,
R.

THX R.

R. 😊

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Mar 2019 21:34:52 +0100

Hey Rafał,

*> To exercise this BGP NG may not be ASBR loopback as it stays in IGP as
long as ASBR is UP.*

Completely not true if you properly configure your ASBRs :).

Imagine next hop self is using loopback 100 and I redistribute it to IGP.

Further observe that interface in a shutdown state is not advertised into
IGP. So all what is needed is to run BFD session to peer which in turn will
remove the connected subnets from global RIB and therefor trigger a
shutdown of your loopback 100.

Very simple and effective :) And if your peer does not like BFD you can
monitor it's interfaces reachability with help of a lot of different
protocols from just your ASBR side. You can set different reaction timers
to UP vs DOWN events, you can configure thresholds if you have a lot of
peers etc ...

Simple example:

/* Tracking your peer’s subnets */

track 1 ip route [peer1_net_address] [peer1_subnet_mask] reachability
track 2 ip route [peer2_net_address] [peer2_subnet_mask] reachability
…

/* Triggering action only when both go down */

track 100 list boolean and
object 1
object 2

!
/* Action DOWN and removal from IGP */

event manager applet LO100-DOWN
event track 100 state down
action 1 cli command "conf t"
action 2 cli command "interface loopback100"
action 2 cli command "shut"
action 3 cli command "end"
action 4 syslog priority errors msg "eBGP peers unreachable; shutting down
lo100"
!
!
/* Action UP and advertising it in IGP */

event manager applet LO100-UP
event track 100 state up
action 1 cli command "conf t"
action 2 cli command "interface loopback100"
action 2 cli command "no shut"
action 3 cli command "end"
action 4 syslog priority errors msg "eBGP peers reachable; activating lo100"
!

*> In draft we track state and EoR of set of sessions. So if session is
ESTABLISHED but *
*> still in initial learning, ANH is not in IGP. This is to prevent:*

When BGP sessions come up and are still in learning mode BGP is (or well
should be) in "READ_ONLY" mode and should not advertise anything to any
peer till EoR is received or timeout happens. Perhaps this is
implementation thing, but I hope all good BGP implementations do support
BGP READ_ONLY mode.

Using lack of Abstract Next Hop to suppress advertised BGP paths somewhere
in the network is a pretty bad idea. Note that it also does not work if
your ANH is AS_WIDE and is common across more then one ASBR.

- -

Bottom line is that solution to all what you are describing has been
shipping commercially in some implementations for years without any 20 page
IETF draft. Moreover your document is really not even describing a BCP, but
how one vendor solved it - rather in a bit suboptimal way (EoR point) or
with much less control (BGP based ANH removal).

IMO it is perfect text to become such vendor’s white paper, but not really
a fit to be an IETF document regardless if it would be of Informational or
BCP character.

Cheers,
R.

---

From: Rafal Jan Szarecki <[email-masked]>
Date: Mon, 4 Mar 2019 20:58:02 +0000

Robert,

See inline.

--
Rafal Szarecki

From: Robert Raszuk <[email-masked]>
Date: Monday, March 4, 2019 at 12:35 PM
To: Rafal Szarecki <[email-masked]>
Cc: Natrajan Venkataraman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

Hey Rafał,

> To exercise this BGP NG may not be ASBR loopback as it stays in IGP as long as ASBR is UP.

Further observe that interface in a shutdown state is not advertised into IGP. So all what is needed is to run BFD session to peer which in turn will remove the connected subnets from global RIB and therefor trigger a shutdown of your loopback 100.

[RJS] What if eBGP goes down while BFD stays up, for whatever reason? IMO tracking BGP session state is correct think to do.

Very simple and effective :) And if your peer does not like BFD you can monitor it's interfaces reachability with help of a lot of different protocols from just your ASBR side. You can set different reaction timers to UP vs DOWN events, you can configure thresholds if you have a lot of peers etc ...

Simple example:

!

action 4 syslog priority errors msg "eBGP peers unreachable; shutting down lo100"

[RJS] And…  you just described how ANH could be implemented.  😊

> In draft we track state and EoR of set of sessions. So if session is ESTABLISHED but
> still in initial learning, ANH is not in IGP. This is to prevent:

When BGP sessions come up and are still in learning mode BGP is (or well should be) in "READ_ONLY" mode and should not advertise anything to any peer till EoR is received or timeout happens. Perhaps this is implementation thing, but I hope all good BGP implementations do support BGP READ_ONLY mode.

[RJS] It is matter of opinion. I see drawback of “READ_ONLY” – it delays propagation of (potentially) large data set --> make entire BGP convergence slower. W/ technique described in draft I propagate large data set ASAP but prevent other speaker from use it, until ANH become active in IGP.

|---------learning/Read-only---------->|
                                       |------------------advertising--------->

|-------------learning/Read-only------------------>|
           |--------------------------advertising------------->
                                                   |
                                                   |
                               <ANH-active in  IGP>|           <  time gained >

Using lack of Abstract Next Hop to suppress advertised BGP paths somewhere in the network is a pretty bad idea. Note that it also does not work if your ANH is AS_WIDE and is common across more then one ASBR.

- -

Bottom line is that solution to all what you are describing has been shipping commercially in some implementations for years without any 20 page IETF draft. Moreover your document is really not even describing a BCP, but how one vendor solved it - rather in a bit suboptimal way (EoR point) or with much less control (BGP based ANH removal).

IMO it is perfect text to become such vendor’s white paper, but not really a fit to be an IETF document regardless if it would be of Informational or BCP character.

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 4 Mar 2019 22:19:16 +0100

> [RJS] What if eBGP goes down while BFD stays up, for whatever reason? IMO
> tracking BGP session state is correct think to do.
>

Not a problem :)  Add as many as you like additional tracking rules.

Example:

event syslog pattern “.*%BGP-5-ADJCHANGE:neighbor x.x.x.x DOWN”

[RJS] It is matter of opinion. I see drawback of “READ_ONLY” – it delays
> propagation of (potentially) large data set à make entire BGP convergence
> slower. W/ technique described in draft I propagate large data set ASAP but
> prevent other speaker from use it, until ANH become active in IGP.
>

The main point of READ_ONLY mode is to reduce control plane churn when
paths learned first would not keep the "best path" status upon other peers
coming up and bringing better paths on the given ASBR.

Besides it matters only during the initial session bring-up. As you have
many peers giving you similar set of routes anyway it really does not
affect your reachability at all.

Thx,
R.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 8 Mar 2019 21:59:53 +0000

Robert, Rafal,

Can we summarize this thread by saying that abstract-nh has the following  goals (listed in order of importance) :

  1.  Rapid deactivation of all routes that resolve through an ANH when the ANH is withdrawn
  2.  Reduction in churn when one or more (but not all) of the BGP sessions that map to an ANH terminates
  3.  Reduction the number of routes advertised to the RR

These benefits are not without cost. Because fewer routes are advertised to the RR, some information is lost.

Do I have this much right?

If Rafal points out this issue in the draft, might network operators be able to make informed decisions regarding whether the costs outweigh the benefits in their network?

                                                      Ron

From: GROW <[email-masked]> On Behalf Of Robert Raszuk
Sent: Monday, March 4, 2019 4:19 PM
To: Rafal Jan Szarecki <[email-masked]>
Cc: [email-masked]; Natrajan Venkataraman <[email-masked]>
Subject: Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

Example:

The main point of READ_ONLY mode is to reduce control plane churn when paths learned first would not keep the "best path" status upon other peers coming up and bringing better paths on the given ASBR.

Besides it matters only during the initial session bring-up.. As you have many peers giving you similar set of routes anyway it really does not affect your reachability at all.

Thx,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 8 Mar 2019 23:43:58 +0100

Hi Ron,

Let's go via your points ...

*> Rapid deactivation of all routes that resolve through an ANH when the
ANH is withdrawn*

I was providing real config samples indicating that the above is possible
to be done today in shipping implementations. So I think while encouraging
community for using next hop indirection is not a bad thing in a form of
BCP calling it as "abstract next hop" vs "virtual next hop" or basically
"loopback next hop" is debatable.

In other words at min document should more focus on the concept of logical
next hop along with options available to invalidate it as opposed to
endorse any particular flavor of its implementation.

*> Reduction in churn when one or more (but not all) of the BGP sessions
that map to an ANH terminates*

I don't think this is really accomplished or guaranteed in general. BGP
advertises entire paths not just NLRIs and next hops and any changes in the
best path advertised will result in churn when such best path goes away.

Only in the case when all path attributes are identical such churn can be
avoided, but it will also avoided today with vanilla nhs on ASBR. I do not
see any extra magic ANH brings to this reduction of churn.

*> Reduction the number of routes advertised to the RR*

Not sure how this is reduced. By default with nhs you advertise best paths
only from any ASBR. Same with ANH. If you use add-paths you may advertise
more then best. So I do not see how ANH reduces RR control plane load nor I
see that such reduction is really so much necessary for control plane
reflector.

Bottom line is that other then the above the proposed document imposes new
terminology for well known best common practices of BGP deployments.

Many thx,
RR.

On Fri, Mar 8, 2019 at 10:59 PM Ron Bonica <[email-masked]> wrote:

> If Rafal points out this issue in the draft, might network operators be
> able to make informed decisions regarding whether the costs outweigh the
> benefits in their network?
>
>
>
>                                                       Ron
>
>
>
> *From:* GROW <[email-masked]> *On Behalf Of * Robert Raszuk
> *Sent:* Monday, March 4, 2019 4:19 PM
> *To:* Rafal Jan Szarecki <[email-masked]>
> *Cc:* [email-masked]; Natrajan Venkataraman <[email-masked]>
> *Subject:* Re: [GROW] Review request for
> draft-szarecki-grow-abstract-nh-scaleout-peering-00
>
>
>
>
>
> Besides it matters only during the initial session bring-up.. As you have

---

From: Rafal Jan Szarecki <[email-masked]>
Date: Sat, 9 Mar 2019 00:32:04 +0000

Ron, Robert,

“Reduction the number of routes advertised to the RR”
I would say “Reduction the number of routes advertised between RR of different sites, while maintaining ECMP and reducing traffic churn”

--
Rafal Szarecki

From: Ron Bonica <[email-masked]>
Date: Friday, March 8, 2019 at 1:59 PM
To: Robert Raszuk <[email-masked]>, Rafal Szarecki <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Natrajan Venkataraman <[email-masked]>
Subject: RE: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

b.       Reduction in churn when one or more (but not all) of the BGP sessions that map to an ANH terminates

c.       Reduction the number of routes advertised to the RR

---

From: Ron Bonica <[email-masked]>
Date: Sun, 10 Mar 2019 23:03:32 +0000

Yes, that is more accurate, and addresses one of Robert’s comments on my message.

                                                                 Ron

From: Rafal Jan Szarecki <[email-masked]>
Sent: Friday, March 8, 2019 7:32 PM
To: Ron Bonica <[email-masked]>; Robert Raszuk <[email-masked]>
Cc: [email-masked]; Natrajan Venkataraman <[email-masked]>
Subject: Re: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00

Ron, Robert,

--
Rafal Szarecki

From: Ron Bonica <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 8, 2019 at 1:59 PM
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Rafal Szarecki <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Natrajan Venkataraman <[email-masked]<mailto:[email-masked]>>
Subject: RE: [GROW] Review request for draft-szarecki-grow-abstract-nh-scaleout-peering-00