Re: [Idr] route-capability explained

Paul Jakma <paul@clubi.ie> Fri, 01 August 2008 13:34 UTC

Return-Path: <idr-bounces@ietf.org>
X-Original-To: idr-archive@megatron.ietf.org
Delivered-To: ietfarch-idr-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AFE73A6938; Fri, 1 Aug 2008 06:34:45 -0700 (PDT)
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 CEEBF3A6938; Fri, 1 Aug 2008 06:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_24=0.6, NO_RELAYS=-0.001]
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 RV1tGqEut7PG; Fri, 1 Aug 2008 06:34:43 -0700 (PDT)
Received: from hibernia.jakma.org (cl-9.dub-01.ie.sixxs.net [IPv6:2001:770:100:8::2]) by core3.amsl.com (Postfix) with ESMTP id AD1153A67B3; Fri, 1 Aug 2008 06:34:41 -0700 (PDT)
Received: from [2001:770:105:1:213:2ff:fed3:a565] ([IPv6:2001:770:105:1:213:2ff:fed3:a565]) (authenticated bits=0) by hibernia.jakma.org (8.14.2/8.14.2) with ESMTP id m71DYMYA014201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Aug 2008 14:34:25 +0100
Date: Fri, 1 Aug 2008 14:34:51 +0100 (BST)
From: Paul Jakma <paul@clubi.ie>
X-X-Sender: paul@localhost.localdomain
To: Samita Chakrabarti <samitac@ipinfusion.com>
In-Reply-To: <000001c8f313$eaa095e0$2b168182@samitacD600>
Message-ID: <alpine.LFD.1.10.0808011257360.4279@localhost.localdomain>
References: <000001c8f313$eaa095e0$2b168182@samitacD600>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
Mail-Copies-To: paul@jakma.org
X-NSA: al aqsar fluffy jihad cute musharef kittens jet-A1 ear avgas wax ammonium bad qran dog inshallah allah al-akbar martyr iraq hammas hisballah rabin ayatollah korea revolt pelvix mustard gas x-ray british airways washington peroxide cool
MIME-Version: 1.0
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0rc1 (hibernia.jakma.org [IPv6:2001:770:105:1:20e:cff:fe29:df20]); Fri, 01 Aug 2008 14:34:25 +0100 (IST)
X-Virus-Scanned: ClamAV 0.92.1/7909/Fri Aug 1 10:42:09 2008 on hibernia.jakma.org
X-Virus-Status: Clean
Cc: Inter-Domain Routing List <idr@ietf.org>, l3vpn@ietf.org
Subject: Re: [Idr] route-capability explained
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: idr-bounces@ietf.org
Errors-To: idr-bounces@ietf.org

Hi Samita,

On Thu, 31 Jul 2008, Samita Chakrabarti wrote:

> ext-format-A:                                   ext-format-B:
>      X:000000010002                              Y:000100000002
>      X= Type-subtype for AS4
>                                   Y= Type-subtype for regular ext-community
>
> Now PE1 sends ext-format-A to ext-format-B , one can see that 8byte 
> comparison of ext-community will not match. (X and Y are different 
> and value fields are different)

Explained like this, the problem is pretty clear. But...

> At the idr meeting at IETF on Wednesday, we were told, this is 
> operational or implementation issue - not a protocol issue. I agree 
> it is not exactly a protocol issue.

Based on the above, it is :). But...

> But, given that IETF is all about running "interoperable" code across many
> vendors, I strongly believe this issue should be addressed to clarify the
> specification such that there are less issues during the AS4 transition.

This is only a problem in interoperating with 2-byte speakers, right?

(Also with AS4 speakers that don't implement AS4 extended community - 
but such speakers are unlikely to exist, surely?)

> So here are a few alternatives that make sense in my mind:
>
> 1. draft-rekhter-as4octet-ext-community-03.txt can specify handling of
> AS4byte and AS2byte extendend-communities.

A 4-byte speaker could, as a courtesy, translate AS4 extcommunity to 
AS2 when sending to AS2 speakers, where the values fit.

Even simpler: the above draft could make it crystal clear that the 
AS4 ext-com format should be used only where the ASN values require 
it, and should probably also warn against the use of values > 2^16-1 
in some appropriate way.

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Chewing gum on /dev/sd3c
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr