Re: [Idr] route-capability explained

Paul Jakma <> Fri, 01 August 2008 13:34 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 6AFE73A6938; Fri, 1 Aug 2008 06:34:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEEBF3A6938; Fri, 1 Aug 2008 06:34:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RV1tGqEut7PG; Fri, 1 Aug 2008 06:34:43 -0700 (PDT)
Received: from ( [IPv6:2001:770:100:8::2]) by (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 (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 <>
X-X-Sender: paul@localhost.localdomain
To: Samita Chakrabarti <>
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)
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 ( [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
X-Virus-Status: Clean
Cc: Inter-Domain Routing List <>,
Subject: Re: [Idr] route-capability explained
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"

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.

Paul Jakma	Key ID: 64A2FF6A
Chewing gum on /dev/sd3c
Idr mailing list