Subject: RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

From: <[email-masked]>
Date: Mon, 2 May 2011 17:10:39 +0200

Hi,

Still a point regarding interAS case. What about the option d) behavior ? (draft-kulmala-l3vpn-interas-option-d)
As the VPN IPv4 route coming from AS1 is imported in ASBR VRF context as IPv4 and then advertised as a new VPN IPv4 route (different RT/RD) to AS2, I suppose that the ATTR_SET should be lost as for option a) even if we still have an inet-vpn route between ASBRs. Could you confirm ?

Regards,

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
Envoyé : vendredi 29 avril 2011 19:14
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : RE: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

Pedro,

Thanks for the clarification text that you have added on inter AS VPN.
New draft (-04) addresses all my comments.

Thanks,
Regards,
Bruno

> From: Pedro Marques [mailto:[email-masked]]
> 
> Bruno,
> 
> On Thu, Apr 28, 2011 at 5:41 AM,  <[email-masked]>
wrote:
> 
> >> In both cases the ATTR_SET attribute will be "poped". The ATTR_SET 
> >> attribute is only propagated as long as the route is an "inet-vpn"
> >> route... once imported into a VRF it disappears.
> >
> > Yes. With iBGP, the ATTR_SET attribute will be "poped" but only
after copying the BGP attributes of
> the customer route (e.g. LOCAL_PREF) on the regular iBGP attributes.
Then the next ASBR would "push"
> them back in a new ATTR_SET attribute. Hence BGP attributes of the
customer are propagated end to end.
> 
> But that wouldn't be inter-as option A, would it ? Option A is defined 
> as using eBGP on a per VRF basis.
> 
> I believe that one needs to consider what is the design of the 
> "customer" AS... while their may be topologies where you can get away 
> with the scenario you suggest, i'm now aware of a generic scenario 
> where this would work correctly.
> 
> 
> >
> > Given that l3vpn-ibgp comes after inter AS, I would assume that
inter AS interconnection pre-exist
> when the first iBGP PE-CE customer comes.
> 
> 
> > So if the deployed VPN ASBR use option A, l3vpn-ibgp have to face
it. That's fine for me if l3vpn-
> ibgp does not work with inter AS option A
> 
> There is no way i'm aware off to achieve VPN network transparency when 
> the provider interconnect is based on converting VPN routes to IP 
> route passing it through an eBGP peering and back.
> 
> The motivation to do iBGP is to provide VPN network transparency. In 
> inter-as cases to achieve transparency iBGP is not the only 
> requirement. You also need to exchange this customer routes via option 
> B (or C).
> 
> >, but I still believe this should be indicated in the "deployment
considerations" section of the
> document. You can also add that to be able to provide iBGP PE-CE, SP
should favor inter AS option B
> (over A).
> Will do.
>   Pedro.

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Pedro Marques <[email-masked]>
Date: Mon, 2 May 2011 09:01:36 -0700

Stephane,
My reading of the document that you quote is that routes are
advertised between ASBRs as "inet-vpn" routes. That is certainly the
case when option B is used with per VRF forwarding, which is the
scenario that i've seen deployed. In both scenarios the ATTR_SET
attribute is propagated since the "inet" route is of local
significance only.

regards,
  Pedro.

---

From: <[email-masked]>
Date: Wed, 4 May 2011 11:41:17 +0200

Pedro,

It's quite different here from standard option B behavior.
>From my understanding, if we consider the following topology for a VPN :
PE1 having VRF1 with RD1, RT1 as import/export
ASBR1 having VRF2 with RD2, RT1 as import/export
ASBR2 having VRF3 with RD3, RT1 as import/export
PE2 having VRF4 with RD4, RT1 as import/export
ASBR1 and ASBR2 have one interface in GRT with MPeBGP session (we consider shared interface forwarding case).

PE1 advertise CE route with RD1:X/Y RT1
ASBR1 imports it in VRF2, removes RD and RT, compute best path, export VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no constraint to use the same RT in each AS ...), the prefix exported is a new VPN route : RD2:X/Y RT1
ASBR2 imports it in VRF3, removes RD and RT, compute best path, export VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is a new VPN route : RD3:X/Y RT1
PE2 imports it in VRF4

Considering this, are you sure that ATTR_SET should be kept ? As BGP-LOC RIB used by ASBRs for exporting routes are inet ones and not inet-vpn. Please correct me if I'm wrong.

Thanks,

Stephane

-----Message d'origine-----
De : Pedro Marques [mailto:[email-masked]] 
Envoyé : lundi 2 mai 2011 18:02
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]
Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

