Subject: Re: [GROW] Missing things in the current MRT draft

From: Erik Romijn <[email-masked]>
Date: Fri, 05 Mar 2010 11:55:50 +0100

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

---

From: Larry Blunk <[email-masked]>
Date: Mon, 08 Mar 2010 17:53:16 -0500

> that, or changing it for AS numbers and IP addresses.

     I rethought things a bit and decided that it what
would probably be best to simply add 2 new subtypes
to make it perfectly clear that the messages were locally
generated.    It wasn't as bad as I thought since it only
affected the BGP4MP_MESSAGE and BGP4MP_MESSAGE_AS4
types.   I think this will avoid potential confusion (although
it  will require implementations to make a modest update to
support).

> the peer it was received from had AS4 capabilities".

  Okay, I've added this text.

 -Larry

---

From: Paul Francis <[email-masked]>
Date: Thu, 11 Mar 2010 08:39:28 +0100

Hi Gang,

I made a mistake submitting the new versions of the base VA and 
auto-config drafts...I posted on time, but didn't realize that the IETF 
submission process also requires you to respond to the authentication 
emails on time.

Anyway, the two that failed the deadline are attached here, and I'll post 
as soon as the submission window opens again.  A third draft was submitted 
successfully, and is at 
http://tools.ietf.org/html/draft-ietf-grow-simple-va-00.

A quick explanation:

There are no new mechanisms in these drafts.  Rather there is a 
consolidation of drafts and an overall simplification.  Namely:

1.  Called out the simple edge-core deployment as a stand-alone draft, 
since this is much simpler than full VA and adequate for many if not most 
cases.
2.  Folded the tunneling drafts into the main draft (and removed all 
tunneling types except LSPs, and inner labels over either LSPs or IP).
3.  Removed all auto-config mechanisms except the "can suppress", in large 
part because Huawei is implementing this.

At this point, I would say that the drafts are essentially finished 
pending lessons learned from implementation and deployment. 

Thanks, 

PF