I suspect that the document is still not quite finmished - I've tried to
write code based on this spec and a few things are unclear / confusing
section 5.1
-----------
Subtype value. The BGP Type and all associated Subtypes are
considered to be DEPRECATED by the BGP4MP Type.
The following BGP Subtypes are defined for the MRT BGP Type.
0 BGP_NULL
1 BGP_UPDATE
2 BGP_PREF_UPDATE
3 BGP_STATE_CHANGE
4 BGP_SYNC *DEPRECATED*
5 BGP_OPEN
6 BGP_NOTIFY
7 BGP_KEEPALIVE
----------
subtype 4 is specifically marked as deprecated, yet the preceeding text
says that all BGP Type Subtypes are deprecated - why is subtype 4 called
out in particular if all subtypes aredeprecated/
Section 5.1.2
--------------
5.1.2. BGP_UPDATE Subtype
The BGP_UPDATE Subtype is used to encode BGP UPDATE messages. The
format of the MRT Message field for this Subtype is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP UPDATE Contents (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The BGP UPDATE contents include the entire BGP UPDATE message which
follows the BGP Message Header. The BGP Message Header itself is not
included.
------------------
How are 32 bit ASNs and IPv6 peers to be encoded in these 32 bit fields?
Or does "deprcated" say "it can't'?
Does the BGP Update Contents include the ENTIRE BGP update message,
reproducing the BGP Marker, Length and Type fields as well as the
contents of the BGP Update payload?
Section 5.1.4
------------------
5.1.4. BGP_STATE_CHANGE Subtype
The BGP_STATE_CHANGE Subtype is used to record changes in the BGP
finite state machine. These FSM states and their numeric encodings
are defined in RFC 4271 [RFC4271], Appendix 1. Both the old state
value and the new state value are encoded as 2-octet numbers. The
format of the MRT Message field is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------------------
The definition of the FSM stats are in section 8.2 of RFC4271, not
Appendix 1, and there does not appear to be any numeric encoding for the
states in this RFC
section 5.9.1
-----------------------
5.9.1. BGP4MP_STATE_CHANGE Subtype
This record is used to encode state changes in the BGP finite state
machine. As with the BGP_STATE_CHANGE Subtype, the BGP FSM states
are encoded in the Old State and New State fields to indicate the
previous and current state. The format is illustrated below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number | Destination AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Old State | New State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
While BGP4MP_STATE_CHANGE message is similar to the BGP_STATE_CHANGE
message, it also includes interface index and Address Family fields.
As with the BGP_STATE_CHANGE message, the FSM states and their
numeric encodings are defined in RFC 4271 [RFC4271], Appendix 1. The
interface index provides the interface number of the peering session.
The index value is OPTIONAL and MAY be zero if unknown or
unsupported. The Address Family indicates what types of addresses
are in the the address fields. At present, the following AFI Types
are supported:
----------------------------------
same comment as before about the inaccurate reference to the the FSM in
RFC4271 and the lack of an encoding of BGP states
section 5.9.6
------------------------
5.9.6. BGP4MP_MESSAGE_AS4 Subtype
This Subtype updates the BGP4MP_MESSAGE Subtype to support 32BIT
Autonomous System numbers. The BGP4MP_MESSAGE_AS4 fields are shown
below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination AS number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Index | Address Family |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Message... (variable)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------------------------
1 - where is "BGP Message" defined? Does it include the Marker?
2 - are all BGP messages (both BGP IPv4 and BGP MP mesages) encoded in
this fashion?
General Comment
The interweaving of deprecated types and current types gets confusing to
say the least. It may be helpful to push the deprecated types and
subtypes into an appendix and leave the body of the text to describe
only the current types and subtypes.
Not ready for the IESG yet imho. Another rev of the draft is called for.
regards,
Geoff
Peter Schoenmaker wrote:
Folks
This note starts the WG Last Call for comments on
draft-ietf-grow-mrt-06.txt, "MRT routing information export format". It
can be found on
<http://www.ietf.org/internet-drafts/draft-ietf-grow-mrt-06.txt>
Currently the document states that the intended status is standards
track, the document's actual proposed status is Informational.
Please review the document carefully, and send your feedback to the
list. Please also indicate whether or not you believe that this
document is ready to go to the IESG.
This Last Call will end on 14 January 2008 at 1400 PST (UTC/GMT-8).
Thanks,
Peter
_______________________________________________
GROW mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/grow
From - Sat
_______________________________________________
GROW mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/grow
