Re: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt

"Samita Chakrabarti" <samitac@ipinfusion.com> Sat, 08 March 2008 14:18 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 1D37F28D89A; Sat, 8 Mar 2008 06:18:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.835
X-Spam-Level:
X-Spam-Status: No, score=-99.835 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_BACKHAIR_55=1, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UT2GzVi85jeo; Sat, 8 Mar 2008 06:18:49 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63F0328DCDE; Sat, 8 Mar 2008 05:45:44 -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 7C49F3A6FD6 for <idr@core3.amsl.com>; Sat, 8 Mar 2008 05:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSJZ7Gwnb+1I for <idr@core3.amsl.com>; Sat, 8 Mar 2008 05:45:27 -0800 (PST)
Received: from gateway.ipinfusion.com (unknown [65.223.109.2]) by core3.amsl.com (Postfix) with ESMTP id CD788294109 for <idr@ietf.org>; Fri, 7 Mar 2008 18:53:48 -0800 (PST)
Received: from samitacD600 ([10.10.0.169]) by gateway.ipinfusion.com (8.11.6/8.11.6) with ESMTP id m282qwc14643; Fri, 7 Mar 2008 18:52:58 -0800
From: Samita Chakrabarti <samitac@ipinfusion.com>
To: 'Geoff Huston' <gih@apnic.net>
References: <47CA3B8D.9060304@cisco.com> <005b01c87e67$926edf10$89000a0a@samitacD600> <47CE2AEC.3050009@apnic.net> <004501c87f27$0fab5d40$89000a0a@samitacD600> <47CF6251.8010608@apnic.net>
Date: Fri, 07 Mar 2008 18:53:04 -0800
Message-ID: <009b01c880c7$8b6d1c10$a9000a0a@samitacD600>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: Ach/OMRm5SiM+nczQHaPIxMfgGFmEwBg3O3g
In-Reply-To: <47CF6251.8010608@apnic.net>
Cc: 'idr' <idr@ietf.org>
Subject: Re: [Idr] comments on draft-chakrabarti-idr-rfc4893-mod-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://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: <https://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

Please  see below in-line.

>> [SC>]  I did not mean that a BGP speaker would know when the transition
>is
>> over. I mentioned that transition period would be long. During that
>period
>> both AS_PATH and AS4_PATH will exist and the transition border NEW BGP
>> speaker does not need to do 2byte<->4byte AS_PATH, AS_AGGREGATOR
>conversion.
>
>would you care to quantify the overhead of any such conversion?
>
>average AS path length = 3.5
>
>Number of updates per second appears to avers around 3 to 4
[SC>] 
[SC>]  If there is 50+ peering connection then ~200 updates/sec for the
control-plane traffic. But one can argue that this is not worth worrying
about.


>
>I'm sorry but I simply can't see what you think you are saving here
>
>

[SC>]  My concern was more on overloading the AS_PATH data sometimes with
2-bytes and sometimes with 4-bytes values; it is error-prone from
programming point of view. 

But as I noted below that I understand the case is closed now. No point
arguing now.

>>
>> But, Enke mentions that similar proposal was discussed before and not
>> adopted. In that case I'll not push for this particular proposal. But it
>is
>> true that RFC 4893 is overloading AS_PATH sometimes with 2byte and
>sometimes
>> with 4bytes values, the NEW speaker will have to carefully take care of
>this
>> situation. It could lead into error-prone implementations.
>
>Yes, this was discussed about 3 years ago as well that the AS Path does
>not implicitly say whether the elements within the path are 2 or 4
>bytes. The consensus outcome of the WG was to run with what is in
>RFC4893. I think you you want to dredge over this ground again you are
>going to have to come up with hard facts, rather than another rerun of
>supposition and opinion of what "could" happen.
>
<snip>

>> [SC>] What is the objection against introducing a notification message to
>> the OLD BGP speaker from a NEW BGP speaker when it receives AS_TRANS in
>OPEN
>> message without AS4 capability?  This is quite useful for transition.
>
>Lets see now what you are saying:
>
>I configure to peer with AS 1. In the session the peer sends me an open
>message with a My AS number of 23456 without the capability to do 32 bit
>AS numbers - i.e. my peer is saying that it really is AS 23456. I
>terminate the session and spit out the diag that this is not the
>neighbor I expect to talk to.
>
>Now the only way this will work is that I configure AS 23456 as my
>neighbor and you assert that you are AS23456. Fine.
>
>Why would this happen ?
>
>a) I am an OLD speaker and you have a non-mappable 32 bit AS number and
>you are a NEW BGP speaker. Well in this case this is precisely what is
>MEANT to happen
>
>b) You and I agree that you really want to be AS23456. Well aside from
>the observation that you and I are demonstrating some level of ignorance
>about Standards and the IANA registry, no actual harm is being done.
>
[SC>]  The ignorance of standards and specification in the field is the real
concern - I am not trying to address any algorithm issue here.

>So what is the problem you think that you are trying to solve here?
[SC>] 

[SC>] Human error or inconsistency of the implementation due to lack of
clarity in the specification - is the problem I am trying to address here.

Assuming your example, above:

  R1> router bgp 77777
    Router> neighbor 3.3.3.3 remote-as 23456  <---- The correct new BGP
implementation should not allow this command to succeed. But it is possible
because the RFC explicitly does not prohibit that, as you mentioned.

On R2> router bgp 23456  [ OLD BGP and they have been doing this incorrectly
due to ignorance ]

OLD BGP sends OPEN message with My ASN = 23456, but there is no AS4
capability.
At this point, the NEW BGP should reject the OPEN and does not peer.
RFC4271 provides Notification type 2 subtype 2 (bad AS); if new BGP
implementation could use that NOTIFICATION before closing TCP, the debug
info could help the poor IT person who does not understand the details we
discuss here in IETF.

Here is a reference based on some real experience from the field about
common mistakes in peering configuration; it might look silly but it can
save customer calls($$) if the debug message shows some hint.
http://www.nanog.org/mtg-0802/presentations/PSmith_BGP.pdf - checkout slide
30
     

Thanks,
-Samita
  



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