Re: [Idr] Mirja Kühlewind's No Objection on draft-ietf-idr-bgp-extended-messages-33: (with COMMENT)

[Alvaro Retana <[e-mail]>]

On July 30, 2019 at 9:38:01 AM, Mirja Kühlewind via Datatracker (
[e-mail]) wrote:

Mirja:

Hi!

Thanks for your review.

...

---------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some comment on use of normative language:

1) I know what the intention is here but this normative language is not
used correctly (sec 4):
"A BGP speaker
MAY send Extended Messages to a peer only if the Extended Message
Capability was advertised by both peers."
This should be a MUST anyway (and moving the "only"):
"A BGP speaker
MUST only send Extended Messages to a peer if the Extended Message
Capability was advertised by both peers."
Or you go for the MUST NOT (and maybe even two sentence) to make it crystal
clear, e.g.
"A BGP speaker
MUST NOT send Extended Messages to a peer if the Extended Message
Capability was not advertised by both peers. A BGP speaker
MAY send Extended Messages to a peer if the Extended Message
Capability was advertised by both peers."

This point (and your last one) should be clarified in light of
clarifications to rfc5492 (Capabilities Advertisement) that were discussed
in Montreal last week.  I’ve started a separate thread with the authors.


2) sec 4:
"If a BGP message with a Length greater than 4,096 octets is received
by a BGP listener who has not advertised the Extended Message
Capability, the listener MUST treat this as a malformed message, and
MUST generate a NOTIFICATION with the Error Subcode set to Bad
Message Length (see [RFC4271] Sec 6.1)."
If this is specified normatively in RFC4271, you should not use normative
language here as well.
I suggest s/MUST/will/

3) sec 4:
s/then it must NOT be sent to the neighbor/then it MUST NOT be sent to the
neighbor/
and
s/it must be withdrawn from service/it MUST be withdrawn from service/

All the actions on these two points are in fact normatively specified in
rfc4271 (which is the reason for the specific references)…so we should use
non-Normative text in both cases.

IOW: your point in #2 is accurate, but the changes suggested in #3 should
not be applied.


Thanks!!

Alvaro.


4) sec 4
"In an iBGP mesh, if BGP Extended Messages are to be advertized, all
peers MUST advertize the BGP Extended Message capability."
Which action(s) should be taken if that is not the case?