Hi, sorry for the late input.
Larry Blunk wrote: > Would you be in favor of changing the draft language > to use From/To or Source/Destination instead of the current > Peer/Local distinction and explicitly permit the logging of > locally generated messages? In the case of locally generated > messages, the AS numbers and IP's would be swapped. I think it is sensible to change the language. Off line you suggested only doing this for AS numbers. I'm fine with that, or changing it for AS numbers and IP addresses. >>> - The most important question is whether difference in BGP4MP_MESSAGE >>> and BGP4MP_MESSAGE_AS4 is just in MRT message header format, or if it >>> is also semantic information whether these BGP messages were received >>> in 'AS4-style' session or 'old' session (and therefore whether >>> AS_PATH attribute in UPDATE messages contains 2B or 4B AS numbers). >>> >> >> For the current implementation in Quagga there is semantic information. >> The code checks whether the AS4 capability is present on the session >> and, if so, uses BGP4MP_MESSAGE_AS4. If the AS4 capability is absent, it >> will use BGP4MP_MESSAGE and write the AS_PATH and AS4_PATH attributes as >> received from the peer. >> >> However, I am not entirely sure whether it should be an explicit >> requirement to store this semantic information in this way. > > Could you and Ondrej come up with some text on what you > would like to see in the draft? Basically, the issue is that if you do not have semantic information, you do not know how to read the AS_PATH attribute. So, we can either embed this information elsewhere, or require a MESSAGE to have 2-byte numbers in the AS_PATH, and a MESSAGE_AS4 to have 4-byte AS numbers in the AS_PATH. Based on that choice, I think we should do the second, and say something like: In case of a BGP4MP_MESSAGE, the AS_PATH must only consist of 2-byte AS numbers. In case of a BGP4MP_MESSAGE_AS4, the AS_PATH must only consist of 4-byte AS numbers. Note that this is a subtle intentional difference from "whether or not the peer it was received from had AS4 capabilities". cheers, Erik Romijn Information Services RIPE NCC _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
