IETF Logo Mail Archive

Re: [Idr] route-capability explained

Paul Jakma <paul@clubi.ie> Mon, 04 August 2008 19:02 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 6FA8A3A67FA; Mon, 4 Aug 2008 12:02:16 -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 C21123A6A66; Mon, 4 Aug 2008 12:02:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, J_BACKHAIR_55=1]
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 VoSjPVrzf2gH; Mon, 4 Aug 2008 12:02:10 -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 87BCE28C31B; Mon, 4 Aug 2008 12:01:55 -0700 (PDT)
Received: from melandri.gla.jakma.org (IDENT:U2FsdGVkX1+aVjgLfOLUhLEBz/TCviS1QpvRh2K1xX8@melandri.jakma.org [81.168.24.37]) (authenticated bits=0) by hibernia.jakma.org (8.14.2/8.14.2) with ESMTP id m74J2AJq022117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Aug 2008 20:02:19 +0100
Date: Mon, 04 Aug 2008 20:02:10 +0100
From: Paul Jakma <paul@clubi.ie>
X-X-Sender: paul@localhost.localdomain
To: Samita Chakrabarti <samitac@ipinfusion.com>
In-Reply-To: <006101c8f65e$302551d0$97000a0a@samitacD600>
Message-ID: <alpine.LFD.1.10.0808041931110.5059@localhost.localdomain>
References: <000001c8f313$eaa095e0$2b168182@samitacD600> <alpine.LFD.1.10.0808011257360.4279@localhost.localdomain> <006101c8f65e$302551d0$97000a0a@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 [212.17.55.49]); Mon, 04 Aug 2008 20:02:20 +0100 (IST)
X-Virus-Scanned: ClamAV 0.92.1/7936/Mon Aug 4 18:02:06 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 Mon, 4 Aug 2008, Samita Chakrabarti wrote:

> [SC>]  Correct.  You are right about unlikely AS4 speakers without AS4
> extended community support -- eventually that should be the case. But, since
> these two documents are separate, we can only assume and hope that an
> implementation would support both at the same time :-)

Ok.

Yakhov's ext-community is probably best place to address these 
problems, no?

Also, I'd like to ask the IDR WG to adopt his draft as a working 
group document. Some kind of communication issue with the IDR chair 
seems to have prevented this from appearing on the agenda...

;)

> [SC>] Yes. The draft-rekhter-as4octet-ext-community can use the 
> extended-asn-capability defined in RFC4893 and make the 2byte/4byte 
> mapping of ext-community decision accordingly. If it is specified 
> in the document, then the implementations will behave in a 
> consistent manner. In that case, we don't need a different 
> route-capability [as proposed in my draft] message.

Unfortunately, there are already some 4B speakers deployed which do 
not translate. So translation is perhaps not a robust answer.

> [SC>] Simpler mandate would be that no 4byte<->2byte mapping takes 
> place for as4-specific ext-community values and 4B-format can 
> operate with another 4B-format compliant system and 2B-format can 
> work with another 2B-format system. But this will again be totally 
> configuration dependent. This might not be easy for large PE 
> deployment scenarios.

Hmm: The 2B form is universally understood, so that should be used if 
the values allow - no translation needed. Surely?

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
"The great question... which I have not been able to answer... is, `What does
woman want?'"
-- Sigmund Freud
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email