Re: [bess] RFC 8277

[Gyan Mishra]

I believe changing the next-hop re-write normally done via next-hop-self
which sets the next hop to the ibgp peering loopback of the PE done in Opt
B can be accomplished via route policy route-map or RPL to set to the same
loopback or different address  via “set ip next-hop.

I think as was mentioned the label binding is not being created to the new
next hop address as was mentioned.

Verify that the label binding is not being created for the rewritten new
next hop address.

Try remove the policy and do next hop self and then check if label binding
is being created.

I have used route policy to set next hop but have never done for opt B.

I think this maybe a corner case issue bug



On Thu, Dec 12, 2019 at 3:06 PM michael walden 
wrote:

> Yes, it's a local address on ASBR R2 which is the same router changing the
> next hop.  I was trying to find out from a standards perspective if
> changing the next hop field in this manner should also change the label
> since I'm seeing different behavior on different network operating systems.
>
> On Thu, Dec 12, 2019 at 2:33 PM Robert Raszuk  wrote:
>
>> Hi Satya,
>>
>> I believe the address Michael is using in the route-map to set nh is one
>> of the local addresses on the very ASBR.
>>
>> Thx,
>> R.
>>
>> On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) <
>> satya...@cisco.com> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> If the next-hop is set to some third-party device at the option-B ASBR
>>> and a new label is advertised, then we have to make sure that at that
>>> third-party device, the particular prefix is in fact bound to that
>>> particular label. Therefore, in addition to setting the next-hop at the
>>> ASBR there needs to be a way to specify the particular label also.
>>>
>>>
>>>
>>> Otherwise just using any dynamic label will not work.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> --Satya
>>>
>>>
>>>
>>>
>>>
>>> *From: *BESS  on behalf of Gyan Mishra <
>>> hayabusa...@gmail.com>
>>> *Date: *Thursday, December 12, 2019 at 11:01 AM
>>> *To: *michael walden 
>>> *Cc: *"bess@ietf.org" , Robert Raszuk 
>>> *Subject: *Re: [bess] RFC 8277
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> I can try it out in VIRL.
>>>
>>>
>>>
>>> What version of XR or XE are you running?
>>>
>>>
>>>
>>> On Thu, Dec 12, 2019 at 1:52 PM michael walden 
>>> wrote:
>>>
>>> Thank you for the responses.  This is specifically not using next hop
>>> self to change the next hop, but using a route map or RPL to set next hop
>>> to a specific IP value such as below.  I realize this probably isn't a
>>> common configuration.
>>>
>>>
>>>
>>> route-map NH permit 10
>>>  match ip address prefix-list ONE
>>>  set ip next-hop x.x.x.x
>>>
>>>
>>>
>>> route-policy NH
>>>   if destination in (1.1.1.1/32) then
>>> set next-hop x.x.x.x
>>>
>>>
>>>
>>> On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra 
>>> wrote:
>>>
>>>
>>>
>>>
>>>
>>> With option b since the LSP is segmented into 3 segments
>>>
>>>
>>>
>>> Left side Rx to R1 -ibgp
>>>
>>> Middle R1 to R2 - ebgp vpnv4
>>>
>>> Right side R2 to R3 - ibgp
>>>
>>>
>>>
>>> So for the LSP to be segmented in opt b for it to work properly what is
>>> required is either next-hop-self on the ibgp peer so the rewrite happens
>>> forcing the label to change so the lsp is segmented on left side and right
>>> side from the middle.  The reason also for the segmentation in opt B is we
>>> are not importing the  SP loops between each other as done with opt c so
>>> the segmentation of the lsp has to happen for opt b to work.
>>>
>>>
>>>
>>> If you are doing this on Cisco XR it requires next hop static /32  route
>>> for MPLS forwarding to happen on the ebgp vpnv4 session where with XE
>>> automatically installs “MPLS forwarding” when ebgp vpnv4 is configured.
>>>
>>>
>>>
>>> If the rewrite is not happening to segment the lsp generate a new label
>>> then sounds like you are hitting a big.
>>>
>>>
>>>
>>> The inter as opt a b c ab are al

Re: [bess] RFC 8277

[Satya Mohanty (satyamoh)]

Thanks Robert.
Yes, I made a general observation.

Best,
--Satya

