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

From: Ron Bonica <[email-masked]>
Date: Tue, 04 Apr 2006 10:55:37 -0400

Folks,

Since the list has been pretty quiet lately, I would like to entertain
discussion regarding whether draft-kulmala-l3vpn-interas-option-d-02
should become a working group item.

I am particularly interested in hearing from operators, but everybody is
welcomed to join in the discussion.

                               -r

---

From: "Yuji KAMITE" <[email-masked]>
Date: Tue, 11 Apr 2006 18:35:50 +0900

> I am particularly interested in hearing from operators, but 
> everybody is welcomed to join in the discussion.

I'd like to know what is the most biggest motivation/application
for deploying this.  Let me ask some questions to the authors.

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?
 
Q.2
 The implementation difference from the existing A/B/C, resides just in
 route import/advertisement behavior?   (i.e., no capability negotiation etc.)

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?

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.

-Yuji

> -----Original Message-----
> From: Ron Bonica [mailto:[email-masked]] 
> Sent: Tuesday, April 04, 2006 11:56 PM
> To: [email-masked]
> Subject: draft-kulmala-l3vpn-interas-option-d-02
> 
> Folks,
> 
> Since the list has been pretty quiet lately, I would like to 
> entertain discussion regarding whether 
> draft-kulmala-l3vpn-interas-option-d-02
> I am particularly interested in hearing from operators, but 
> everybody is welcomed to join in the discussion.
> 
>                                -r
>

---

From: Ville Hallivuori <[email-masked]>
Date: Tue, 11 Apr 2006 22:08:26 +0300

> for deploying this.  Let me ask some questions to the authors.

Our motivation is to combine benefits of option A and B to a single
option. With option D one gets:
  +No need to provision per VRF AC:s if shared interface forwarding is
   used (B)
  +No per VRF BGP sessions (B)
  +Operational separation for allocation of RD:s and RTs for SPs (A)
  +Because RD is per ASBR, a reasonable load balancing is possible
   (with option B RD is per remote PE so local RR selects only one of
   possible ASBRs to reach the remote PE)  (A)
  +Possible to perform IP forwarding at ASBR (in VRF) -> route
   aggregation, ACLs, re-classifying,  etc are possible. (A)
  +VRF context -> per VRF PSN tunnel selection, per VRF policing, etc (A)

>  do they get any special benefits by this?

With shared interface forwarding you do get the MPLS forwarding
option (->no need to provision separate per VRF ACs).

If you have thousands or tens of thousands VPNs per ASBR, having same
number of BGP sessions seems rather unreasonable. If single ASBR would
peer with three other ASBRs using option B and would have 10 000 common
VPNs with each, with default BGP timers there would be 1000 BGP
keep-alives every second just for maintaining the per VRF BGP
sessions...  with option D you would only need one hello every ten
second. 

>  route import/advertisement behavior?   (i.e., no capability negotiation etc.)

This is correct. The line protocol remains unchanged, and only
advertisement behaviour has been changed. This option can actually
inter-operate with option B speaker.

>  equivalent to the criteria which option, "A" or "B" is preferred?

Shared interface forwarding is more convenient to provision. However
sometimes having MPLS enabled interface towards another SP might be
concidered as a security risk, and in such situations private
interface forwarding might be preferable.

>  Option A and D look similar in terms of adopting "Intra"-AS TE connected

This is correct.

-- 
[Ville Hallivuori][[email-masked]][http://www.iki.fi/vph/]
[ID 8E1AD461][FP16=C9 50 E2 DF 48 F6 33 62  5D 87 47 9D 3F 2B 07 5D]
[ID 58543419][FP20=8731 941D 15AB D4A0 88A0  FC8F B55C F4C4 5854 3419]
[ID 8061C24E][FP20=C722 12DA 841E D811 DBFE  2FB3 174C E291 8061 C24E]