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

From: "Martin Halstead" <[email-masked]>
Date: Thu, 13 Apr 2006 15:41:50 +0100

Yuji

Answers in-line

> 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?

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.

MH: True, but the simplest way to solve this with no additional
capability announcement is to ensure on each ASBR that all VRF AC
interfaces share the same address as the global peer. Saying that, I do
agree with your next comment.

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. 

MH: Agreed - will include this in the next version.

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.

MH: The draft does talk about supporting options 'a' and 'b' along with
this additional option, but more detailed interworking descriptions for
all options could be added fairly easily.

Again, thanks for the comments,

Regards

Martin
[email-masked]

---

From: Ron Bonica <[email-masked]>
Date: Thu, 13 Apr 2006 11:12:06 -0400

Martin,

Could you explain the motivation for private interface forwarding? I
don't understand which problems it solves that could not be solved with
an equal number of Option A and Option B interfaces between ASBR's

                           Ron
                           /as individual contributror