Stephane,
My reading of the document that you quote is that routes are advertised between ASBRs as "inet-vpn" routes. That is certainly the case when option B is used with per VRF forwarding, which is the scenario that i've seen deployed. In both scenarios the ATTR_SET attribute is propagated since the "inet" route is of local significance only.

regards,
  Pedro.

On Mon, May 2, 2011 at 8:10 AM,  <[email-masked]> wrote:
> Hi,
>
> Still a point regarding interAS case. What about the option d) 
> behavior ? (draft-kulmala-l3vpn-interas-option-d)
> De : [email-masked] [mailto:[email-masked]] De la part 
> de [email-masked] Envoyé : vendredi 29 avril 2011 
> 19:14 À : [email-masked] Cc : [email-masked]; [email-masked] 
>> But that wouldn't be inter-as option A, would it ? Option A is 
>> defined as using eBGP on a per VRF basis.
>>
>> There is no way i'm aware off to achieve VPN network transparency 
>> when the provider interconnect is based on converting VPN routes to 
>> IP route passing it through an eBGP peering and back.
>>
>> requirement. You also need to exchange this customer routes via 
>> option B (or C).
>>
> **********************************************************************
> ********** IMPORTANT.Les informations contenues dans ce message 
> electronique y compris les fichiers attaches sont strictement 
> confidentielles et peuvent etre protegees par la loi.
> Si vous avez recu ce message par erreur ou s il ne vous est pas 
> destine, veuillez immediatement le signaler  a l expediteur et effacer ce message et tous les fichiers eventuellement attaches.
> IMPORTANT.This e-mail message and any attachments are strictly 
> confidential and may be protected by law. This message is intended only for the named recipient(s) above.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 04 May 2011 14:18:47 +0200

Hi Stephane,

The behaviour of option d is really dependent on the implementation.

Remember that as general rule imported routes should not be exported 
again. I think draft-kulmala-l3vpn-interas-option-d describes the 
concept not the actual implementation.

So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 
while leaving all other attributes as is including ATTR_SET. In the same 
time the prefix will be imported into vrf.

IMHO draft-ietf-l3vpn-ibgp-02 should not mandate what BGP 
implementations of various flavors of inter-as VPN peering should result 
in (options C+, C- or D ...) in regards of keeping or not ATTR_SET. In 
fact the same applies to option B and C too. It is up to provider to 
pass this attribute and the draft may only recommend default behaviour.

Many thx,
R.

> Objet : Re: [Idr] Joint L3VPN&  IDR WG LC for draft-ietf-l3vpn-ibgp-02
>
> Stephane,
> On Mon, May 2, 2011 at 8:10 AM,<[email-masked]>  wrote:
>> Hi,
>>
>> Objet : RE: [Idr] Joint L3VPN&  IDR WG LC for draft-ietf-l3vpn-ibgp-02
>>
>> Pedro,
>>
>>> On Thu, Apr 28, 2011 at 5:41 AM,<[email-masked]>
>> wrote:
>>>
>> **********

---

From: Pedro Marques <[email-masked]>
Date: Wed, 4 May 2011 10:12:34 -0700

Stephane,

> ASBR1 imports it in VRF2, removes RD and RT, compute best path, export VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no constraint to use the same RT in each AS ...), the prefix e…

I don't share your assumption.

You are assuming that the VRF route is re-advertised from the main
instance to a VRF and then back. Indeed in this case ATTR_SET should
not be kept. But that is not the only issue with this scenario.

In my view the routes in the VRFs are used for forwarding only and
should not be used for routing exchanges. That would allow one to have
forwarding entries for some VRFs and not others purely as a local
matter.

I believe this is taking us into an entirely different discussion on
how to do inter-as. Which is quite orthogonal to the document we are
discussing.

I think that it is generally agreed that for inter-as the scalability
of option B is desirable but that SP sometimes need the type of
control that can get out of an option A interconnect. In my view that
is functionality that can exist as a matter of local forwarding
behavior (It has been demonstrated).

The "option d" document that has been quoted in this thread does
deserve credit for correctly identifying the problem. The solution in
this space however should be transparent to both ends of the peering
session. i.e. provider A should be able to deploy per VRF traffic
forwarding behavior without coordinating with provider B. That in my
view requires that the format for route and traffic exchanges is the
same as defined by option B today.

regards,
  Pedro.

---

From: <[email-masked]>
Date: Thu, 5 May 2011 15:16:31 +0200

Robert, Pedro,

[R] >So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while leaving all other 
[R] >attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf.

