Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost

From: Jeff Tantsura <[email-masked]>
Date: Tue, 29 Sep 2015 20:54:17 +0000

Very much support Jakob¹s points, in a reasonable big deployment different
updates will inevitably arrive in a different order.

Cheers,
Jeff

-----Original Message-----
From: "Jakob Heitz   (jheitz)" <[email-masked]>
Date: Tuesday, September 29, 2015 at 1:25 PM
To: "[email-masked]" <[email-masked]>, idr wg
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [Idr] decraene-idr-next-hop-capability <->
ietf-idr-bgp-nh-cost

>Another benefit of advertising the next-hop capability in the same
>update as the prefixes it applies to is that the receiving router
>then will know the capabilities at the time that it receives the
>prefixes.
>
>If this information were to come in a different update message in
>a different SAFI, it will not know how to treat the prefix until
>the update containing the next-hop capability is received.
>The next-hop SAFI update could come at any time before or after
>the prefix update. BGP updates are not synchronized unless the
>NLRI is the same, especially if route reflectors or confeds are used.
>
>If there are multiple paths to a prefix and a new path with
>unknown nexthop capabilities becomes bestpath, traffic loss can
>occur until the nexthop capabilities are learnt.
>
>Therefore, it is best to keep all information about how to treat
>a prefix in the update message that advertises that prefix.
>
>--Jakob
>
>> -----Original Message-----
>> From: Idr [mailto:[email-masked]] On Behalf Of
>>[email-masked]
>> Sent: Wednesday, March 25, 2015 12:57 PM
>> To: David Lamparter <[email-masked]>
>> Cc: idr wg <[email-masked]>; [email-masked];
>>[email-masked]
>> Subject: Re: [Idr] decraene-idr-next-hop-capability <->
>>ietf-idr-bgp-nh-cost
>> 
>> Hi David,
>> 
>> Thanks for your comments.
>> Please see inline.
>> 
>> > From: David Lamparter [mailto:[email-masked]] > Sent: Tuesday,
>>March 24, 2015 4:30 PM
>> >
>> > Hi Bruno, Ilya, Robert,
>> > Hi idr list,
>> >
>> >
>> > the next-hop-capability draft currently seems to target using the new
>>nexthop
>> > capability on a per-advertisement level.  Considering that
>>draft-idr-bgp-nh-
>> > cost adds a new SAFI to convey information about nexthops, it seems
>>natural
>> > to tranposrt the capability information in that place?
>> 
>> That's a valid comment.
>> 
>> 1)  cost/benefit
>> Avertising the next-hop-capability on a per update basis has indeed a
>>cost but also a benefit.
>> In term of cost, the simplest next-hop-capability is 5 octets. Compared
>>to an update in the range of 100-1000 octets,
>> that's 5% to 0,5%.
>> In term of benefit, this allow customizing the capability on a per
>>update/routes granularity if required, which may
>> be a useful possibility for some capabilities.
>> Engineering is about trade-off. IMO, the benefit, especially long term,
>>out weight the fixe cost, which is small and
>> will become smaller, in relative term, in the future (thanks to Moore's
>>law).
>> 
>> 2) deployability
>> In addition, in term of deployability, a new attribute has no impact.
>>On the other hand draft-idr-bgp-nh-cost use a
>> new AFI/SAIF which requires reconfiguration and reboot of all BGP
>>sessions. This is a much higher cost for IBGP
>> alone. For EBGP, this is simply not an option IMO.
>> 
>> 
>> So, I agree that this is a valid option to consider, however I don't
>>think that it's a better one.
>> 
>> > (That would also remove the question of what behaviour should be when
>>you
>> > get different advertisements with the same nexthop, but with a
>>different
>> > nexthop capability attribute.)
>> 
>> For a given route/NLRI, you use the next-hop capability attached to
>>this route.
>> To rephrase, you do not consider next-hop capability that may have been
>>advertised in another update.
>> I agree that this may not be crystal clear in the text, I will clarify
>>in the next revision.
>> 
>> Thanks again for your comments,
>> Bruno
>> 
>> >
>> >
>> > -David
>> 
>> 
>>_________________________________________________________________________
>>___________________________________________
>> _____
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations
>>confidentielles ou privilegiees et ne doivent
>> donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>>recu ce message par erreur, veuillez le
>> signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>>messages electroniques etant susceptibles
>> d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged
>>information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and
>>delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>>been modified, changed or falsified.
>> Thank you.
>> 
>> _______________________________________________
>> Idr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/idr
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 29 Sep 2015 23:07:07 +0200

Jakob, Jeff,

At surface the point mentioned by Jakob looks very attractive. However the
topic needs to be sorted into and looked with sufficient depth:

- distributing critical reachability information in band of given update
msg
- distributing optimizations

For critical reachability I agree (but hardly there are really cases like
this in BGP).

For optimizations I do not agree - Explanation: BGP next hops should
resolve in their native way. If there is no resolution for next hop via
recursion or IGP or static path is invalid.

