Subject: [Idr] 4 bytes AS to PS

From: Yakov Rekhter <[email-masked]>
Date: Sat, 12 Nov 2005 20:24:11 -0800

Bill and Alex,

The IDR WG would like to ask the IESG to advance
draft-ietf-idr-as4bytes-12.txt to a Proposed Standard.
The implementation report is draft-huston-idr-as4bytes-survey-00.txt

Sue & Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: John Leslie <[email-masked]>
Date: Mon, 21 Nov 2005 14:33:35 -0500

> The implementation report is draft-huston-idr-as4bytes-survey-00.txt

   IMHO, as4bytes-12 is not ready to advance as written.

   Section 4 states a NEW BGP speaker "MAY" advertise the 4-byte-ASN
capability, thus allowing non-4byte sessions between NEW BGP speakers.
The rest of Section 4 states rules in terms of whether a speaker is
NEW or OLD, rather than in terms of whether the session is 2-byte or
4-byte. IMHO the "MAY" should be a "MUST", or we need to restate
many of the Section 4 rules in terms of session type.

   Section 6 leaves an unresolved potential-routing-loop situation
without any recommended action. (I would guess dropping the NLRI is
the most appropriate action, but I dislike guessing...)

   Clearly there are possible situations in which an AS_TRANS can fail
to be resolved to its corresponding 4-byte ASN. IMHO, there should be
a statement that a NEW BGP speaker whose ASN is >65535 which receives
an unresolved AS_TRANS SHOULD discard that NLRI as a possible loop.

   The "SHALL be constructed" rule in Section 4.2.3 requires generating
(4-byte) AS_PATHs which could easily be known to be inconsistent. IMHO,
this spec should at least allow such situations to discard the NLRI (or
leave the AS_TRANS wherever it is found in the 2-byte AS_PATH).

   (I am sorry to have taken so long to respond -- it was hard to find
time to carefully read as4bytes-12 to make sure I understood things.)

--
John Leslie <[email-masked]>