Is your implementation at CISCO works like this ?

The text in the draft seems to mention that routes are taken from VRF RIBs to be exported, not from VPN IPv4 BGP LOCAL-RIB :

§4.1.2 (for shared if fwding as example) : "ASBR1 exports routes associated to VPN-1 from VRF2's RIB to BGP where
   RD and RT attributes, plus label bindings are attached to these
   routes. These labeled VPN-IPv4 routes are advertised across interface
   'b' to ASBR2 via BGP, with a next-hop set to ASBR1. ASBR2 imports the
   VRF2 exported routes into VRF3's RIB where the routes RT and RD
   attributes are removed."

VRF BGP LOC-RIB will not have the ATTR_SET attribute anymore as attributes are changed during import from L3VPN route to the VRF.

[P] >In my view the routes in the VRFs are used for forwarding only and should not be used for routing exchanges. That would allow one to have forwarding entries for some VRFs and not others purely as a local matter.

The sentence "ASBR1 exports routes associated to VPN-1 from VRF2's RIB to BGP where
   RD and RT attributes, plus label bindings are attached to these
   routes." is not pretty clear, and I understand that inet routes in VRF are used for routing too.

§5.1 talks about "IPv4 routes that are converted by the ASBR to labeled VPN-IPV4 routes", this lead to think too that IPv4 VRF RIB is used as a base for exporting routes at ASBR level.

Moreover the draft option D permits aggregation of VPN routes (§5.3), imo  VRFs are not only used for forwarding but also for routing

[P] >I think that it is generally agreed that for inter-as the scalability of option B is desirable but that SP sometimes need the type of control that can get out of an option A interconnect.

I agree on that

Thanks,

Stephane

-----Message d'origine-----
De : Robert Raszuk [mailto:[email-masked]] 
Envoyé : mercredi 4 mai 2011 14:19
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

Hi Stephane,

Remember that as general rule imported routes should not be exported again. I think draft-kulmala-l3vpn-interas-option-d describes the concept not the actual implementation.

So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while leaving all other attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf.

IMHO draft-ietf-l3vpn-ibgp-02 should not mandate what BGP implementations of various flavors of inter-as VPN peering should result in (options C+, C- or D ...) in regards of keeping or not ATTR_SET. In fact the same applies to option B and C too. It is up to provider to pass this attribute and the draft may only recommend default behaviour.

Many thx,
R.

> ASBR1 imports it in VRF2, removes RD and RT, compute best path, export 
> VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there is no 
> constraint to use the same RT in each AS ...), the prefix exported is 
> a new VPN route : RD2:X/Y RT1
> ASBR2 imports it in VRF3, removes RD and RT, compute best path, export 
> VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix exported is 
> a new VPN route : RD3:X/Y RT1
> PE2 imports it in VRF4
>
>> De : [email-masked] [mailto:[email-masked]] De la 
>> part de [email-masked] Envoyé : vendredi 29 avril 
>> 2011
>>> "customer" AS... while their may be topologies where you can get 
>>> away with the scenario you suggest, i'm now aware of a generic 
>>> scenario where this would work correctly.
>>>
>>>
>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 05 May 2011 16:22:52 +0200

Hi Stephane,

> Robert, Pedro,
>
> [R]>So some implementation may just copy RD1:NET RT1 to RD2:NET RT1,RT2 while leaving all other
> [R]>attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf.
>

In IOS the default implementation of option D is to follow the draft 
literally that means to export the imported prefix from the ASBR's VRF - 
exactly as you have interpreted by reading the draft.

However due to operator requests we also by configuration allow to 
advertise the original src routes (and not those imported to ASBR's 
VRFs) and therefor treat VRF only to be used for forwarding.

So to conclude, since you asked, Cisco IOS supports both options in 
option D inter-as configuration. Clearly the second mode will propagate 
ATTR_SET unchanged.

Thx,
R.

---

From: <[email-masked]>
Date: Thu, 5 May 2011 16:36:23 +0200

Thanks for the clarification.

Regards,

Stephane

-----Message d'origine-----
De : Robert Raszuk [mailto:[email-masked]] 
Envoyé : jeudi 5 mai 2011 16:23
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

Hi Stephane,

> Robert, Pedro,
>
> [R]>So some implementation may just copy RD1:NET RT1 to RD2:NET 
> RT1,RT2 while leaving all other [R]>attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf.
>

In IOS the default implementation of option D is to follow the draft literally that means to export the imported prefix from the ASBR's VRF - exactly as you have interpreted by reading the draft.

