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

From: David Lamparter <[email-masked]>
Date: Tue, 24 Mar 2015 22:29:35 +0100

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

-David

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 24 Mar 2015 22:42:52 +0100

Hello David,

Yes I very much agree with you that nh safi is a much better fit for
transporting bgp next hop capabilities.

Many thx,
R.

---

From: <[email-masked]>
Date: Wed, 25 Mar 2015 19:56:48 +0000

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.

---

From: "Jerome Durand (jerduran)" <[email-masked]>
Date: Wed, 25 Mar 2015 20:32:28 +0000

Hi Bruno,

Interesting there are some similarities to what I proposed here:
draft-jdurand-idr-next-hop-liveliness-00
Where I tried to describe how we could carry next-hop capability to implement a host liveliness mechanism and solve the route-server black-holing stuff we have been talking about lately. Having a kind of general framework for any capability (ie. not just host liveliness) makes sense.

But your proposal relies on a non transitive attribute and couldn’t pass the route-server so I cannot adjust my proposal to fit in yours.

Anyway note that now I more or less stopped that work for the moment to focus on a more automated solution as there were some challenges with BGP (issues described in the draft). Also it seems that it was quite heavy from a processing/memory point of view to have new attributes per route. Note we had the idea to use some kind of "magic route" in order to have the attribute transported only once. Maybe to be investigated further. This is also described in the draft.

Thanks!

Jerome

Le 25 mars 2015 à 20:56, <[email-masked]> <[email-masked]> a écrit :

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: David Lamparter <[email-masked]>
Date: Wed, 25 Mar 2015 22:04:04 +0100

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

Sure, the attribute is smaller.  But how many neighbors are there?  How
many routes are there?  What's the semantic / complexity impact of tying
this to update processing?  I assume the attribute is sent only once, on
a randomly picked update that has the "right" nexthop - what happens if
that route is withdrawn?  What if the last route with nexthop X gets
withdrawn?

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

I don't think we should design "around" limitations.
Fix the limitation?

> I agree that this may not be crystal clear in the text, I will clarify in the next revision.

Er - I'd go as far as change the name then.  It's not "next-hop
capability", it's "route's (including next-hop) capability".  Most
significantly, it won't be useful in any context that is really nexthop.
The way you describe it, I can't feed information from this attribute
into the nexthop table.

If there's a need to signal route 'flag bit' capabilities more
efficiently than adding an empty attribute - sure.  But that's not
"next-hop capabilities".

-David

---

From: <[email-masked]>
Date: Tue, 31 Mar 2015 10:22:17 +0000

Hi Jérome, all

> From: Jerome Durand (jerduran) [mailto:[email-masked]] > Sent: Wednesday, March 25, 2015 9:32 PM
> 
> Hi Bruno,
> 

You are right. 
I had read your document and had considered chatting this with you, but then understood that you were now favoring a different approach (namely draft-jdurand-auto-bfd).

> Where I tried to describe how we could carry next-hop capability to
> implement a host liveliness mechanism and solve the route-server black-
> holing stuff we have been talking about lately. Having a kind of general
> framework for any capability (ie. not just host liveliness) makes sense.

Thanks. I clearly agree with you.
 
> But your proposal relies on a non transitive attribute and couldn't pass the
> route-server so I cannot adjust my proposal to fit in yours.

ID. next-hop-capability _needs_ a non transitive attribute so this is not something that I can accommodate.
Can't the route-server be extended to support the capability? Looks like a relatively small change (and if the Route Server is known to never change the next-hop, a (horrible) hack would be just a matter of recognizing the attribute to pass it unchanged. But I will deny having said this ;-) )
 
> Anyway note that now I more or less stopped that work for the moment to
> focus on a more automated solution as there were some challenges with BGP
> (issues described in the draft). Also it seems that it was quite heavy from a
> processing/memory point of view to have new attributes per route. Note we
> had the idea to use some kind of "magic route" in order to have the attribute
> transported only once. Maybe to be investigated further. This is also
> described in the draft.

Thanks for the feedback. As of today, IMO carrying the attribute in each update is simpler and more flexible. Some NH capability may need this (and as a matter of fact, the entropy label capability needs this).

Thanks for the comments and feedback.
/Bruno

> >> 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
> > 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.
> >
> >
> ____________________________________________________________
> __________
> > ___________________________________________________
> >
> > 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,
> > 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.

---

From: <[email-masked]>
Date: Tue, 31 Mar 2015 10:22:28 +0000

David, all

> From: David Lamparter [mailto:[email-masked]] > Sent: Wednesday, March 25, 2015 10:04 PM
> 
> > > From: David Lamparter [mailto:[email-masked]] > Sent: Tuesday,
> > > March 24, 2015 4:30 PM 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
> Sure, the attribute is smaller.  But how many neighbors are there?  How many
> routes are there? 

This is application specific.
The first capability is applicable to MPLS routes, typically inter AS MPLS routes, typically within an administrative domain. e.g. in the range of 1k to 10k
If your point is that BGP will not scale one additional attribute/ 10 bytes per update, you could comment many more IDR related documents. (I will refrain from picking names to avoid trolling IDR ML)
If your point is about the trade-off with regard to a different encoding (namely ID.bgp-nh-cost), I have already replied to that point.

> What's the semantic / complexity impact of tying this to update processing?

You mean, compared to other attribute? I'd say roughly the same as others (I would even say on the low end side). Do you see an issue?

>  I assume the attribute is sent only once, on a randomly
> picked update that has the "right" nexthop - what happens if that route is
> withdrawn?  What if the last route with nexthop X gets withdrawn?

The attribute defines NH capabilities for the NLRI advertised in the update. Hence, it's advertised in each UPDATE requiring the advertisement of a capability. e.g. for the Entropy Label Capability, typically in each UPDATE carrying labels routes to Entropy Label capable routers loopback
This may not be clear in -00. This will be clarified in -01. Thanks for the comment.
 
> I don't think we should design "around" limitations.

I think we should design based on reality, especially if deployment is the goal.

> Fix the limitation?

In the meantime, the argument holds.
 
> > > (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.)
> >
> Er - I'd go as far as change the name then.  It's not "next-hop capability", it's
> "route's (including next-hop) capability". 

Changing the name is a possibility. However, the key behavior is that such capabilities are removed when the next-hop is changed. The current name reflects this behavior.

> Most significantly, it won't be useful
> in any context that is really nexthop.
> The way you describe it, I can't feed information from this attribute into the
> nexthop table.

Meaning ietf-idr-bgp-nh-cost is not applicable?
 
> If there's a need to signal route 'flag bit' capabilities more efficiently than
> adding an empty attribute - sure.  But that's not "next-hop capabilities".

Using ID.next-hop-capability, one may define a capability carrying flags. This has been considered in -00 but rejected to favor simplicity and to focus first discussions. This may be added in a subsequent version.
Regarding the first capability (Entropy Label), following first discussion after IDR meeting, it seems likely that the value will be used to advertise the Readable Label Size Depth. Hence flag would not be applicable.

Thanks,
/Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 31 Mar 2015 07:34:38 -0500

Hi Bruno,

Three small questions (to warm up :)

- do you assume in practice next hop self on ingress border router towards
your ibgp

- how do you handle third party next hop behaviour

- do you plan to modify the draft to use it with next hop new SAFI

Many thx,
R.
 On Mar 31, 2015 3:22 AM, <[email-masked]> wrote:

> I had read your document and had considered chatting this with you, but
> then understood that you were now favoring a different approach (namely
> draft-jdurand-auto-bfd).
>
>
> Can't the route-server be extended to support the capability? Looks like a
> relatively small change (and if the Route Server is known to never change
> the next-hop, a (horrible) hack would be just a matter of recognizing the
> attribute to pass it unchanged. But I will deny having said this ;-) )
>
> Thanks for the feedback. As of today, IMO carrying the attribute in each
> update is simpler and more flexible. Some NH capability may need this (and
> as a matter of fact, the entropy label capability needs this).
>
> > >> March 24, 2015 4:30 PM
> that
> > > Avertising the next-hop-capability on a per update basis has indeed a
> cost
> > but also a benefit.
> > > So, I agree that this is a valid option to consider, however I don't
> think that
> > it's a better one.
> > >
> > > For a given route/NLRI, you use the next-hop capability attached to
> this
> > route.
> > > I agree that this may not be crystal clear in the text, I will clarify
> in the next
> > revision.
> > >
> > Orange decline toute responsabilite si ce message a ete altere, deforme
> ou
> > falsifie. Merci.
> > >
> > > 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.
> > >
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Tue, 31 Mar 2015 13:30:30 +0000

Hi Robert,

Please see inlined.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk Sent: Tuesday, March 31, 2015 2:35 PM

Hi Bruno,

[Bruno] I was waiting for your email ;-)

- do you assume in practice next hop self on ingress border router towards your ibgp

[Bruno] No assumption. Should work for Next-Hop self  and Next-Hop unchanged.

More specifically

- for Next-Hop Self, the Next-Hop Capability must be removed. A new one may be attached, with whatever relevant information.

- for next-hop unchanged, the Next-Hop Capability should be kept

[Bruno] As the Next-Hop is not changed, the Next-Hop Capability is not changed, hence reflect the capability of the third party.

[Bruno] The Next-Hop Capability is a BGP attribute which can be attached to routes of (a priori) any AFI/SAFI. Therefore it may a priori be used with the next-hop SAFI. That being said, it’s not clear to me what ID.nh-cost sets in the “Network Address of Next Hop” field of the MP_REACH_NLRI attribute. i.e. it’s not clear if ID.nh-cost use the BGP Next-Hop field. I guess first action would be to clarify this in ID.nh-cost.

In the meantime, trying to theorize

 - If this BGP Next-Hop is set to the NEXT_HOP field of the nh-cost SAFI, then it looks like the ID.next-hop-capability can be directly applied to nh-cost SAFI

- Otherwise, short answer is that ID. nh-cost may need to define how the Next-Hop Capability is used for this SAFI. One sub-option would be to advertise a single NLRI (hence next-hop route per update). Or to extend the nh-cost SAFI NLRI to also carry BGP attributes related to this NLRI (NEXT-HOP)…I trust your creativity.

/Bruno

Many thx,
R.
On Mar 31, 2015 3:22 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Jérome, all

> From: Jerome Durand (jerduran) [mailto:[email-masked]<mailto:[email-masked]>] > Sent: Wednesday, March 25, 2015 9:32 PM
>
> Hi Bruno,
>

You are right.

> Thanks!
>
> Jerome
>
>
>
>
>
>
> Le 25 mars 2015 à 20:56, <[email-masked]<mailto:[email-masked]>>
> <[email-masked]<mailto:[email-masked]>> a écrit :
>
> > Hi David,
> >
> >> 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]>

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr