[c-nsp] Problems sub-interface Catalyst 6500

[Marko Milivojevic]

> I'm not sure such an approach has been considered, but the relative 
> complexity and potential caveats/limitations would potentially be high 
> versus actual utility.

	Well, as a customer in a position that is being hurt by this, I could 
immediately point out how it could be useful ;-).

	Say that you have a network that looks something like this:

  [a1]--[a2]--[a3]
   |           |
   |           |
[pe1]-------[pe2]
   ||          ||
{mpls}      {mpls}
{cld.}      {cld.}
   ||          ||
[pe3]-------[pe4]
   |           |
   |           |
  [a4]--[a5]--[a6]

	In words, there are some access rings connected to PE's, which in turn are 
connected to the rest of MPLS cloud using L3 links. Due to $om€ £imitation$, 
uplinks and PE-PE are implemented using LAN interfaces (in my case 10G 
Ethernet).

	Then again, say  that you need "VLAN" (L2VPN) between [a2] and [a5].  You 
would create VLAN in pe1, pe2, a1, a2, a3, as well as pe3, pe4, a4, a5, a6. 
Then, depending on the requirement, you'd create subinterface on pe1-a1 and 
do xconnect... But, wait, that turns pe1-a1 link into L3 link with all 
benefits of the switched interface lost. You can't do xconnect from SVI 
without using OSM/SIP/FlexWAN as uplink. As a concerned customer you 
approach helpful engineer on Networkers and they recommend you "external 
loopback". You go home happy man, make loopback pe1-pe1, with one end being 
trunk, the other end L3 with subinterfaces. You try to create xconnect:

! a1-facing interface
interface gi1/1
  switchport trunk enc dot1q
  switchport mode trunk
!
! trunk end of loopback
interface gi1/2
  switchport trunk enc dot1q
  switchport mode trunk
  switchport trunk allowed vlan 27
!
! L3 end of loopback -- xconnect source interface
interface gi1/3
  no switchport
!
interface gi1/3.27
  encapsulation dot1q 27
Command rejected: VLAN 27 not available

  ... this is where we fail miserably :-)

	So, happy man, turns to be a sad man, but discovers VLAN mapping and 
configures the horrible hack:

interface gi1/1
  switchport vlan mapping enable
  switchport vlan mapping 1027 27
!
interface gi1/3.27
  encapsulation dot1q 1027
  xconnect pe3.ip.ad.dr 27 encapsulation mpls
!

	This works, of course. It's using 2 VLAN's per xconnect, configures this 
translation on half of the line card in question and I have no problem with 
all that. However, I *do* have a problem explaining this solution to the 
guys who have to do the provisioning. I tried it once, got very blank looks 
on their faces and realized that this may not be the best thing to do in a 
production network.

	If there was a support for "real subinterfaces", even if it were using VLAN 
mapping as an underlying workaround, with all the limitations, it would 
greatly simplify provisioning in casses like these. Networkers guy said they 
do this on regular basis, so... I'm not the only one.

	With the current price tag of 10G SIP to solve this problem the right way 
(tm), it's not an option :-).

Marko.

P.S. Just three days ago I got recommended external loopback by a Cisco 
consulting engineer for another issue -- you guys seem to love this stuff! :-)