From: Robert Raszuk 
Date: Thursday, December 12, 2019 at 11:34 AM
To: "Satya Mohanty (satyamoh)" 
Cc: Gyan Mishra , michael walden 
, "bess@ietf.org" 
Subject: Re: [bess] RFC 8277

Hi Satya,

I believe the address Michael is using in the route-map to set nh is one of the 
local addresses on the very ASBR.

Thx,
R.

On Thu, Dec 12, 2019 at 8:25 PM Satya Mohanty (satyamoh) 
mailto:satya...@cisco.com>> wrote:
Hi,

If the next-hop is set to some third-party device at the option-B ASBR and a 
new label is advertised, then we have to make sure that at that third-party 
device, the particular prefix is in fact bound to that particular label. 
Therefore, in addition to setting the next-hop at the ASBR there needs to be a 
way to specify the particular label also.

Otherwise just using any dynamic label will not work.

Thanks,
--Satya


From: BESS mailto:bess-boun...@ietf.org>> on behalf of 
Gyan Mishra mailto:hayabusa...@gmail.com>>
Date: Thursday, December 12, 2019 at 11:01 AM
To: michael walden mailto:michaelewal...@gmail.com>>
Cc: "bess@ietf.org<mailto:bess@ietf.org>" 
mailto:bess@ietf.org>>, Robert Raszuk 
mailto:rob...@raszuk.net>>
Subject: Re: [bess] RFC 8277



I can try it out in VIRL.

What version of XR or XE are you running?

On Thu, Dec 12, 2019 at 1:52 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:
Thank you for the responses.  This is specifically not using next hop self to 
change the next hop, but using a route map or RPL to set next hop to a specific 
IP value such as below.  I realize this probably isn't a common configuration.

route-map NH permit 10
 match ip address prefix-list ONE
 set ip next-hop x.x.x.x