However due to operator requests we also by configuration allow to advertise the original src routes (and not those imported to ASBR's
VRFs) and therefor treat VRF only to be used for forwarding.

So to conclude, since you asked, Cisco IOS supports both options in option D inter-as configuration. Clearly the second mode will propagate ATTR_SET unchanged.

Thx,
R.

---

From: Pedro Marques <[email-masked]>
Date: Thu, 5 May 2011 08:50:05 -0700

Stephane,
With option B), ASBR peering happens at the inet-vpn address family
(1, 128). In this case ATTR_SET attribute is propagated. It is still
possible to import routes into VRFs, these routes are forwarding-only
routes not used for routing exchanges and thus not important for this
discussion. These forwarding entries can be used to apply fine grain
control over the traffic without exposing this local functionality to
the peer.

  Pedro.

---

From: <[email-masked]>
Date: Fri, 6 May 2011 09:51:42 +0200

Yes you are right for this case.

Thanks for your feedback.

Regards,

Stephane

-----Message d'origine-----
De : Pedro Marques [mailto:[email-masked]] 
Envoyé : jeudi 5 mai 2011 17:50
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02

Stephane,
With option B), ASBR peering happens at the inet-vpn address family (1, 128). In this case ATTR_SET attribute is propagated. It is still possible to import routes into VRFs, these routes are forwarding-only routes not used for routing exchanges and thus not important for this discussion. These forwarding entries can be used to apply fine grain control over the traffic without exposing this local functionality to the peer.

  Pedro.

On Thu, May 5, 2011 at 6:16 AM,  <[email-masked]> wrote:
> Robert, Pedro,
>
>
> [R] >So some implementation may just copy RD1:NET RT1 to RD2:NET 
> RT1,RT2 while leaving all other [R] >attributes as is including ATTR_SET. In the same time the prefix will be imported into vrf.
>
> §4.1.2 (for shared if fwding as example) : "ASBR1 exports routes 
> associated to VPN-1 from VRF2's RIB to BGP where
> Moreover the draft option D permits aggregation of VPN routes (§5.3), 
> imo  VRFs are not only used for forwarding but also for routing
>
> De : Robert Raszuk [mailto:[email-masked]] Envoyé : mercredi 4 mai 
> 2011 14:19 À : LITKOWSKI Stephane DTF/DERX Cc : 
> [email-masked]; [email-masked]; [email-masked] Objet : Re: 
> [Idr] Joint L3VPN & IDR WG LC for draft-ietf-l3vpn-ibgp-02
>
> Hi Stephane,
>
>> ASBR1 imports it in VRF2, removes RD and RT, compute best path, 
>> export VRF RIB route to MPeBGP by adding RD2 and RT1 (morever there 
>> is no constraint to use the same RT in each AS ...), the prefix 
>> exported is a new VPN route : RD2:X/Y RT1
>> ASBR2 imports it in VRF3, removes RD and RT, compute best path, 
>> export VRF RIB route to MPIBGP by adding RD3 and RT1, the prefix 
>> exported is a new VPN route : RD3:X/Y RT1
>> PE2 imports it in VRF4
>>
>>> 19:14 À : [email-masked] Cc : [email-masked]; 
>>> [email-masked] Objet : RE: [Idr] Joint L3VPN&  IDR WG LC for
>>> draft-ietf-l3vpn-ibgp-02
>>>
>>> Pedro,
>>>
>>>>>> In both cases the ATTR_SET attribute will be "poped". The 
>>>>>> ATTR_SET attribute is only propagated as long as the route is an "inet-vpn"
>>>> The motivation to do iBGP is to provide VPN network transparency. 
>>>> In inter-as cases to achieve transparency iBGP is not the only 
>>> ********************************************************************
>>> *
>>> *
>>> ********************************************************************
>>> *
>>> *
>>> **********
>>>
>>>
>>

---

From: Saku Ytti <[email-masked]>
Date: Fri, 6 May 2011 11:53:37 +0300

> behavior (It has been demonstrated).

Sorry to butt in with off-topic. But this is one of my larger pet
peevees, no vendor supports RFC4364 page 31 last sentence. Which means
OptB cannot be used in inter-AS environments if full trust does not
exist.

In RFC compliant implementation risk is same as in OptA, i.e. neighbor
can leak traffic between customers shared in NNI, but cannot inject
traffic to arbitrary VRF.

It would be very nice way to multiplex connections between CE and PE
too, instead of configuration overhead of Opt A (and no need to be
have circuit which can support PVC/VLAN multiplexing).

