Re: [Idr] Comments on RFC4893

"Samita Chakrabarti" <> Fri, 01 February 2008 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DEE53A697F; Fri, 1 Feb 2008 11:50:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1QzuLhOYZebC; Fri, 1 Feb 2008 11:50:44 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 12FCE3A6978; Fri, 1 Feb 2008 11:50:44 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C35D3A6888 for <>; Fri, 1 Feb 2008 11:50:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ErUhtaxcfRux for <>; Fri, 1 Feb 2008 11:50:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id AD8023A6886 for <>; Fri, 1 Feb 2008 11:50:41 -0800 (PST)
Received: from samitacD600 ([]) by (8.11.6/8.11.6) with ESMTP id m11Jpi414292; Fri, 1 Feb 2008 11:51:44 -0800
From: Samita Chakrabarti <>
To: 'Kalpesh Zinjuwadia' <>,,,
References: <002f01c8647c$9dafb700$9d000a0a@samitacD600> <>
Date: Fri, 01 Feb 2008 11:51:54 -0800
Message-ID: <001401c8650b$e8a39760$9d000a0a@samitacD600>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AchkfJnFg0bX62edRpC+ThO14/0EDgAB9ayQACBsYzA=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <>
Subject: Re: [Idr] Comments on RFC4893
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Kalpesh,

Thanks for the response. Please see in-line.

>Clarification 1:
>In section 4 it describes the interaction between NEW BGP speakers; it
>discusses the UPDATE
>message processing with
>NEW and OLD BGP speakers. But  it does not discuss the OPEN message
>send/recv in details;
>the following cases need clarification:
>1) NEW BGP speakers interactions: If the BGP speaker has a 2byte unique
>it uses the
>   2 byte ASN in the "My ASN" field of OPEN message. If the BGP speaker
>a 4 byte
>   non-mappable AS number, then it  uses AS_TRANS in "My ASN" field of
>2) Receiving OPEN message: If a NEW BGP speaker receives a OPEN message
>extended ASN
>   capability, then it ignores the "My ASN" field of OPEN message and
>the 4byte ASN
>   value in the capability message. [ this will clarify the
>   ambiguity  and increases interoperability ]
>Kalpesh> NEW BGP speaker (R1) will always put the 4-BYTE-AS capability
>in the Open message, unless it's acting as OLD. "My AS" will contain the
>actual AS if it's mappable to 2-byte field; else it will contain
>AS-TRANS. OLD speaker (R2) will use AS-TRANS as R1's AS.
[SC>]  Yes. We are saying the same thing. But the point is that the RFC is
not very clear about sending/receiving "My ASN" value in the OPEN message
and it should be clarified.

Kalpesh> NEW speaker
>(R3) will use the ASN in the capability as R1's AS. R3 may also put
>sanity check such as "My AS" can be AS-TRANS iff R1's actual ASN is
>4-byte non-mappable.
[SC>] What is your topology in this example? Is R3 peering with both R1 and
R2?  The question is should we allow R2 to peer with non-mappable ASN BGP
speaker in the following scenario?

    R1 (ASN=65566)-----R2(100)-------------R3(77777)-----R4(400)
     NEW              OLD BGP               NEW            OLD BGP
In this example, R4 finds loop in ASN path, because it can only understand
2byte AS_TRANS.  R4 sees <23456, 100, 23456> in ASN PATH.

The RFC in section 4.2.1 is very liberal about the specification; I think,
the RFC at least should recommend some valid scenarios and discourage things
that can cause interoperability or confusion in the BGP path.

>a OLD BGP are NEW with 4byte ASN). I assume that the RFC recommends :
>     1)  If the NEW BGP speaker has a unique 2 byte ASN or a
>4byte ASN, it
>           SHOULD use the 2 byte ASN in the "My ASN field" for OPEN
>     2) The NEW BGP with non-mappable 4byte ASN SHOULD not peer with OLD
>           this can easily produce routing loop or loss of ASN value in
>Kalpesh> I don't know if I understand your question completely. However,
>I don't think RFC puts any restriction on NEW BGP speaker with
>non-mappable 4-byte ASN to communicate with OLD & NEW BGP speakers at
>the same time. In your case, NEW speaker w/ ASN 65666 will communicate
>differently with NEW speaker w/ ASN 5000 and OLD speaker w/ ASN 101.
>Each speaker pair should be is treated independently and not confused
>with others.
      Please see the previous example  of R1-R2-R3-R4 scenario.

