Subject: [GROW] Last Call mrt

From: Peter Schoenmaker <[email-masked]>
Date: Thu, 27 Dec 2007 13:00:38 -0800

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-masked]
https://www1.ietf.org/mailman/listinfo/grow

---

From: Geoff Huston <[email-masked]>
Date: Sun, 30 Dec 2007 05:32:17 +1100

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>
> 
>  From - Sat

---

From: "tom.petch" <[email-masked]>
Date: Mon, 31 Dec 2007 13:59:51 +0100

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

---

From: Peter Schoenmaker <[email-masked]>
Date: Mon, 31 Dec 2007 10:32:50 -0800

Geoff,

Based on the comments from john heasley and yourself we will wait  
until uses raised are resolved.  It appears likely that another rev of  
the draft will be required.

Peter

On Dec 29, 2007, at 10:32 AM, Geoff Huston wrote:

> 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 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
>
> --------------
> How are 32 bit ASNs and IPv6 peers to be encoded in these 32 bit  
> fields? Or does "deprcated" say "it can't'?
>
> Appendix 1, and there does not appear to be any numeric encoding for  
> the states in this RFC
>
>
>
> section 5.9.1
>
> -----------------------
> 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
>
> ------------------------
> 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.
>
>
>> 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 
>> >

---

From: Peter Schoenmaker <[email-masked]>
Date: Mon, 31 Dec 2007 10:28:54 -0800

Geoff,

Peter

---

From: Peter Schoenmaker <[email-masked]>
Date: Mon, 31 Dec 2007 10:32:50 -0800

Geoff,

Peter

---

From: Peter Schoenmaker <[email-masked]>
Date: Mon, 31 Dec 2007 10:28:54 -0800

Geoff,

Peter