Subject: RE: draft-kulmala-l3vpn-interas-option-d-02 (Yuji KAMITE)

From: "Martin Halstead" <[email-masked]>
Date: Thu, 13 Apr 2006 09:34:21 +0100

Shane

Thank you for interest in this option. Answers in-line:

I also had some questions on this draft, as well, (as an operator 
interested in it):
1)  I understand the goal you're attempting to achieve to reduce the 
number of BGP sessions between ASBR's, but the 'private interface 
forwarding' as detailed in Section 4 is concerning:

    For private interface forwarding, interface 'a' is a VRF attachment
    circuit associated to VRF2 (on ASBR1) and VRF3 (on ASBR2) and is
used
    to transport labeled or native IP VPN traffic between VRF pairs. Per
    VPN routing updates are not advertised across this interface, rather
    interface 'b' carries all ASBR VPN-IPv4 routing updates exported
    from VRF pairs.

Specifically, you are proposing to decouple data-plane forwarding from 
the control-plane, if I understand your proposal correctly.  How do you 
propose to detect data-plane liveness/viability for the VRF-to-VRF AC's 
if there is no routing protocol run across the private AC's between
VRF's?

MH: Indeed, the proposal for this data plane option is to decouple the
control from the data plane, but how that is achieved in practice can be
implementation specific, for example:
- If the link layer supports LMI, there should be no issue.
- If the data plane and control plane are carried across the same
physical layer, again there should be no issue.
- For a link layer that currently lacks LMI, it should be possible to
run an IGP and advertise loopback addresses as next hops. Not ideal I
know, but certainly achievable.

2) In Section 5.2, 'Per VRF Route Limiting'.  The text states that "the 
ASBR SHOULD have the ability to restrict numbers of routes learned on a 
per-VRF and BGP neighbor basis" for both eBGP and iBGP neighbors.  I'm 
unclear how you would attempt to achieve this in practice where only a 
single eBGP session exists across one AC between ASBR's?  Are you 
proposing filtering number of routes inside a VRF based on number of 
prefixes associated with an RD and/or RT to control the number of routes

learned inside a single VRF, since only a single eBGP session exists 
between the ASBR's?

MH: I think that route filtering based on RTs makes a lot of sense for
this option, but don't feel it is appropriate to specify how a vendor
should satisfy this requirement. I think what is important is that
service providers who connect their AS to a third party - be that an
enterprise or another service provider should be able to use similar
mechanisms to prevent overloading their VPN control plane, specifically
at the level of a VPN, rather than an entire peer.     

Again, thanks for the good questions.

Regards

Martin
[email-masked]

Martin Halstead wrote:
> Yugi
> 
> RE: draft-kulmala-l3vpn-interas-option-d-02
> 
> Thanks for posting these questions. I have attempted to respond to
each
> one in-line. 
> 
> Q.1
>  About this solution's advantages. 
>  Is the difference from option A, only to decrease the number of BGP
> peer of ASBRs
>  (especially if "private interface forwarding" is adopted in the
option
> D.) ?  
>  In another way of saying, for SPs who does not have peering number
> problems yet,
>  do they get any special benefits by this?
> 
> MH: Reducing the number of back-to-back peers is indeed a big
motivator
> for this option as a number of operators have expressed concerns
> regarding numbers of BtB peering sessions demanded by 'option a'. In
my
> experience, it is one of the primary reasons for some operators to
> prefer 'option b'. In addition to reducing the number of peers, this
> option (independent of both traffic forwarding methods) allows for RT
> based import/export policies to exist between service provider domains
> that are independent of the RT import/export policies adopted by each
> service provider within their own ASes. This is not achievable by
> 'option a' or indeed 'option b', but useful for a service provider or
> third party organisation wanting to administer VPN routing based on RT
> import/export policy, independent of existing service provider VPN
> membership schemas.    
> 
> Q.2
>  The implementation difference from the existing A/B/C, resides just
in
>  route import/advertisement behavior?   (i.e., no capability
negotiation
> etc.)
> 
> MH: True for this version. There has been discussion about
applicability
> to CsC (which may require additional capability announcement and is
> alluded to in the draft). For 'shared interface forwarding', this
option
> seamlessly interworks with 'option b'. For 'private interface
> forwarding' however, a capability announcement may be useful to get
> around next hop issues where the advertised next hop may not be in the
> 'global' routing table, but is applicable within the context of a VRF.
> What do you think?
> 
> Q.3
>  Is the criteria which scheme should be taken, 
>  "Private Interface Forwarding" or "Shared Interface Forwarding",
>  equivalent to the criteria which option, "A" or "B" is preferred?
> 
> MH: Good question. I think that service providers do fall into two
> separate camps on this one - ones who will not contemplate connecting
> their MPLS core to another service provider via a 'global' interface
due
> in part to security issues related to the possibility of label based
> attacks and routing vendors inability to prevent these attacks.
'Option
> a' and 'shared interface forwarding' are equally applicable here to
> solve these concerns. Other service providers however have sufficient
> trust with their partners and do not see this as an issue. The 'loose
> coupling' of VPN services that an MPLS based connection gives in
'shared
> interface forwarding' (per ASBR VRFs are not attached across AS
borders)
> allows for some interesting topology builds that could be achieved
> across SPs by logically associating ASBR VRFs across AS borders as
> hub-and-spoke. One of the nice thing about this additional option
though
> is that the control plane for 'private' and 'shared' interface
> forwarding could be administered identically meaning that a single
> service provider could connect to different partners via either data
> plane method and use the same administrative policies at the control
> plane to link sites across AS borders. That is not possible in options
> 'a' and 'b'. 
> 
> Q.4
>  In terms of Inter/intra-AS TE context, the difference between option
B
> and D is whether or not it can provide "per-vrf" tunnel setup, isn't
it?
>  Option A and D look similar in terms of adopting "Intra"-AS TE
> connected
>  approach, though.
> 
>  MH: Agreed - for both forwarding options in the draft, assuming that
> the ASBR supports per VRF TE setup, numbers of TE tunnels can be
> drastically reduced across ASes (compared with 'option c'). 
> 
> Thanks for the questions. Do you see this additional option as being
> useful based on your knowledge so far?
> 
> Regards
> 
> Martin Halstead
> [email-masked]
>