route-policy NH
  if destination in (1.1.1.1/32<http://1.1.1.1/32>) then
set next-hop x.x.x.x

On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


With option b since the LSP is segmented into 3 segments

Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp

So for the LSP to be segmented in opt b for it to work properly what is 
required is either next-hop-self on the ibgp peer so the rewrite happens 
forcing the label to change so the lsp is segmented on left side and right side 
from the middle.  The reason also for the segmentation in opt B is we are not 
importing the  SP loops between each other as done with opt c so the 
segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route for 
MPLS forwarding to happen on the ebgp vpnv4 session where with XE automatically 
installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label then 
sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and 
behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second 
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only local 
significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is quite 
surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:

Regarding RFC 8277 Section 3.2.2
3.2.2.  When the Next Hop Field Is Changed

   If the Network Address of Next Hop field is changed before a SAFI-4
   or SAFI-128 route is propagated, the Label field(s) of the propagated
   route MUST contain the label(s) that is (are) bound to the prefix at
   the new next hop.


"the Label field(s) of the propagated route MUST contain the label(s) that is 
(are) bound to the prefix at the new next hop."

This specification should apply when the next hop field of the route is changed 
by any means such as route map, route policies, or next-hop-self and propagated?

I've experienced differing behaviors between platforms as to whether or not a 
the label is changed when the next hop field is changed with a route map or 
route policy.

For example below inter-as option b R2 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> with label 1 from R1.  R2 changes the next hop 
field with an outbound route policy but doesn't replace the label before 
propagating the route to R3.  R3 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> and original label 1 breaking the LSP.

R1-eBGP- VPNv4-R2-iBGP VPNv4-R3


However on other platforms inter-as option b R2 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> 

Re: [bess] RFC 8277

[Satya Mohanty (satyamoh)]

Hi,

If the next-hop is set to some third-party device at the option-B ASBR and a 
new label is advertised, then we have to make sure that at that third-party 
device, the particular prefix is in fact bound to that particular label. 
Therefore, in addition to setting the next-hop at the ASBR there needs to be a 
way to specify the particular label also.

Otherwise just using any dynamic label will not work.

Thanks,
--Satya


From: BESS  on behalf of Gyan Mishra 

Date: Thursday, December 12, 2019 at 11:01 AM
To: michael walden 
Cc: "bess@ietf.org" , Robert Raszuk 
Subject: Re: [bess] RFC 8277



I can try it out in VIRL.

What version of XR or XE are you running?

On Thu, Dec 12, 2019 at 1:52 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:
Thank you for the responses.  This is specifically not using next hop self to 
change the next hop, but using a route map or RPL to set next hop to a specific 
IP value such as below.  I realize this probably isn't a common configuration.

route-map NH permit 10
 match ip address prefix-list ONE
 set ip next-hop x.x.x.x

route-policy NH
  if destination in (1.1.1.1/32<http://1.1.1.1/32>) then
set next-hop x.x.x.x

On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra 
mailto:hayabusa...@gmail.com>> wrote:


With option b since the LSP is segmented into 3 segments

Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp

So for the LSP to be segmented in opt b for it to work properly what is 
required is either next-hop-self on the ibgp peer so the rewrite happens 
forcing the label to change so the lsp is segmented on left side and right side 
from the middle.  The reason also for the segmentation in opt B is we are not 
importing the  SP loops between each other as done with opt c so the 
segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route for 
MPLS forwarding to happen on the ebgp vpnv4 session where with XE automatically 
installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label then 
sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and 
behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk 
mailto:rob...@raszuk.net>> wrote:
/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second 
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only local 
significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is quite 
surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden 
mailto:michaelewal...@gmail.com>> wrote:

Regarding RFC 8277 Section 3.2.2
3.2.2.  When the Next Hop Field Is Changed

   If the Network Address of Next Hop field is changed before a SAFI-4
   or SAFI-128 route is propagated, the Label field(s) of the propagated
   route MUST contain the label(s) that is (are) bound to the prefix at
   the new next hop.


"the Label field(s) of the propagated route MUST contain the label(s) that is 
(are) bound to the prefix at the new next hop."

This specification should apply when the next hop field of the route is changed 
by any means such as route map, route policies, or next-hop-self and propagated?

I've experienced differing behaviors between platforms as to whether or not a 
the label is changed when the next hop field is changed with a route map or 
route policy.

For example below inter-as option b R2 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> with label 1 from R1.  R2 changes the next hop 
field with an outbound route policy but doesn't replace the label before 
propagating the route to R3.  R3 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> and original label 1 breaking the LSP.

R1-eBGP- VPNv4-R2-iBGP VPNv4-R3


However on other platforms inter-as option b R2 receives VPNv4 route 
1.1.1.1/32<http://1.1.1.1/32> with label 1 from R1.  R2 changes the next hop 
field with an outbound route policy and does replace the label before 
propagating the route to R3.  R3 receives VPNv4 route 
1.1..1.1/32<http://1.1.1.1/32> and new label 2.

R1-eBGP- VPNv4-R2-iBGP VPNv4-R3






___
BESS mailing list
BESS@ietf.org<mailto:BESS@ietf.org>
https://www.ietf.org/mailman/listinfo/bess
--
Gyan S. Mishra
IT Network Engineering & Technology
Verizon Communications Inc. (VZ)
13101 Columbia 
Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail=g>
 FDC1 3rd Floor
Silver Spring, MD 20904
United States
Phone: 301 502-13

Re: [bess] RFC 8277

[Gyan Mishra]

I can try it out in VIRL.

What version of XR or XE are you running?

On Thu, Dec 12, 2019 at 1:52 PM michael walden 
wrote:

> Thank you for the responses.  This is specifically not using next hop self
> to change the next hop, but using a route map or RPL to set next hop to a
> specific IP value such as below.  I realize this probably isn't a common
> configuration.
>
> route-map NH permit 10
>  match ip address prefix-list ONE
>  set ip next-hop x.x.x.x
>
> route-policy NH
>   if destination in (1.1.1.1/32) then
> set next-hop x.x.x.x
>
> On Thu, Dec 12, 2019 at 12:48 PM Gyan Mishra 
> wrote:
>
>>
>>
>> With option b since the LSP is segmented into 3 segments
>>
>> Left side Rx to R1 -ibgp
>> Middle R1 to R2 - ebgp vpnv4
>> Right side R2 to R3 - ibgp
>>
>> So for the LSP to be segmented in opt b for it to work properly what is
>> required is either next-hop-self on the ibgp peer so the rewrite happens
>> forcing the label to change so the lsp is segmented on left side and right
>> side from the middle.  The reason also for the segmentation in opt B is we
>> are not importing the  SP loops between each other as done with opt c so
>> the segmentation of the lsp has to happen for opt b to work.
>>
>> If you are doing this on Cisco XR it requires next hop static /32  route
>> for MPLS forwarding to happen on the ebgp vpnv4 session where with XE
>> automatically installs “MPLS forwarding” when ebgp vpnv4 is configured.
>>
>> If the rewrite is not happening to segment the lsp generate a new label
>> then sounds like you are hitting a big.
>>
>> The inter as opt a b c ab are all IETF standards and the functionality
>> and behavior should be the same across all vendors.
>>
>> Cheers,
>>
>> Gyan
>>
>> On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk  wrote:
>>
>>> /* replacing IETF mailer with BESS */
>>>
>>> Hi Michael,
>>>
>>> Clearly you have discovered a bug in first implementation. Second
>>> implementation "other platform" works correctly.
>>>
>>> I assume you are doing next hop self on R2. Advertising labels have only
>>> local significance to a box which is listed as next hop in the NLRIs.
>>>
>>> Btw this behaviour did not really change from original RFC3107 so it is
>>> quite surprising you would still be running into such issues.
>>>
>>> Thx,
>>> R.
>>>
>>> On Thu, Dec 12, 2019 at 5:27 PM michael walden 
>>> wrote:
>>>

 Regarding RFC 8277 Section 3.2.2
 3.2.2.  When the Next Hop Field Is Changed

If the Network Address of Next Hop field is changed before a SAFI-4
or SAFI-128 route is propagated, the Label field(s) of the propagated
route MUST contain the label(s) that is (are) bound to the prefix at
the new next hop.


 "the Label field(s) of the propagated route MUST contain the label(s)
 that is (are) bound to the prefix at the new next hop."

 This specification should apply when the next hop field of the route is
 changed by any means such as route map, route policies, or next-hop-self
 and propagated?

 I've experienced differing behaviors between platforms as to whether or
 not a the label is changed when the next hop field is changed with a route
 map or route policy.

 For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32
 with label 1 from R1.  R2 changes the next hop field with an outbound route
 policy but doesn't replace the label before propagating the route to R3.
 R3 receives VPNv4 route 1.1.1.1/32 and original label 1 breaking the
 LSP.

 R1-eBGP- VPNv4-R2-iBGP VPNv4-R3


 However on other platforms inter-as option b R2 receives VPNv4 route
 1.1.1.1/32 with label 1 from R1.  R2 changes the next hop field with
 an outbound route policy and does replace the label before propagating the
 route to R3.  R3 receives VPNv4 route 1.1.1.1/32 and new label 2.

 R1-eBGP- VPNv4-R2-iBGP VPNv4-R3







 ___
>>> BESS mailing list
>>> BESS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/bess
>>>
>> --
>>
>> Gyan S. Mishra
>>
>> IT Network Engineering & Technology
>>
>> Verizon Communications Inc. (VZ)
>>
>> 13101 Columbia Pike
>> 
>> FDC1 3rd Floor
>>
>> Silver Spring, MD 20904
>>
>> United States
>>
>> Phone: 301 502-1347
>>
>> Email: gyan.s.mis...@verizon.com
>>
>> www.linkedin.com/in/networking-technologies-consultant
>>
>> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com

www.linkedin.com/in/networking-technologies-consultant
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8277

[Gyan Mishra]

With option b since the LSP is segmented into 3 segments

Left side Rx to R1 -ibgp
Middle R1 to R2 - ebgp vpnv4
Right side R2 to R3 - ibgp

So for the LSP to be segmented in opt b for it to work properly what is
required is either next-hop-self on the ibgp peer so the rewrite happens
forcing the label to change so the lsp is segmented on left side and right
side from the middle.  The reason also for the segmentation in opt B is we
are not importing the  SP loops between each other as done with opt c so
the segmentation of the lsp has to happen for opt b to work.

If you are doing this on Cisco XR it requires next hop static /32  route
for MPLS forwarding to happen on the ebgp vpnv4 session where with XE
automatically installs “MPLS forwarding” when ebgp vpnv4 is configured.

If the rewrite is not happening to segment the lsp generate a new label
then sounds like you are hitting a big.

The inter as opt a b c ab are all IETF standards and the functionality and
behavior should be the same across all vendors.

Cheers,

Gyan

On Thu, Dec 12, 2019 at 11:55 AM Robert Raszuk  wrote:

> /* replacing IETF mailer with BESS */
>
> Hi Michael,
>
> Clearly you have discovered a bug in first implementation. Second
> implementation "other platform" works correctly.
>
> I assume you are doing next hop self on R2. Advertising labels have only
> local significance to a box which is listed as next hop in the NLRIs.
>
> Btw this behaviour did not really change from original RFC3107 so it is
> quite surprising you would still be running into such issues.
>
> Thx,
> R.
>
> On Thu, Dec 12, 2019 at 5:27 PM michael walden 
> wrote:
>
>>
>> Regarding RFC 8277 Section 3.2.2
>> 3.2.2.  When the Next Hop Field Is Changed
>>
>>If the Network Address of Next Hop field is changed before a SAFI-4
>>or SAFI-128 route is propagated, the Label field(s) of the propagated
>>route MUST contain the label(s) that is (are) bound to the prefix at
>>the new next hop.
>>
>>
>> "the Label field(s) of the propagated route MUST contain the label(s)
>> that is (are) bound to the prefix at the new next hop."
>>
>> This specification should apply when the next hop field of the route is
>> changed by any means such as route map, route policies, or next-hop-self
>> and propagated?
>>
>> I've experienced differing behaviors between platforms as to whether or
>> not a the label is changed when the next hop field is changed with a route
>> map or route policy.
>>
>> For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32
>> with label 1 from R1.  R2 changes the next hop field with an outbound route
>> policy but doesn't replace the label before propagating the route to R3.
>> R3 receives VPNv4 route 1.1.1.1/32 and original label 1 breaking the LSP..
>>
>> R1-eBGP- VPNv4-R2-iBGP VPNv4-R3
>>
>>
>> However on other platforms inter-as option b R2 receives VPNv4 route
>> 1.1.1.1/32 with label 1 from R1.  R2 changes the next hop field with an
>> outbound route policy and does replace the label before propagating the
>> route to R3.  R3 receives VPNv4 route 1.1.1.1/32 and new label 2.
>>
>> R1-eBGP- VPNv4-R2-iBGP VPNv4-R3
>>
>>
>>
>>
>>
>>
>>
>> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: gyan.s.mis...@verizon.com

www.linkedin.com/in/networking-technologies-consultant
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] RFC 8277

[Robert Raszuk]

/* replacing IETF mailer with BESS */

Hi Michael,

Clearly you have discovered a bug in first implementation. Second
implementation "other platform" works correctly.

I assume you are doing next hop self on R2. Advertising labels have only
local significance to a box which is listed as next hop in the NLRIs.

Btw this behaviour did not really change from original RFC3107 so it is
quite surprising you would still be running into such issues.

Thx,
R.

On Thu, Dec 12, 2019 at 5:27 PM michael walden 
wrote:

>
> Regarding RFC 8277 Section 3.2.2
> 3.2.2.  When the Next Hop Field Is Changed
>
>If the Network Address of Next Hop field is changed before a SAFI-4
>or SAFI-128 route is propagated, the Label field(s) of the propagated
>route MUST contain the label(s) that is (are) bound to the prefix at
>the new next hop.
>
>
> "the Label field(s) of the propagated route MUST contain the label(s) that
> is (are) bound to the prefix at the new next hop."
>
> This specification should apply when the next hop field of the route is
> changed by any means such as route map, route policies, or next-hop-self
> and propagated?
>
> I've experienced differing behaviors between platforms as to whether or
> not a the label is changed when the next hop field is changed with a route
> map or route policy.
>
> For example below inter-as option b R2 receives VPNv4 route 1.1.1.1/32
> with label 1 from R1.  R2 changes the next hop field with an outbound route
> policy but doesn't replace the label before propagating the route to R3.
> R3 receives VPNv4 route 1.1.1.1/32 and original label 1 breaking the LSP.
>
> R1-eBGP- VPNv4-R2-iBGP VPNv4-R3
>
>
> However on other platforms inter-as option b R2 receives VPNv4 route
> 1.1.1.1/32 with label 1 from R1.  R2 changes the next hop field with an
> outbound route policy and does replace the label before propagating the
> route to R3.  R3 receives VPNv4 route 1.1.1.1/32 and new label 2.
>
> R1-eBGP- VPNv4-R2-iBGP VPNv4-R3
>
>
>
>
>
>
>
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess