Subject: draft-kulmala-l3vpn-interas-option-d-02 consensus

From: Rick Wilder <[email-masked]>
Date: Thu, 20 Apr 2006 13:36:31 -0700 (PDT)

Dear Working Group Participants,

May we please have more active response on the question of whether 
draft-kulmala-l3vpn-interas-option-d-02 should become a working group
document? 

We need more active response on this issue to determine a consensus. Intention to
implement from equipment vendors and intention to deploy from service providers would be
espcially helpful. Please speak up now.

Thanks,

Rick and Ron

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 20 Apr 2006 13:43:56 -0700 (PDT)

Hi Rick,

> draft-kulmala-l3vpn-interas-option-d-02 should become a working group

No.

rahul

---

From: Pedro Roque Marques <[email-masked]>
Date: Sat, 22 Apr 2006 19:33:26 -0700

> draft-kulmala-l3vpn-interas-option-d-02 should become a working group

I believe it should not.

 From a problem statement analysis it seems to ignore the existence of 
option b) deployments that perform per VRF routing policy and traffic 
filtering decisions (usually associated with option a) capabilities).

 From a solution point of view, it seems to me that the proposal is not 
explained in a detailed enough manner that one can assess the protocol 
and/or implementation changes being proposed.

I also find the document very hard to read. I'd like to see a step by 
step analysis of the protocol mechanisms that are being introduced and 
or modified. I don't see this in the document... my personal impression 
is that it "hand waves" around some pretty complex implementation 
consequences of what is being proposed.

Specific comments:

    Option 'A' inherently allows per VRF route readvertisement
    import/export policy at the AS border. Options 'B' and 'C' do not
    have this attribute, but remove Option 'A's requirement for per VRF
    [...]

==>
This is not factually correct in my opinion. Given the knowledge of 
import targets per VRF, option b or c allow one to specific import and 
export route policies. The draft does call per per VRF configuration.

This appears to be the problem statement in the document. It describes a 
set of mechanisms but i'd like to understand what is the problem so that 
we can evaluate other potential solutions.

4.1.1. Route Advertisement - Private interface forwarding

    VPN-IPv4 prefixes are advertised from ASBR1 to ASBR2 via a BGP
    session that is in the global routing table context. This implies
    that the advertised next-hop address is also reachable via the global
    routing table context. In order to force traffic to be forwarded via
    interface 'a', VRF forwarding entries need to be installed using a
    next-hop address that is in VRF3's (which resides on ASBR2) routing
    context.

==> The concept of having route advertisements in one instance refer to 
address in a separate instance needs to be looked at very carefully. It 
is unclear to me how the addressing realm for this next-hop is to be 
determined by the receiver, for instance.
A next-hop on an ebgp session is expected to be directly connected to 
the peering interface. There is no discussion of the protocol changes 
that would be required to make this happen.

5.1. Inter-AS IP VPN Route Distribution

    Routes received from internal or external peers that are imported
    into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors.
==>
Why ? what happens if the ASBR is also a PE ?

regards,
   Pedro.