Once there is resolution path becomes valid and eligible for best path.

If I change my next hop forwarding rewrite to different tunnel, LSP,
segment or native IP that should not trigger re advertisement of millions
of BGP routes which otherwise will be necessary if you always insist in
carrying all information in the same message.

Cheers,
R.

---

From: <[email-masked]>
Date: Wed, 30 Sep 2015 09:15:07 +0000

Hi Robert,

The goal is to advertise next-hop dependent capabilities, more than next-hop capabilities. I agree that this may not have been clear from reading the title/name, and hence I’m considering changing the name (suggestions welcomed. Current candidate is :s/Next-Hop/Next-Hop dependent ).

What we want is an attribute which is removed when the BGP Next-Hop is changed. Using this, we can advertise capabilities which are next-hop dependent. But they may also depend on other things, e.g. be NLRI specific.
The entropy label capability is an example, defined in the draft. (for 2 NLRI having the same BGP Next-Hop, you may have one which supports Entropy Label (EL) and the other which does not support).

Bottom line, advertising capability only on a Next-Hop basis (e.g. using  ietf-idr-bgp-nh-cost) is not a feasible option for the EL use case.

Cheers,
Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Tuesday, September 29, 2015 11:07 PM
To: Jeff Tantsura
Cc: Jakob Heitz (jheitz); DECRAENE Bruno IMT/OLN; idr wg; [email-masked]
Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost

Jakob, Jeff,

At surface the point mentioned by Jakob looks very attractive. However the topic needs to be sorted into and looked with sufficient depth:

- distributing critical reachability information in band of given update msg
- distributing optimizations

For critical reachability I agree (but hardly there are really cases like this in BGP).

For optimizations I do not agree - Explanation: BGP next hops should resolve in their native way. If there is no resolution for next hop via recursion or IGP or static path is invalid.

If I change my next hop forwarding rewrite to different tunnel, LSP, segment or native IP that should not trigger re advertisement of millions of BGP routes which otherwise will be necessary if you always insist in carrying all information in the same message.

Cheers,
R.

On Tue, Sep 29, 2015 at 10:54 PM, Jeff Tantsura <[email-masked]<mailto:[email-masked]>> wrote:
Very much support Jakob¹s points, in a reasonable big deployment different
updates will inevitably arrive in a different order.

Cheers,
Jeff

