Subject: Re: [Idr] Clarification points for rfc4893-bis

From: Enke Chen <[email-masked]>
Date: Wed, 15 Apr 2009 16:27:42 -0700

Hi, Samita:

Thanks for your comments and suggestion. Please see my replies inlined.

Samita Chakrabarti wrote:
>
> Hi Enke,
>
> This is a follow-up from the idr meeting comments. I’d like to thank 
> you for your kind consideration in taking into some of the comments 
> addressed in draft-chakrabarti-idr-rfc4893-mod.
>
> Here are few cases that I propose to clarify in the next revision of 
> the rfc4893-bis and I think these will be helpful for new readers and 
> implementers especially considering the fact that 2byte ASes and 4byte 
> ASes are going to co-exist for sometime.
>
> Clarification 1:
>
> Section 3: “My AS Number” field
>
> Currently it says:
>
> " and "We denote this special AS number as AS_TRANS for ease of
>
> description in the rest of this specification. This AS number is
>
> also placed in the "My Autonomous System" field of the OPEN message
>
> originated by a NEW BGP speaker, if the speaker does not have a
>
> (globally unique) 2-octet AS number."
>
>    The clarification would be useful : 1) When 4-byte AS number capability message is
>    present and the receiver is able to process the capability message,
>    should it ignore the AS number field in the OPEN message and use the AS-number present in the capability message?

How about the following addition in Section 4.1:

When a NEW BGP speaker processes an OPEN message from another NEW BGP
speaker, it MUST take the Autonomous System number encoded in the 
Capability Value
field of the Capability in lieu of the "My Autonomous System" field of 
the OPEN message.

>  
>  
> Clarification 2:
> Minor nit: "truly 4-octet" should be defined as a quantity higher
>    than 65535.

Will replace "truly 4-octet" by "non-mappable 4-octet AS number".

>  
>    Should the NEW BGP speaker send a NOTIFICATION message when it
>    receives a OPEN message with AS_TRANS but without any corresponding
>    capability message ?  Note that although AS_TRANS(23456) is a
>    reserved number now, it is still possible to receive a OPEN message
>    with AS_TRANS value from an OLD BGP speaker or from a ill-behaving
>    NEW BGP speaker.
>  
> Proposal for a NOTIFICATION message
>  
>    When two BGP speakers correspond with each other by sending AS_TRANS
>    value in the 'My AS number' field, then the OPEN message MUST contain
>    the 4-octet AS number capability option.  If the 4-octet capability
>    is missing in OPEN message where the 'My AS Number' field contains
>    AS_TRANS value, a NEW BGP speaker-receiver SHOULD send a notification
>    with code=2, subcode=2 [bad peer AS] to the sender of the OPEN
>    message.

We could be at the risk of over-specifying here. (Note that RFC 4271 
does not cover the possible misuse of reserved / non-allocated AS numbers.)

>  
>  
>
> Clarification on section 6 (Transition)
>
> How about some more text on PE-CE cases? Especially the AS_OVERRIDE 
> issue as identified in
>
> http://www.ietf.org/proceedings/08mar/slides/idr-4/idr-4.htm [ Please 
> check-out slide 11]
>

As AS_OVERRIDE is something that is not covered in RFC 4271, I think 
that we should leave it out due to the lack of background information / 
reference.

-- Enke

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Fri, 17 Apr 2009 15:07:12 -0700

Hi Enke,

> speaker, it MUST take the Autonomous System number encoded in the
Capability
> Value field of the Capability in lieu of the "My Autonomous System" field
of
> the OPEN message.

[SC>]  Looks good. 

> We could be at the risk of over-specifying here. (Note that RFC 4271 does
> not cover the possible misuse of reserved / non-allocated AS numbers.)
[SC>] 
[SC>]  I see that RFC4271 does not cover the misuse of
reserved/non-allocated AS numbers and some deployments internally might be
using AS_TRANS number in the OLD BGP speakers. But then at that time there
was no concept of 4byte AS number either since RFC4271 assumes 2-byte AS
value. 
The NEW BGP speakers anyway are not supposed to send/receive AS_TRANS in "My
ASN" without the 4-byte capability - hence a notification  makes sense
during the OPEN message negotiation. It would be useful from debugging
purpose in the field during transition.

> As AS_OVERRIDE is something that is not covered in RFC 4271, I think that
we
> should leave it out due to the lack of background information / reference.
> 

[SC>] We can always add some text for information in Appendix section if it
does not belong to the body. Although it is not part of the main BGP(RFC
4271) specification, it will help the implementers to provide as wide
spectrum as possible to plan for the implementation change.

Thanks very much for your consideration.

-Samita

---

From: Enke Chen <[email-masked]>
Date: Fri, 17 Apr 2009 15:37:06 -0700

Hi, Samita:

> Hi Enke,
[snip]

> purpose in the field during transition.

We can not mandate or change what an OLD speaker does :-)

The revised text in draft-ietf-idr-rfc4893bis-00.txt makes it explicit 
that "My ASN" filed does not matter when the capability is carried in 
the OPEN:

----------------------------------------------------------------------
4.1. Interaction Between NEW BGP Speakers

A BGP speaker that supports 4-octet Autonomous System numbers SHOULD
advertise this to its peers using the BGP Capability Advertisements.
The Autonomous System number of the BGP speaker MUST be carried in
the capability value field of the advertised capability.

When a NEW BGP speaker processes an OPEN message from another NEW BGP
speaker, it MUST use the Autonomous System number encoded in the
Capability Value field of the Capability in lieu of the "My
Autonomous System" field of the OPEN message.
-----------------------------------------------------------------------

> spectrum as possible to plan for the implementation change.

I am in favor of leaving the "exotic" features such as AS_OVERRIDE, 
AS_PREPEND, etc. to the implementation. Clearly an implementation needs 
to make the necessary changes when the AS number is enlarged.

Thanks. -- Enke