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

From: "Martin Halstead" <[email-masked]>
Date: Tue, 25 Apr 2006 12:03:48 +0100

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?