5. Funzionamento

L'identificatore di percorso specificato nella Sezione 3 può essere utilizzato per annunciare percorsi multipli per lo stesso prefisso di indirizzo senza che gli annunci successivi sostituiscano quelli precedenti. A parte il fatto che questo è ora possibile, le regole di annuncio delle route di [RFC4271] non vengono modificate. In particolare, un nuovo annuncio per un dato prefisso di indirizzo e un dato identificatore di percorso sostituisce un annuncio precedente per lo stesso prefisso di indirizzo e identificatore di percorso. Se uno speaker BGP riceve un messaggio per ritirare un prefisso con un identificatore di percorso non visto prima, DOVREBBE (SHOULD) ignorarlo silenziosamente.

Affinché uno speaker BGP sia in grado di inviare percorsi multipli al suo peer, quello speaker BGP DEVE (MUST) annunciare la capacità ADD-PATH con il campo Invio/Ricezione impostato a 2 o 3, e DEVE (MUST) ricevere dal suo peer la capacità ADD-PATH con il campo Invio/Ricezione impostato a 1 o 3, per il corrispondente <AFI, SAFI>.

Uno speaker BGP DEVE (MUST) seguire le procedure definite in [RFC4271] quando genera un messaggio UPDATE per un particolare <AFI, SAFI> verso un peer, a meno che lo speaker BGP non annunci la capacità ADD-PATH al peer indicando la sua capacità di inviare percorsi multipli per il <AFI, SAFI>, e riceva anche la capacità ADD-PATH dal peer indicando la sua capacità di ricevere percorsi multipli per il <AFI, SAFI>. In tal caso, lo speaker DEVE (MUST) generare un aggiornamento di route per il <AFI, SAFI> basato sulla combinazione del prefisso di indirizzo e dell'identificatore di percorso, e utilizzare le codifiche NLRI estese specificate in questo documento. Il peer DEVE (SHALL) agire di conseguenza nell'elaborazione di un messaggio UPDATE relativo a un particolare <AFI, SAFI>.

Uno speaker BGP DOVREBBE (SHOULD) includere la migliore route [RFC4271] quando più di un percorso viene annunciato a un vicino, a meno che non sia un percorso ricevuto da quel vicino.

Poiché gli identificatori di percorso sono assegnati localmente e possono o meno essere persistenti attraverso un riavvio del piano di controllo di uno speaker BGP, un'implementazione DOVREBBE (SHOULD) prestare particolare attenzione affinché il piano di inoltro sottostante di uno "Speaker ricevente" come descritto in [RFC4724] non sia influenzato durante il graceful restart di una sessione BGP.