Subject: Re: Question regdg. MPLS/BGP VPN MIB

From: [email-masked]
Date: Fri, 02 May 2003 17:17:28 +0200

hi Greg,

Shmunis, Gregory wrote:

> Tom,
> 
> thanks. I understand the technical aspect of using various criteria
> (including the source address) in the PE-incoming traffic to identify the
> right lookup VRF. What I'm trying to figure out is a concrete deployment
> case where sharing of a PE interface between VRFs would be required, and
> also - what are potential side-effects of such use. 

simplest example: a site S can be part of an intranet with sites from 
the only same organization (VPN-A) AND part of an extranet involving 
sites from other organizations (VPN-B).

1) quoted from the current 2547bis draft:

[section 3.1. "VRFs and Attachment Circuits"]
    "We allow the case in which a single attachment circuit is associated
    with a set of VRFs, rather than with a single VRF. This can be
    useful if it is desired to divide a single VPN into several "sub-
    VPNs", each with different connectivity restrictions, where some
    characteristic of the customer packets is used to select from among
    the sub-VPNs.  For simplicity though, we will usually speak of an
    attachment circuit as being associated with a single VRF."

Then, considering the upper-cited text, you'll have to attach this site 
S both to VRF-A AND VRF-B... and you also need some mechanism to 
identify the right lookup VRF.

2) but the current 2547bis draft also mention this:

[section 3.2. "Associating IP packets with VRF"]:
    "If an attachment circuit leads to a site which is in multiple VPNs,
    the attachment circuit may still associated with a single VRF, in
    which case the VRF will contain routes from the full set of VPNs of
    which the site is a member."

from this standpoint, a (sub-)interface is attached to a single VRF, 
which belongs to several VPNs. What I pointed out some times ago on the 
MIB is that the VPN-id does not make sense for a given VRF, since it can 
belong to several VPNs.

> For instance, the
> example of using the source address alone on a VRF-shared interface implies
> that the VRFs that share the interface cannot use overlapping address spaces
> - otherwise the traffic in the reverse (PE-to-CE) direction would be
> untreatable.
> 
> Perhaps Yasin can give his example. Having said all the above I want to make
> it clear that the question is less of a MIB nature - it pertains to the
> general operational aspect of 2547bis.

agree.

> greg.

thanks,
yacine

> 
> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Wednesday, April 30, 2003 4:47 PM
> To: Shmunis, Gregory
> Cc: [email-masked]; [email-masked]
> Subject: RE: Question regdg. MPLS/BGP VPN MIB
> 
> 
> 
> 
>>Tom,
>>
>>can you please point to a previous thread where concrete operational
>>scenarios with an interface belonging to more than one VRF were discussed ?
>>If it is simpler for you, can you just mention a case or two ?
>>
> 
>          I have two examples. First, Yacine pointed out
> a case a while back that we discussed -- perhaps
> he can explain his scenario.  In my case, my products
> allow for multiple VRFs to be associated with the same
> interface, and then based on the source address, one
> of the VRFs is chosen to do the route lookup. Admittedly,
> this is not a widely used case, but I think it is still one
> that is used enough that the standard MIB should handle
> it.
> 
>          --Tom
> 
> 
> 
> 
> 
> 
>>thank you,
>>
>>Greg.
>>
>>-----Original Message-----
>>From: Thomas D. Nadeau [mailto:[email-masked]]
>>Sent: Tuesday, April 29, 2003 11:00 AM
>>To: Siddharth Aanand
>>Cc: [email-masked]; "Harmen Van der Linde"[email-masked]
>>Subject: Re: Question regdg. MPLS/BGP VPN MIB
>>
>>
>>At 10:46 AM 4/29/2003 -0400, Siddharth Aanand wrote:
>>
>>>>>The draft-ietf-ppvpn-mpls-vpn-mib-05.txt defines mplsVpnVrfName and
>>>>>mplsVpnIfConfIndex as keys to the mplsVpnIfConfTable. The question I
>>>>>
>>had
>>
>>>>>was, isn't the ifIndex (mplsVpnIfConfIndex) sufficient to uniquely
>>>>>identify a row in this table ? Under what circumstances do we need
>>>>>
> both
> 
>>>>>the vrfName as well as the ifIndex as keys?
>>>>>
>>>>         Yes, but the operational feedback was that operators
>>>>wanted to cycle through interfaces belonging to each VRF.
>>>>We need to update this slightly because there are cases where
>>>>one interface may belong to multiple VRFs.
>>>>
>>>Yes. If one interface belongs to multiple VRFs then we'd need the vrfName
>>>as a key. Do you know what distinguishing feature of the incoming
>>>
> traffic,
> 
>>>on that interface, would be used to decide which VRF to use?
>>>
>>         I think that is orthogonal to the discussion at hand.
>>What is important is that the MIB can handle these
>>cases without regard to how the choice is being made.
>>The reason being that it is often a proprietary feature/configuration
>>that does the choosing. My implementation for instance,
>>uses several rules to make this determination.  I know of
>>another that makes a simple choice based on source
>>address.
>>
>>         --Tom
>>
>>
>>
>>
>>>-Sidd
>>>
> 
> 
> 
> 
>