Zusammenfassung

  • Die zwölfte Fassung des BIER-BFD-Internet-Drafts legt die unaufgeforderte Meldung eines aktiven Endpunkts für BIER deutlicher auf das Verfahren aus RFC 9780 fest und grenzt es gegen angeforderte Meldungen nach RFC 8563 ab. Bereits Fassung 11 kannte eine entsprechende Untersektion; die aktuelle Änderung erfindet den Alarm nicht neu.
  • Nach einem Verlust der P2MP-BFD-Kontinuität meldet sich der BFER per Unicast auf einem vom Multicast-Baum getrennten Weg beim BFIR. Ein gültiges Final bestätigt die zugeordnete Benachrichtigung, aber nicht die Wiederherstellung der ursprünglichen Verteilung.

Wer die Verfügbarkeit eines Verteilbaums beurteilt, muss fragen, an welcher Stelle eine Beobachtung entstanden ist. Der BFIR sendet BFD-Kontrollpakete an mehrere BFER. Jeder Empfänger kann feststellen, dass seine Kopie ausbleibt. Daraus folgt noch nicht, dass der BFIR weiß, welcher Ast betroffen ist. Die technische Lücke ist zugleich eine Nachweislücke: Ein zentrales Alarmsystem kann schweigen, während am Rand bereits ein Ausfall erkannt wurde.

Der am 29. September datierte Entwurf draft-ietf-bier-bfd-12 macht diesen Übergang zum Gegenstand konkreter Regeln. Im IETF Datatracker steht er als aktiver Entwurf der BIER-Arbeitsgruppe im WG Last Call; der IESG-Status lautet I-D Exists. Eine verabschiedete RFC, ein Beleg für installierte Geräte oder eine Ausfallstatistik ist das nicht. Der Text spezifiziert die Anwendung von punkt-zu-mehrpunkt BFD über BIER.

Für die Richtung vom Kopf zum Ende beschreibt RFC 8562 die Kontinuitätsprüfung. Der einzelne Endpunkt kann einen Verlust feststellen, doch RFC 8562 allein liefert dem Kopf keine Meldung darüber, welcher Empfänger betroffen ist. Abschnitt 6 der neuen Fassung bindet das Verhalten aktiver BIER-Endpunkte ausdrücklich an die unaufgeforderte Benachrichtigung aus RFC 9780, nicht an die dort gegenübergestellten angeforderten Verfahren aus RFC 8563. Diese Aussage darf nicht überdehnt werden: Die vorherige Entwurfsfassung enthielt bereits einen Abschnitt zur unaufgeforderten Meldung, und auch RFC 8563 erwähnt unaufgeforderte Pakete.

Neu ist die präzisere Verfahrenswahl mitsamt verbindlicher formulierten Paketfeldern und Antwortschritten.

Nach der Fehlererkennung setzt der BFER im BFD-Kontrollpaket das Poll-Bit, den Status Down und die Diagnose Control Detection Time Expired. Your Discriminator enthält den My Discriminator der ausgefallenen P2MP-Sitzung. Die Zieladresse ist die IP-Adresse des BFIR, der UDP-Zielport 4784. Die Nachricht läuft als Unicast über einen Pfad, der vom Multicast-Verteilbaum getrennt sein muss. Eine Alarmierung über denselben womöglich defekten Baum wäre kein unabhängiger Rückkanal.

Der Entwurf verlangt einen Versand pro Sekunde, bis für die Sitzung ein gültiges Final eintrifft oder die Störung verschwindet. Um die Zustellung wahrscheinlicher zu machen, empfiehlt er zudem drei Pakete in pseudozufälligen Abständen innerhalb einer Sekunde. Beim BFIR wird die Sitzung anhand von Your Discriminator ausgewählt; nach erfolgreicher Zuordnung sendet er unicast ein BFD-Paket mit Final zurück. Die Sitzung der eingehenden Multicast-Pakete bestimmt der Endpunkt dagegen durch die Kombination aus BFIR-id und dem My Discriminator des Kopfes. Diese unterschiedlichen Zuordnungen gehören in die Beweiskette eines Alarms.

Der Entwurf weist ebenfalls darauf hin, dass gleichzeitig betroffene Empfänger eine Meldungswelle an die Steuerungsebene auslösen können, und behandelt deren Begrenzung. Daraus folgt als Betriebsfrage, nicht als gemessene Schadensmeldung: Ist ein fehlender Alarm wirklich ein gesundes Netz, oder ist der Rückweg beziehungsweise die Annahmekapazität ausgefallen? Ebenso beweist ein Final nur die Antwort auf die Meldung, nicht den wiederhergestellten Hinweg. Der frühere BIER-Ping-Beitrag betraf Diagnoseparameter und Zulassungsschritte; hier geht es um die Übermittlung einer laufend gewonnenen Fehlerbeobachtung.

Quellen