Zusammenfassung

  • Entwurf -13 übernimmt die Administratorwerte eines Route Targets in einen anderen Extended-Community-Subtyp, verleiht dieser Kopie aber keine Wirkung auf Routenverteilung oder VRF-Import.
  • Die transitive Kopie kann eine AS-Grenze passieren. Ein eBGP-Filter, der auf den Route-Target-Subtyp prüft, erkennt sie womöglich nicht.

BGP-Tags sind klein. Ihre Aufgaben sind es nicht unbedingt.

Ein Route Target (RT) kann einer Route ihre VPN-Zuordnung geben. Im Betrieb kann es außerdem einschränken, welche Router eine Route erhalten, und den Import in eine passende VRF auslösen. Eine gewöhnliche Extended Community kann eine verwandte Kennzeichnung tragen, ohne diese Rechte zu beanspruchen. Das ist relevant, wenn eine Route nur auf einem Teil der Provider-Edge-Router einem VPN zugeordnet werden soll.

Genau diesen Fall behandelt Entwurf -13, zuletzt aktualisiert am 28. Oktober. Angenommen, zehn PE-Router importieren VPN-Routen mit RT1. Eine weitere Route soll auf einer Teilmenge dieser Router demselben VPN zugeordnet werden, ihre Verteilung wird jedoch von einem anderen RT3 gesteuert. RT1 als Zuordnungsmarke wiederzuverwenden, könnte so verstanden werden, dass jeder RT1 importierende Router die Route erhalten soll. Für jede Teilmenge ein neues Label anzulegen, würde die Zahl der Labels für dasselbe VPN aufblasen.

Der Entwurf schlägt eine abgeleitete Extended Community vor: Die Werte für Global Administrator und Local Administrator des RT bleiben erhalten, der Subtyp wird ersetzt, und das Ergebnis heißt RT-derived EC. Die Werte verweisen auf das RT; der andere Subtyp zeigt, dass die Kopie selbst kein RT ist.

Die Grenze ist ausdrücklich formuliert. Eine RT-derived EC beschränkt laut diesem Entwurf weder die Routenverteilung noch importiert sie eine Route in eine VRF. Auch eine Policy, die auf das passende RT prüft, trifft sie nicht. In das Route Target Membership NLRI aus RFC 4684 darf sie ebenfalls nicht aufgenommen werden. Der Entwurf definiert Zuordnung und Codepunkte. Ein anderes Dokument muss festlegen, was ein Empfänger mit dem Wert tut.

An der Grenze wird es heikel. Der Entwurf bewahrt das höchstwertige Oktett des Type-Feldes. Ein einer transitiven RT entsprechender RT-derived EC bleibt damit transitiv. Ohne gegenteilige Policy kann er eine AS-Grenze passieren. Eine Regel, die den RT-Subtyp filtert oder umschreibt, erfasst den abgeleiteten Subtyp nicht automatisch. Gleiche Administratorwerte, anderer Codepunkt, anderes Matchergebnis.

Der Entwurf dokumentiert die Zuweisung des Subtyps 0x15 in mehreren Extended-Community-Registern, darunter transitive AS-spezifische Formen. Er weist diesen Wert nicht jedem denkbaren RT-Format zu; andere Zuordnungen sind noch beantragt oder offen. RFC 4360 erklärt, warum das Type-Feld Policy-Regeln nach Community-Typ strukturieren kann. Hier ist es gerade der Subtyp, durch den ein Filter ein verwandtes Label übersehen kann.

Eine Prüfung des Operations Directorate der IETF schloss am 30. Oktober die Begutachtung von Version 13 mit dem Ergebnis „Has nits“ ab. Reviewer Gen Chen forderte einen eigenen Abschnitt zu betrieblichen Aspekten und nannte Inter-AS-Filterung und Leckagerisiken, die Geltungsgrenzen sowie das Verhalten älterer BGP-Systeme. Falls die Weitergabe unerwünscht ist, könnten Betreiber 0x15 an eBGP-Grenzen filtern. Das ist ein Review-Hinweis, kein Beleg für ein tatsächliches Leck. Er zeigt die Lücke zwischen einem definierten Codepunkt und der Frage, wie er sich in gemischten Netzen verhält.

Am 2. November befindet sich der Entwurf in der IESG-Evaluierung; für den 5. November ist ein Telechat angesetzt. Ein Informational-Dokument kann die Bit-Zuordnung festlegen, ohne zu entscheiden, wer filtert, wie alte Router reagieren oder wie spätere Anwendungen eingehegt werden. Der Subtyp passt in ein Byte. Die Bestandsaufnahme der Policies ist die größere Arbeit.

Quellen: Entwurf -13 · Operations-Directorate-Review · RFC 4360 · RFC 4684