Subject: Re: [GROW] Last call draft-ietf-grow-mrt-09.txt

From: Larry Blunk <[email-masked]>
Date: Tue, 21 Apr 2009 13:41:33 -0400

Ricard Oliveira of UCLA just noticed a discrepancy between
the MRT draft and the quagga and libbgpdump implementations.
The BGP4MP_STATE_CHANGE_AS4 type was added in the -04
version of the MRT draft and defined to have a value of 4.   The
BGP4MP_MESSAGE_AS4 type was assigned a value of 5 in
this draft (it had been orignally named BGP4MP_MESSAGE_32BIT_AS
and had been assigned a value of 4 in earlier drafts).

    The reason the value of the BGP4MP_MESSAGE_AS4
type changed from 4 to 5 is because the BGP4MP_STATE_CHANGE
and BGP4MP_MESSAGE 16-bit AS types are defined as 0 and 1, respectively.
So it seemed reasonable to use the same ordering for the 4 byte
AS versions of these types (bit 2 is set in the 4 byte AS versions,
and clear in the 16-bit AS versions).

   Unfortunately, the libbgpdump and quagga implementations use
the original value of 4 for the BGP4MP_MESSAGE_AS4 type, and
the value of 5 for the BGP4MP_STATE_CHANGE_AS4 type.

   These type codes of been in production for about 2 years with the
RIPE RIS project and Oregon Routeviews just recently
switched to using these as well when it moved to the lastest
Quagga version.

   So, the options would be to update the draft to reflect these
two known implementations, or ask the implementers to update
their code and the archives to update their archived BGP data.
I'm guessing it will be preferable to update the draft, but I'd like to
hear if there are any other implementations out there first.    I did
check the lastest OpenBGPD, and it does not yet support the
AS4 types.

 -Larry Blunk

Peter Schoenmaker wrote:
> Hello,
>
> I would like to issue last call for draft-ietf-grow-mrt-09.txt.  
> Please provide any final comments by March 20th (just before IETF 74 
> San Francisco.)
>
> thanks
>
> peter
>
>
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: February 25, 2009 7:15:01 AM PST
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [GROW] I-D Action:draft-ietf-grow-mrt-09.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>> This draft is a work item of the Global Routing Operations Working 
>> Group of the IETF.
>>
>>
>>     Title           : MRT routing information export format
>>     Author(s)       : L. Blunk, et al.
>>     Filename        : draft-ietf-grow-mrt-09.txt
>>     Pages           : 28
>>     Date            : 2009-02-25
>>
>> This document describes the MRT format for routing information
>> export.  This format was developed in concert with the Multi-threaded
>> Routing Toolkit (MRT) from whence the format takes it name.  The
>> format can be used to export routing protocol messages, state
>> changes, and routing information base contents.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-grow-mrt-09.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> _______________________________________________
>> GROW mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/grow

---

From: Christopher Morrow <[email-masked]>
Date: Tue, 21 Apr 2009 14:33:21 -0400

does this, if it's not materially impacting, fall into something that
gets fixed in IESG comment/fixes?

-Chris

On Tue, Apr 21, 2009 at 1:41 PM, Larry Blunk <[email-masked]> wrote:
>> I would like to issue last call for draft-ietf-grow-mrt-09.txt.  Please
>> provide any final comments by March 20th (just before IETF 74 San
>> Francisco.)
>>
>> thanks
>>
>> peter
>>
>>
>>
>> Begin forwarded message:
>>
>>> This draft is a work item of the Global Routing Operations Working Group
>>> of the IETF.
>>>
>>>

<div><br></div>

---

From: Larry Blunk <[email-masked]>
Date: Wed, 22 Apr 2009 10:29:55 -0400

I would say it's definitely materially impacting.
The I-D tracker still shows the draft as just being
in the I-D Exists state.   So I should just be able to
just spin a new -10 draft and we do another
last call.  Correct?

 -Larry

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 22 Apr 2009 11:10:06 -0400

s'okay by me.

On Wed, Apr 22, 2009 at 10:29 AM, Larry Blunk <[email-masked]> wrote:
>>>>> Group

<div><br></div>

---

From: Paul Francis <[email-masked]>
Date: Fri, 24 Apr 2009 16:57:51 +0200

Gang,

I would like to start the discussion of making Virtual Aggregation, which 
I presented at the GROW meeting in SF, a working group item.

A new version of the document has been posted, which mainly consists of 
minor clarifications from folks who make up an expanded author list 
(Zhang, Jen, and Raszuk).  It is at 
http://www.ietf.org/internet-drafts/draft-francis-intra-va-01.txt.

Note that there are two companion documents associated with this, one each 
on the specifics of MPLS and IP-in-IP tunnels in support of VA.  These 
have not been updated, though we expect them to be soon.  (These are at 
http://tools.ietf.org/id/draft-francis-va-tunnels-mpls-00.txt and 
http://www.ietf.org/internet-drafts/draft-xu-va-tunnels-gre-00.txt 
respectively)

I think that there are mainly two things to discuss:

1.  What additional documentation, if any, is needed (requirements, 
scenarios, MIB, ....)?
2.  What should the status of the produced RFCs be (informational, BCP, 
standard)?

Regarding the first, I do think that a requirements/scenarios document is 
a good idea, but would like to hear opinions.

Regarding the second, there are arguments for and against each type. 
Strictly speaking no protocol changes are needed (except for a case 
involving GRE tunnels with key values, which require an extended 
communities attribute to convey the key info).  So informational or BCP 
could both work.  I'm inclined towards BCP, but would like to hear 
opinions.  Even possibly we could start this as a working group item 
without making this decision just yet.

Thanks all,

PF