[atnog] BFD
Kaiser, Karl
karl.kaiser at upc.at
Thu Jan 17 08:13:34 CET 2019
Hi,
also ich kann's nur von unserer Seite aus sagen:
Ja wir haben ASRs im Einsatz und wir haben ein paar Peerings.
Ja wir aktivieren BFD auf BGP Sessions - allerdings nur nach Nachfrage des Kunden.
Nachdem fast alle unsere BGP Sessions auf p2p Links sind die unter eigener Kontrolle stehen wird’s von uns nicht gefordert, kann aber wenn's wer unbedingt haben will aufgedreht werden.
Meines Wissens wurden bis dato keine zusätzlichen Gebühren an Kunden dafür verrechnet.
LG Karl
-----Ursprüngliche Nachricht-----
Von: atnog-bounces at atnog.at [mailto:atnog-bounces at atnog.at] Im Auftrag von Arnold Nipper
Gesendet: Montag, 14. Jänner 2019 19:41
An: Dominic Schallert <ds at schallert.com>; atnog at atnog.at
Betreff: Re: [atnog] BFD
Allen noch ein gutes Neues!
On 14.01.2019 16:24, Dominic Schallert wrote:
> verwendet hier eigentlich jemand BFD für Transit- oder Peering-Sessions?
> So wie ich BFD verstehe, wäre das ja eine gute Sache, nur verwendet es
> kaum wer. Warum eigentlich? Mögliche Gründe die mir einfallen sind:
>
> 1) Nicht notwendig da beide Router directly connected
>
Das "directly connected" ist imho heute häufig über Ethernet und dann auch nicht wirklich mit nur einer Strippe, sondern da ist oft ein (oder
mehrere) Switch(e) dazwischen. Und dann nützt dir das "directly connected" nix.
> 2) Interoperability-Probleme mit unterschiedlichen Routern
>
Wäre mir neu
> 3) Kosten für Lizenzierung —> auf Cisco ASR eine AIS/AES Lizenz
> erfoderlich
>
Und kostet wie viel?
> 4) Vielleicht Historisch bedingt?
>
> Bieten die etwas größeren Transits hier in AT (Anexia, Nextlayer, A1,
> T-Mobile, etc.) ihren Kunden BFD optional an?
>
> Es gibt aktuell übrigens auch ein Proposal für BFD bei IXP Routeservern:
> https://datatracker.ietf.org/doc/draft-ietf-idr-rs-bfd/
>
Das ist *komplett* etwas anderes. Und zwar geht es in dem RFC darum, über den RS auch BFD-Sessions zwischen den Peers aufzusetzen. Bei IXen mit mehr als einem Switch, ist oft der Control Plane Weg unterschiedlich vom Data Plane Weg.
Was ursprünglich als simpel erschien, entwickelte sich dann nach und nach zu einer komplizierten Sache. Oben zitierter Draft erfordert nämlich eine neue SAFI (... both to allow the route server to request its clients use BFD to track data plane connectivity to their peers'
addresses, and for the clients to signal that connectivity state back to the route server.)
Gruß
Arnold
--
Arnold Nipper
email: arnold at nipper.de
mobile: +49 172 2650958
Information gemäß § 14 Unternehmensgesetzbuch: T-Mobile Austria GmbH, Firmensitz: Wien, Geschäftsanschrift Rennweg 97-99, 1030 Wien, Firmenbuchnummer: FN 171112 k, Handelsgericht Wien.
More information about the atnog
mailing list