Re: [Idr] WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype

Jeffrey Haas <jhaas@pfrc.org> Fri, 21 November 2008 20: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 E38313A6A57; Fri, 21 Nov 2008 12:02:37 -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 221B83A6A0C for <idr@core3.amsl.com>; Fri, 21 Nov 2008 12:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 yUBm-h13ovuS for <idr@core3.amsl.com>; Fri, 21 Nov 2008 12:02:35 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id D69D83A69D9 for <idr@ietf.org>; Fri, 21 Nov 2008 12:00:54 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 67E77244050; Fri, 21 Nov 2008 20:00:53 +0000 (UTC)
Date: Fri, 21 Nov 2008 15:00:53 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: Paul Jakma <paul@clubi.ie>
Message-ID: <20081121200053.GB2615@slice>
References: <200811021527.mA2FR0M34537@magenta.juniper.net> <20081118185010.GD23366@slice> <alpine.LFD.1.10.0811211709020.5059@localhost.localdomain>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <alpine.LFD.1.10.0811211709020.5059@localhost.localdomain>
User-Agent: Mutt/1.5.15+20070412 (2007-04-11)
Cc: Yakov Rekhter <yakov@juniper.net>, idr@ietf.org
Subject: Re: [Idr] WG adoption of draft-dhrao-idr-4octet-extcomm-generic-subtype
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

Paul,

On Fri, Nov 21, 2008 at 05:51:52PM +0000, Paul Jakma wrote:
> 2. Is it deliberate that the non-transitive-bit-set form of 0x2,
>    0x42, is not specified there?

See RFC 4360, Section 2, "transitive bit".  If the top bit is clear, it
is transitive.

> 2. I'm probably being dense, but why does it have a fixed sub-type of
>    4? I.e. isn't the idea to specify a generic AS4 extcomm, and
>    shouldn't it therefore apply to the existing sub-types (rather
>    than a new one)?

The first octet represents the format - 0x04 meaning 4 octet global
administrator field.  The second octet represents the subtype - we're
looking to define this as the 'generic' 4-octet extended community type.
The other subtypes have differing semantics.

(I may be misunderstanding your question.)

Note that there is errata registered on RFC 4360 to an incomplete
refactoring of type 0x02 out of the base draft.

> 3. "Deployment Considerations" / Compatibility:
>
>    Could this section perhaps be rephrased so as to encourage maximum
>    compatibility? E.g. prefer the AS2 form over the AS4, where the
>    values fit? I think this might be important with transitive
>    communities.

I believe that's what we're trying to achieve.  Do you have any
suggested wording changes?  In the case of a 2 octet community that has
a 4 octet community representation, our expectations are they should be
expressed in 2 octet format.  In the situation where they are not, this
should be no different than conflicting sets of communities targeted to
a given AS today.  E.g. if I send community 64512:100 and ext comm:
0x0204:0.64512:200, how is this different from having received
64512:200?  The only clear difference is that in the case of mis-coding,
it's possible the receiving router may not understand the second
community due to lack of 4-octet generic extended community support.

> 4. Some people use communities to send AS values to their peers (e.g.
>    "please blackhole AS-X"). What's going to happen when someone
>    wants to flag some 4-byte-AS to their 4-byte-AS peer? :)
>
>    (I guess this one isn't terribly urgent, but it sounds like we'll
>     need to widen extended-communities one day?)

I think that's probably a much larger issue since not only does this
have semantics, but even 4 octets for the local administrator field
isn't sufficient.  We couldn't encode this in an extended community.
This base issue was one of the motivations of Andrew Lange's flexible
community format.

> Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A

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