Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus (Pedro Roque Marques)

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

Pedro

Answers in-line.

Regards
Martin
[email-masked]

Message: 2
Date: Sat, 22 Apr 2006 19:33:26 -0700
From: Pedro Roque Marques <[email-masked]>
Subject: Re: draft-kulmala-l3vpn-interas-option-d-02 consensus
To: Rick Wilder <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Rick Wilder wrote:
> 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? 
> 

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).

MH: True - but RFC4364 does not describe using VRFs in option 'b'. I
think that it is a long shot to say that importing RTs within a VRF on
an ASBR is equivalent to 'option 'a' capabilities. In option 'b', RT and
RD values are not advertised per ASBR VRF, rather they are advertised
from PE to PE - a major difference. I appreciate you could change RT
values on a per peer basis (depending on vendor support), but again that
is nothing to do with option 'a's ability to generate VPN-IPv4 routes
per VRF. Also, traffic filtering capabilities are not equivalent to
option 'a'. There is no sub-interface on which to apply ACLs per VPN in
option 'b'  

 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.

MH: Fair comment, will take a look at being more specific. 

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.

MH: In addition to my first answer, options 'b' and 'c' DO NOT allow for
per VRF exports at an ASBR. Further, option 'c' does not allow per VRF
route filtering at an AS border. 

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.

MH: There is an attempt at elaborating on the problem statement further
in the document (section 9 - comparison of inter-AS options).

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 ?

MH: Have pasted the whole paragraph below. If the ASBR is also a PE,
then a separate IPV4 peer would be configured within a VRF context. In
that case, routes would be advertised to the CE neighbour. The statement
is meant for 'global' routing context neighbors.

'Routes received from internal or external peers that are imported 
   into ASBR VRFs SHOULD NOT be readvertised to any BGP neighbors. 
   Routes that are not imported into VRFs but are installed in the 
   ASBR's global routing table MAY be readvertised using existing Option

   'B' techniques as described in the Multi-AS section of [RFC4364]. The

   ASBR MUST be equipped with RT based filtering mechanisms that 
   explicitly permit all or a subset of such RT values to be 
   readvertised to its neighbors.  '

The reason for this statement is to allow an ASBR to operate option 'b'
and 'd' concurrently on the same ASBR. In option 'd', an imported route
is readvertised via an export statement within the same VRF - a major
difference to option 'b'. You could in addition run option 'b' on the
box by turning on a knob and disabling bgp route target filtering, but
have to be careful to not readvertise the same route twice via some
careful route mapping as the consequences could be nasty...

Regards and thanks for the comments,

Martin

------------------------------

_______________________________________________
L3vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l3vpn

End of L3vpn Digest, Vol 24, Issue 10
*************************************

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 25 Apr 2006 10:16:55 -0700

Martin Halstead wrote:

> an ASBR is equivalent to 'option 'a' capabilities.

Martin,
There is no standardization effort required to be able to use per VRF 
routing and traffic policies with "option b)". This draft should start 
by admitting that. This has been demonstrated in deployment.

> In option 'b', RT and
> from PE to PE - a major difference. 

I'm sorry but why does that matter ?

I'd like to start by understanding what problem you are trying to 
solve... that would allow us to discuss if there are other alternatives 
to solving that problem and which tradeoffs are there. A comment of 
"values are not advertised per VRF" is really hard to understand without 
such context.

>I appreciate you could change RT
> per VRF.

I really don't understand what you mean by "ability to generate routes 
per VRF"...

> Also, traffic filtering capabilities are not equivalent to

Why does that matter ? what are you trying to accomplish ?

> per VRF exports at an ASBR.

What do you mean by per VRF exports ? If you mean applying BGP export 
policy it is evident that one can achieve this given the knowledge of 
which RTs correspond to which VRF.
> is meant for 'global' routing context neighbors.

This illustrates the point i was making about the draft not containing a 
detailed enough description of protocol mechanisms. There are 
conflicting statements regarding protocol behavior. This is not a 
document that is ready for WG status imho.

   Pedro.