Subject: Re: [GROW] Graceful BGP session shutdown draft-ietf-grow-bgp-gshut-06

From: Rick Casarez <[email-masked]>
Date: Thu, 12 Feb 2015 15:17:54 -0500

Hello,

First off I will say I love this idea. It is addressing an issue I know
some of my team members and I have discussed before. We have configured our
own set of "DEPREF" policies (Inbound and Outbound) to address it and they
align with this for the most part.

The one difference is that since not all AS will allow LOCAL_PREF
manipulation we instead also use AS-PATH pre-pending outbound to external
peers to make NLRIs from the peer under maintenance less attractive. Since
we have multiple connections those routers not undergoing maintenance will
become preferred paths.

Having said that your solution would be more elegant since we would be able
to create a single policy than configures the same community both
directions for the same result. I am always a fan of simplification if we
can get there. I would prefer it if it can be made part of a BGP
implementation though allowing us to forgo the manual configuration process
we have now.
-------------------
Cheers, Rick

Experiences not things.

---

From: Pierre Francois <[email-masked]>
Date: Thu, 12 Feb 2015 15:54:30 -0800

Hello Rick, 

On Feb 12, 2015, at 12:17 PM, Rick Casarez <[email-masked]> wrote:

> Hello,
> 
> First off I will say I love this idea. It is addressing an issue I know some of my team members and I have discussed before. We have configured our own set of "DEPREF" policies (Inbound and Outbound) to address it and they align with this for the most part.

I am glad to read that :)

> 
> The one difference is that since not all AS will allow LOCAL_PREF manipulation we instead also use AS-PATH pre-pending outbound to external peers to make NLRIs from the peer under maintenance less attractive. Since we have multiple connections those routers not undergoing maintenance will become preferred paths.

When the case is

.  // links with the same AS 
. the neighbouring AS is not setting LP larger on paths received from the session you are bringing down, the effect will be the same.

It's likely to be the case when you are tearing down one of the // sessions you have with your transit provider and your transit is not TE'ing you. 
When shutting down a peering link with a customer, you're never quite sure as well, customer likely decides how to get to you with LP. 

> Having said that your solution would be more elegant since we would be able to create a single policy than configures the same community both directions for the same result. I am always a fan of simplification if we can get there. I would prefer it if it can be made part of a BGP implementation though allowing us to forgo the manual configuration process we have now.

It was the goal. Check with your favourite vendor if it does not, by any chance, already provide the feature ;)

Cheers, 

Pierre.

> -------------------
> Cheers, Rick
> 
> Experiences not things.
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: "Bertrand Duvivier (bduvivie)" <[email-masked]>
Date: Fri, 13 Feb 2015 00:24:55 +0000

Pierre,

Cisco IOS XE and IOS classic support the draft since 18 months
Cisco IOS XR will support it in Q2 2015, code completed.

You got at least 2 networking OS supporting it

Bertrand 
BGP Product Manager.

On 12/02/15 23:54, "Pierre Francois" <[email-masked]> wrote:

>>some of my team members and I have discussed before. We have configured
>>our own set of "DEPREF" policies (Inbound and Outbound) to address it
>>and they align with this for the most part.
>
>>manipulation we instead also use AS-PATH pre-pending outbound to
>>external peers to make NLRIs from the peer under maintenance less
>>attractive. Since we have multiple connections those routers not
>>undergoing maintenance will become preferred paths.
>
>When the case is
>
>. the neighbouring AS is not setting LP larger on paths received from the
>session you are bringing down, the effect will be the same.
>
>It's likely to be the case when you are tearing down one of the //
>sessions you have with your transit provider and your transit is not
>TE'ing you. 
>When shutting down a peering link with a customer, you're never quite
>sure as well, customer likely decides how to get to you with LP.
>
>
>> Having said that your solution would be more elegant since we would be
>>able to create a single policy than configures the same community both
>>directions for the same result. I am always a fan of simplification if
>>we can get there. I would prefer it if it can be made part of a BGP
>>implementation though allowing us to forgo the manual configuration
>>process we have now.
>