Picking up the point about the FSM states, you are right that the enumeration no longer appears in the base RFC but remains defined in the MIB, RFC4273.
Tom Petch ----- Original Message ----- From: "Geoff Huston" <[EMAIL PROTECTED]> To: "Peter Schoenmaker" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Saturday, December 29, 2007 7:32 PM Subject: Re: [GROW] Last Call mrt > 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 _______________________________________________ GROW mailing list [email protected] https://www1.ietf.org/mailman/listinfo/grow
