Re: draft-kulmala-l3vpn-interas-option-d-02 (Yakov Rekhter)

"Martin Halstead" <mhalstead@nexagent.com> Tue, 25 April 2006 11:04 UTC

Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 25 Apr 2006 12:03:48 +0100
Message-ID: <B2B4D3618441D941B811329A672FD64E01087598@THHS2EXBE2X.hostedservice2.net>
Thread-Topic: draft-kulmala-l3vpn-interas-option-d-02 (Yakov Rekhter)
Thread-Index: AcZm7wirYlzwdbNvRg696YrtbqWz9gAjpFhA
From: Martin Halstead <mhalstead@nexagent.com>
To: l3vpn@ietf.org
Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 (Yakov Rekhter)
Precedence: list
Errors-To: l3vpn-bounces@ietf.org

   1. Re: draft-kulmala-l3vpn-interas-option-d-02  (Yakov Rekhter)

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.

MH: If the RT constrain is generated within an AS (a PE), then it would
be 'rewritten' at the ASBR. An ASBR running option 'd' would advertise a
'new' RT constrain NLRI by the process of generating VPN-IPv4 prefixes
within per VPN VRFs at the ASBR. The constrain draft does seem to be
geared towards RFC4364 multi-AS option 'c' though as in option 'b', IP
NLRI would be rewritten by the ASBR as well?

Re: draft-kulmala-l3vpn-interas-option-d-02 (Yako… Martin Halstead