So vendors, please implement this as described in RFC.
-- 
  ++ytti

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 May 2011 11:03:23 +0200

<removing idr and adjusting the title>

Hi Saku,

> peevees, no vendor supports RFC4364 page 31 last sentence.

Can you quote this sentence ? My page 31 talks about CSC ....

> have circuit which can support PVC/VLAN multiplexing).

How can you multiplex control plane which is coming from N CEs to one PE ?

Thx,
R.

---

From: Saku Ytti <[email-masked]>
Date: Fri, 6 May 2011 12:12:58 +0300

> Can you quote this sentence ? My page 31 talks about CSC ....

I Think I was off by one.

--
An ASBR should never accept a labeled packet from an EBGP peer unless
it has actually distributed the top label to that peer.
--

> How can you multiplex control plane which is coming from N CEs to one PE ?

No I mean single CE, where you'd today to vrf-lite and multplex VLAN
or PVC to deliver them, if you have good number of VRF per CE, OptB
would be nicer, especially as relatively low-end CPE today have MPLS
capability.
Of course greater benefit would be NNI. But no one wants to do OptB,
due to security issues.

-- 
  ++ytti

---

From: <[email-masked]>
Date: Fri, 6 May 2011 11:53:58 +0200

Saku,

For single PE - single CE with multiple VPNs, imo option D should fit the need.

Regards,

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Saku Ytti
Envoyé : vendredi 6 mai 2011 11:13
À : [email-masked]
Cc : [email-masked]
Objet : Re: Option B

--
An ASBR should never accept a labeled packet from an EBGP peer unless it has actually distributed the top label to that peer.
--

> How can you multiplex control plane which is coming from N CEs to one PE ?

No I mean single CE, where you'd today to vrf-lite and multplex VLAN or PVC to deliver them, if you have good number of VRF per CE, OptB would be nicer, especially as relatively low-end CPE today have MPLS capability.
Of course greater benefit would be NNI. But no one wants to do OptB, due to security issues.

--
  ++ytti

---

From: Saku Ytti <[email-masked]>
Date: Fri, 6 May 2011 13:40:53 +0300

> For single PE - single CE with multiple VPNs, imo option D should fit the need.

If you are labeling in D you have the same exact problem as far as I
can see as with B, i.e. you cannot use it due to incomplete
implementation by the vendors, unless you have full trust.

-- 
  ++ytti

---

From: <[email-masked]>
Date: Fri, 6 May 2011 15:21:20 +0200

Your concern is about the CE being able to use a crafted label stack permitting him to access to another VPN than his own ? Pls confirm my understanding.

-----Message d'origine-----
De : Saku Ytti [mailto:[email-masked]] 
Envoyé : vendredi 6 mai 2011 12:41
À : LITKOWSKI Stephane DTF/DERX
Cc : [email-masked]; [email-masked]
Objet : Re: Option B

> For single PE - single CE with multiple VPNs, imo option D should fit the need.

If you are labeling in D you have the same exact problem as far as I can see as with B, i.e. you cannot use it due to incomplete implementation by the vendors, unless you have full trust.

--
  ++ytti

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 May 2011 15:27:36 +0200

Hi Saku,

Well I am not sure which vendor you are referring to but one vendor I 
checked does seem to support label verification in inter-as option D.

As a rule of thumb if the packets are coming to a VRF either from CE or 
from inter-as ASBR the VPN label is verified against the one which has 
been advertised to a peer.

However you are right that for plain option B where packets are coming 
not to a VRF, but to a global LFIB such verification is not currently 
enabled.

Rgs,
R.

PS. For vendor specifics let's talk offline not to spam the list too 
much ;-).

> On 6 May 2011 12:53,<[email-masked]>  wrote:
>

---

From: Saku Ytti <[email-masked]>
Date: Fri, 6 May 2011 20:32:51 +0300

> checked does seem to support label verification in inter-as option D.

Ok, I assumed D would be more or less same as B, tbh haven't really
investigated D support.

For option B at least Alcatel, Huawei, Juniper and Cisco do not
support as per their RFP responses.
And I've been asking CSCO for maybe decade, bit less from JNPR.

> However you are right that for plain option B where packets are coming not
> to a VRF, but to a global LFIB such verification is not currently enabled.

I'm curious why not, I'm sure that some older 'pure ASIC' hardware
can't do it, but more modern stuff
like ezchip, xelerated, trio, qfp/cpp10 etc I'm confident are all able
to do it.
I know people want it, many SP to whom I've talked, would swap their
MPLS NNI from OptA to OptB were it standard compliant.

-- 
  ++ytti