Re: draft-kulmala-l3vpn-interas-option-d-02

Yakov Rekhter <yakov@juniper.net> Sun, 23 April 2006 00:42 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXSgY-0004K9-AK; Sat, 22 Apr 2006 20:42:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXSgX-0004K4-6C for l3vpn@ietf.org; Sat, 22 Apr 2006 20:42:45 -0400
Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXSgV-0006Pg-Rr for l3vpn@ietf.org; Sat, 22 Apr 2006 20:42:45 -0400
Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k3N0gaX98987; Sat, 22 Apr 2006 17:42:36 -0700 (PDT) (envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k3N0gU532494; Sat, 22 Apr 2006 17:42:30 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200604230042.k3N0gU532494@merlot.juniper.net>
To: Martin Halstead <mhalstead@nexagent.com>
In-Reply-To: Your message of "Thu, 20 Apr 2006 11:33:02 BST." <B2B4D3618441D941B811329A672FD64E01032311@THHS2EXBE2X.hostedservice2.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <25548.1145752950.1@juniper.net>
Date: Sat, 22 Apr 2006 17:42:30 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: l3vpn@ietf.org
Subject: Re: draft-kulmala-l3vpn-interas-option-d-02
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: l3vpn.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
Errors-To: l3vpn-bounces@ietf.org

Martin,

> Ron
> 
> You make a good point - I think that 'draft-ietf-l3vpn-rt-constrain'
> does play well with 'option d' as a means to restrict VPN route updates
> to interested parties only. This could apply when a single ASBR is
> peered with more than one ASBR (in my opinion a very good thing). The
> distribution graphs (and associated policies) would then sit between
> peered ASBRs, rather than across ASes as described in the 'constrain'
> draft.

Could you please elaborate on "does play well". Specifically, would
option d require to rewrite NLRI carried in RT constrains ?

Yakov.

> 
> BTW - I think that in the case of L3 VPN, the 'constrain' draft should
> add that the option is only applicable to multi-AS options 'b' and 'c'
> and by implication will not work with option 'a'.
> 
> Regards
> 
> Martin
> mhalstead@nexagent.com
> 
> -----Original Message-----
> From: Ron Bonica [mailto:rbonica@juniper.net] 
> Sent: 18 April 2006 19:37
> To: Martin Halstead
> Cc: l3vpn@ietf.org
> Subject: Re: draft-kulmala-l3vpn-interas-option-d-02
> 
> Martin,
> 
> BTW, would Option D play well with Constrained VPN Route Distribution (
>                 draft-ietf-l3vpn-rt-constrain)?
> 
>                                 Ron
>