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

From: "Martin Halstead" <[email-masked]>
Date: Wed, 12 Apr 2006 15:32:38 +0100

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]

---

From: Shane Amante <[email-masked]>
Date: Wed, 12 Apr 2006 16:32:55 -0600

Martin,

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?

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?

Thanks,

-shane

---

From: "Yuji KAMITE" <[email-masked]>
Date: Thu, 13 Apr 2006 22:17:28 +0900

Hi Martin,

> 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 

As long as 'private interface' case, treatment of "next hop" looks a little awkward to me.
It seems to require a new paradigm of creating and using routing table,

In my understanding, VPNv4 prefix is attached with "overwritten" RD/RT at ASBR 
and next-hop interface must be treated at per sub-interface level,  for private
interface's isolation;  however,  advertised next-hop is always at global route.

For option A users, It MUST have a mechanism to avoid mixturing each VRF's route and
other interfaces (for non-vpn usage as well).  If it can be 
prevented at protocol-level negotiation, some kind of capability advertisement 
might be useful, and safe. 

Basically description about operational differences (or migration scheme)
from existing A/B users would be useful and highly expected.
Connectivity checking scheme (as already pointed out) is included there too.

-Yuji