Re: [Idr] Clarification points for rfc4893-bis

[Enke Chen <[e-mail]>]

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