Re: [Idr] Comments on RFC4893

"Kalpesh Zinjuwadia" <kzinjuwadia@force10networks.com> Fri, 01 February 2008 20:27 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: ietfarch-idr-archive@core3.amsl.com
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A996B28C33C; Fri, 1 Feb 2008 12:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8OdAb+XjNnv; Fri, 1 Feb 2008 12:27:38 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43AF528C24D; Fri, 1 Feb 2008 12:27:38 -0800 (PST)
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DC9228C1D3 for <idr@core3.amsl.com>; Fri, 1 Feb 2008 12:27:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qekeRJXH9jF for <idr@core3.amsl.com>; Fri, 1 Feb 2008 12:27:35 -0800 (PST)
Received: from mx.force10networks.com (corp.force10networks.com [64.186.164.204]) by core3.amsl.com (Postfix) with ESMTP id AB7F328C246 for <idr@ietf.org>; Fri, 1 Feb 2008 12:27:35 -0800 (PST)
Received: from EXCH-CLUSTER-03.force10networks.com ([10.11.0.53]) by mx.force10networks.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Feb 2008 12:28:33 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 01 Feb 2008 12:28:33 -0800
Message-ID: <44ED058B21DF294ABE394CABE5C1B52101303B07@EXCH-CLUSTER-03.force10networks.com>
In-Reply-To: <001401c8650b$e8a39760$9d000a0a@samitacD600>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] Comments on RFC4893
Thread-Index: AchkfJnFg0bX62edRpC+ThO14/0EDgAB9ayQACBsYzAAAi4IsA==
References: <002f01c8647c$9dafb700$9d000a0a@samitacD600> <44ED058B21DF294ABE394CABE5C1B52102775B3B@EXCH-CLUSTER-03.force10networks.com> <001401c8650b$e8a39760$9d000a0a@samitacD600>
From: Kalpesh Zinjuwadia <kzinjuwadia@force10networks.com>
To: Samita Chakrabarti <samitac@ipinfusion.com>, idr@ietf.org, quaizar.vohra@gmail.com, enkechen@cisco.com
X-OriginalArrivalTime: 01 Feb 2008 20:28:33.0345 (UTC) FILETIME=[03D8D310:01C86511]
Subject: Re: [Idr] Comments on RFC4893
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Comments inline.

Thanks,
Kalpesh

-----Original Message-----
From: Samita Chakrabarti [mailto:samitac@ipinfusion.com] 
Sent: Friday, February 01, 2008 11:52 AM
To: Kalpesh Zinjuwadia; idr@ietf.org; quaizar.vohra@gmail.com;
enkechen@cisco.com
Cc: 'Samita Chakrabarti'
Subject: RE: [Idr] Comments on RFC4893

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
>ASN
>it uses the
>   2 byte ASN in the "My ASN" field of OPEN message. If the BGP speaker
>has
>a 4 byte
>   non-mappable AS number, then it  uses AS_TRANS in "My ASN" field of
>OPEN
>message.
>2) Receiving OPEN message: If a NEW BGP speaker receives a OPEN message
>with
>extended ASN
>   capability, then it ignores the "My ASN" field of OPEN message and
>uses
>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>] 
[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>> I don't think there is any ambiguity in RFC for this. Can
you elaborate what's not clear to you?



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>] 
[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.

<<Kalpesh>> BGP speaker will only check for it's local AS in the
received AS-PATH and doesn't worry about multiple occurrence of other
ASes. Pl go thru RFC 4271, sec 9.1.2, 3rd para on pg 78.

>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
>2-byte-mappable
>4byte ASN, it
>           SHOULD use the 2 byte ASN in the "My ASN field" for OPEN
>message.
>     2) The NEW BGP with non-mappable 4byte ASN SHOULD not peer with
OLD
>BGP
>speaker;
>           this can easily produce routing loop or loss of ASN value in
>the
>PATH.
>
>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.
>
>
[SC>] 
      Please see the previous example  of R1-R2-R3-R4 scenario.

<<Kalpesh>> My previous comment should clarify your doubt.

>
>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.
>
>
[SC>] 
 
Yes. Again the RFC needs more clarification here, as well. 

<<Kalpesh>> Pl elaborate if you see any ambiguity here.

>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.
[SC>] 
[SC>] 
      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
>about
>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>] 
[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>] 
[SC>] This is also subject to interpretation in the RFC.

<<Kalpesh>> I think "truly 4-octet ASN" always means same in RFC. Do you
notice different interpretation in RFC?

>
>Clarification 5
>===================
>
>Should the NEW BGP speaker send a NOTIFICATION with error code =2 and
>subcode=7
>(unsupported capability) when it receives a OPEN message with AS_TRANS
>but
>without
>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
>dependent.
>
[SC>] 
[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.

<<Kalpesh>> Again, the behavior is implementation dependent.
-Samita


_______________________________________________
Idr mailing list
Idr@ietf.org
http://www.ietf.org/mailman/listinfo/idr