Hi All,
I apologize for the late reply to the WGLC. I have a couple of comments I'd
like to raise. I'll start by saying that although I'm going to bring up a
couple problems with draft-ietf-grow-bmp-local-rib, I think at least the second
was inherent in RFC 7854, and I will start a different mail thread to discuss
the problem and proposed fix in more detail. (Not to keep anyone in suspense, I
think it was a mistake to have the Initiation and Peer Up messages share a
namespace. More broadly I think the authors, ahem, of 7854 didn't drink enough
of the TLV koolade before finalizing it.)
Issue 1. draft-ietf-grow-bmp-local-rib says:
Peer down notification SHOULD follow the section 4.9 [RFC7854] reason
2.
The VRF/Table Name informational TLV SHOULD be included if it was in
the Peer UP.
This doesn't make sense to me, since the definition of reason 2 in RFC 7854
section 4.9 doesn't allow for any extra data:
o Reason 2: The local system closed the session. No notification
message was sent. Following the reason code is a 2-byte field
containing the code corresponding to the Finite State Machine
(FSM) Event that caused the system to close the session (see
Section 8.1 of [RFC4271]). Two bytes both set to 0 are used to
indicate that no relevant Event code is defined.
One fix, I think the more expedient one, would be to request a new reason code
("TBD3"), whose format includes both the content carried in reason 2, and a
VRF/Table Name. Then if you want to send the table name, you use the new reason
code.
An alternate fix, somewhat more involved but possibly useful in the long run,
would be to update RFC 7854 to permit Peer Down messages to carry additional
data beyond the reason code and its own associated data, and then to define the
format of that data. Probably the additional data would be TLVized. It would
obviously need to have a registry created for it.
By the way, shouldn't those "SHOULDs" be "MUSTs"? If not MUST, under what
circumstances MAY they be omitted?
Issue 2. draft-ietf-grow-bmp-local-rib says:
The following peer UP information TLV types are added:
o Type = TBD2: VRF/Table Name. The Information field contains an
ASCII string whose value MUST be equal to the value of the VRF or
table name (e.g. RD instance name) being conveyed. The string
size MUST be within the range of 1 to 255 bytes.
The VRF/Table Name TLV is optionally included. For consistency,
it is RECOMMENDED that the VRF/Table Name always be included. The
default value of "global" SHOULD be used for the default Loc-RIB
instance with a zero-filled distinguisher. If the TLV is
included, then it SHOULD also be included in the Peer Down
notification.
Nit1, "types are added" should be "type is added".
Nit2, I'm not crazy about the definition of string here, and ASCII should
almost certainly be UTF-8. I will offer a replacement definition in the other
thread I'll start.
Nit3, all those SHOULDs. Can't they be MUSTs? If not, can you give the reader a
hint of why not?
The real problem (this is the one that came from RFC 7854): though the text
says "peer UP information TLV types are added", there is no such thing as the
peer UP information TLV! We could fix this by adding the type to the
Information TLV, which in RFC 7854 is shared by Initiation and Peer Up. However
I think it is a cleaner fix to separate the namespaces, one for Initiation and
one for Peer Up. Once that's done (and it should be easy unless there's
controversy), just allocate the TLV out of the (to be created) Peer Up Message
TLVs registry. (This is what I'm starting a new thread to discuss.)
Thanks,
--John
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