-----Original Message-----
From: "Jakob Heitz   (jheitz)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 29, 2015 at 1:25 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, idr wg
<[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,
"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] decraene-idr-next-hop-capability <->
ietf-idr-bgp-nh-cost

>> From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>>[email-masked]<mailto:[email-masked]>
>> To: David Lamparter <[email-masked]<mailto:[email-masked]>>
>> Cc: idr wg <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
>>[email-masked]<mailto:[email-masked]>
>> > From: David Lamparter [mailto:[email-masked]<mailto:[email-masked]>] > Sent: Tuesday,
>>March 24, 2015 4:30 PM
>> >
>> > Hi Bruno, Ilya, Robert,
>> > Hi idr list,
>> >
>> >
>> [email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Sep 2015 11:36:10 +0200

Hi Bruno,

I agree that we should not put everything in one basket and that was what I
have tried to communicate in my msg.

In fact my message was general applicable not solely to your document but
also to tunnel safi.

As far as example with EL I am not clear.

EL is function of the forwarding and I can not see why for given next hop
some packets carrying EL will be correctly switched by such nhs router vs
other would not.

Cheers,
R.
On Sep 30, 2015 11:15 AM, <[email-masked]> wrote:

> Hi Robert,
>
>
>
> The goal is to advertise next-hop dependent capabilities, more than
> next-hop capabilities. I agree that this may not have been clear from
> reading the title/name, and hence I’m considering changing the name
> (suggestions welcomed. Current candidate is :s/Next-Hop/Next-Hop
> dependent ).
>
>
>
> What we want is an attribute which is removed when the BGP Next-Hop is
> changed. Using this, we can advertise capabilities which are next-hop
> dependent. But they may also depend on other things, e.g. be NLRI specific.
>
> The entropy label capability is an example, defined in the draft. (for 2
> NLRI having the same BGP Next-Hop, you may have one which supports Entropy
> Label (EL) and the other which does not support).
>
>
>
> Bottom line, advertising capability only on a Next-Hop basis (e.g. using
> ietf-idr-bgp-nh-cost) is not a feasible option for the EL use case.
>
>
>
> Cheers,
>
> Bruno
>
>
>
>
>
> *From**:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Tuesday, September 29, 2015 11:07 PM
> *To:* Jeff Tantsura
> *Cc:* Jakob Heitz (jheitz); DECRAENE Bruno IMT/OLN; idr wg;
> [email-masked]
> *Subject:* Re: [Idr] decraene-idr-next-hop-capability <->
> ietf-idr-bgp-nh-cost
>
>
>
> Jakob, Jeff,
>
>
>
>
>
> On Tue, Sep 29, 2015 at 10:54 PM, Jeff Tantsura <
> [email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 30 Sep 2015 12:35:12 +0000

Hi Robert,

Please see inline #Bruno

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Wednesday, September 30, 2015 11:36 AM
To: DECRAENE Bruno IMT/OLN
Cc: idr wg; Jakob Heitz (jheitz); [email-masked]; Jeff Tantsura
Subject: RE: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost

Hi Bruno,

I agree that we should not put everything in one basket and that was what I have tried to communicate in my msg.

In fact my message was general applicable not solely to your document but also to tunnel safi.

EL is function of the forwarding and I can not see why for given next hop some packets carrying EL will be correctly switched by such nhs router vs other would not.

#Bruno EL capability is in fact the capability to process the EL on the Egress LSR. ( https://tools.ietf.org/html/rfc6790#section-5 first sentence)

During the BGP signaling from the Egress to the Ingress, the BGP Next-Hop may change, in particular when crossing ASBR. Such BGP Next-Hop are Transit LSR for this LSP, and they don’t require new forwarding capability. ( https://tools.ietf.org/html/rfc6790#section-4 )

Let’s illustrate with the following example:

- labelled IP unicast routes (AFI 1, SAFI 4), hence we’ll discuss the propagation of PEs’ loopback address

-2 ASes (AS1, AS2)

- AS2 is the egress AS, having PE2a, PE2b and ASBR2

- AS1 is the ingress AS, having PE1 and ASBR1

- PE2a supports EL as egress hence advertise the capability in BGP, P2B does not support EL as egress hence does not support the capability in BGP.

During BGP propagation from PE2x to PE1, ASBR1 (and probably ASBR2) will change the BGP Next-Hop (to self). As a result both PE2a and PE2b route will have ASBR1 as BGP Next Hop. But only PE2a route will have the EL BGP NH capability.

To specifically answer your question, you are right that both packets will be equally correctly switched (label swapped) by the BGP Next-Hop. But the LSPs do not stop at the BGP Next-Hop and the concern is further down, on the LSR Egress.

Cheers,

Bruno

Cheers,
R.
On Sep 30, 2015 11:15 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Cheers,
Bruno

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert Raszuk
Sent: Tuesday, September 29, 2015 11:07 PM
To: Jeff Tantsura
Cc: Jakob Heitz (jheitz); DECRAENE Bruno IMT/OLN; idr wg; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] decraene-idr-next-hop-capability <-> ietf-idr-bgp-nh-cost

Jakob, Jeff,

Cheers,
R.

Cheers,
Jeff

-----Original Message-----
From: "Jakob Heitz   (jheitz)" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, September 29, 2015 at 1:25 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, idr wg

Thank you.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 30 Sep 2015 15:17:59 +0200

Hi Bruno,

I see your line of thinking here.

However the transit node which sets nhs on the wat to the egress could
propagate or reset/delete EL labels instead of propagating this info.

In fact very ingress may not have much control over which final exit point
packets will traverse as it depends on number of dynamic events later in
the network especially when number of nodes set nhs.

To conclude I am sure you can provide specific use case where this
extension helps in this case which can justify proceeding with the draft.

However in general I would be rather carefull with going that path for
other scenarios which set nhs.

Cheers,
R.
On Sep 30, 2015 2:35 PM, <[email-masked]> wrote:

> Hi Robert,
>
>
>
> Please see inline #Bruno
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk
> *Sent:* Wednesday, September 30, 2015 11:36 AM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* idr wg; Jakob Heitz (jheitz); [email-masked]; Jeff
> Tantsura
> *Subject:* RE: [Idr] decraene-idr-next-hop-capability <->
> ietf-idr-bgp-nh-cost
>
>
>
> Hi Bruno,
>
> #Bruno EL capability is in fact the capability to process the EL on the
> Egress LSR. ( https://tools.ietf.org/html/rfc6790#section-5 first
> sentence)
>
> During the BGP signaling from the Egress to the Ingress, the BGP Next-Hop
> may change, in particular when crossing ASBR. Such BGP Next-Hop are
> Transit LSR for this LSP, and they don’t require new forwarding capability. (
> https://tools.ietf.org/html/rfc6790#section-4 )
>
> - PE2a supports EL as egress hence advertise the capability in BGP, P2B
> does not support EL as egress hence does not support the capability in BGP.
>
> During BGP propagation from PE2x to PE1, ASBR1 (and probably ASBR2) will
> change the BGP Next-Hop (to self). As a result both PE2a and PE2b route
> will have ASBR1 as BGP Next Hop. But only PE2a route will have the EL BGP
> NH capability.
>
>
>
> To specifically answer your question, you are right that both packets will
> be equally correctly switched (label swapped) by the BGP Next-Hop. But the
> LSPs do not stop at the BGP Next-Hop and the concern is further down, on
> the LSR Egress.
>
> Cheers,
>
> Bruno
>
>
>
> Cheers,
> R.
>
> (suggestions welcomed. Current candidate is :s/Next-Hop/Next-Hop dependent
> ).
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Robert
> Raszuk