>Kalpesh> NEW1 & NEW2 will exchange update with 4-byte AS-PATH & AGGR
>attributes. However, when NEW2 advertises update to OLD2, it will split
>4-byte AS-PATH attribute into 2-byte AS-PATH and 4-byte AS4-PATH using
>the steps mentioned in RFC. Same goes for AGGR attribute. OLD2 & OLD3
>will treat AS4-PATH & AS4-AGGR attributes as unknown opt-trans and pass
>it further.
Yes. Again the RFC needs more clarification here, as well. 

>Clarification 4
>When the NEW BGP speaker has a non-mappable 4byte unique AS number and
>it is
>peering with an OLD BGP
>speaker, only then should it use AS_TRANS in AS_PATH and a corresponding
>AS4_PATH 4byte
> AS number?
>This should simplify reconstructing the AS number from both AS_PATH and
>AS4_PATH and also
>is in sync with AS4_AGGREGATOR processing as described in the RFC.
>Kalpesh> NEW speaker will generate AS4-PATH only if the AS-PATH to be
>sent to OLD peer has at least 1 non-mappable 4-byte ASN. Hence, a NEW
>speaker with 2-byte mappable AS may generate AS4-PATH if reqd.
      OK. It is now clarified. 
>section 4.2.2:
>"When communicating with an OLD BGP speaker, a NEW speaker MUST send
>   the AS path information in the AS_PATH attribute encoded with 2-octet
>   AS numbers.  The NEW speaker MUST also send the AS path information
>   in the AS4_PATH attribute (encoded with 4-octet AS numbers), except
>   for the case where the entire AS path information is composed of 2-
>   octet AS numbers only.  In this case, the NEW speaker SHOULD NOT send
>   the AS4_PATH attribute."
>The above rule is confusing from the implementation perspective. How
>making it simple by doing the same thing as AS_AGGREGATOR (as follows) ?
>  "Similarly, if the NEW speaker has to send the AGGREGATOR attribute,
>   and if the aggregating Autonomous System's AS number is truly 4-
>   octets, then the speaker constructs the AS4_AGGREGATOR attributes by
>   taking the attribute length and attribute value from the AGGREGATOR
>   attribute and placing them into the attribute length and attribute
>   value of the AS4_AGGREGATOR attribute, and sets the AS number field
>   in the existing AGGREGATOR attribute to the reserved AS number,
>   AS_TRANS.  Note that if the AS number is 2-octets only, then the
>   AS4_AGGREGATOR attribute SHOULD NOT be sent."
>I assume that "truly 4-octet" means it is higher than 65535.
>Kalpesh> I think conditions mentioned for generating AS4-PATH & AS4-AGGR
>are inherently same. For AS-PATH all ASN in it are considered for AGGR
>the aggregating ASN is considered.
[SC>]  Conditions for AS4_PATH and AS4_AGGR should be the same; again this
part is a bit unclear in the RFC.

>Yes "truly 4-octet" ASN means ASN > 65535.
[SC>] This is also subject to interpretation in the RFC.

>Clarification 5
>Should the NEW BGP speaker send a NOTIFICATION with error code =2 and
>(unsupported capability) when it receives a OPEN message with AS_TRANS
>any corresponding capability message ?
>Kalpesh> RFC doesn't discuss how NEW speaker should behave when OLD
>speaker uses AS-TRANS in "My AS" field. Behavior is implementation
[SC>] Please note the above situation can also happen from a faulty or
misbehaving NEW BGP speaker with non-mappable 4b ASN. Since AS_TRANS is a
reserved value and not assigned to anyone, if the OLD BGP speaker somehow
uses this value in the OPEN message, it must not be accepted either.
IMHO, this NOTIFICATION case is a valid one and should be documented.


Idr mailing list