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

[Robert Raszuk <[e-mail]>]

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, <[e-mail]> wrote:

> Hi Jérome, all
>
> > From: Jerome Durand (jerduran) [mailto:[e-mail]] > Sent:
> Wednesday, March 25, 2015 9:32 PM
> >
> > Hi Bruno,
> >
> > Interesting there are some similarities to what I proposed here:
> > draft-jdurand-idr-next-hop-liveliness-00
>
> 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
>
>
> > Thanks!
> >
> > Jerome
> >
> >
> >
> >
> >
> >
> > Le 25 mars 2015 à 20:56, <[e-mail]>
> > <[e-mail]> a écrit :
> >
> > > Hi David,
> > >
> > > Thanks for your comments.
> > > Please see inline.
> > >
> > >> From: David Lamparter [mailto:[e-mail]] > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/idr
>
>
>
> _________________________________________________________________________________________________________________________
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>