Hi Aman,

> I am a little bit confused by your response below. What I'll do is send a more
> detailed description of what routes I expect to see with VRFs -- both for
> ingress traffic (coming from the CEs), and egress traffic (going to the CEs).

It might be how GoBGP or FRRouting/Zebra learned routes to CEs, you said we need
also advertise routes to CEs? In other words, GoBGP need to advertise 2 routes
(CE to VRF and VRF to MPLS-NW) per MPLS VPN path?

Thanks,
Iwase

On 2018年02月09日 01:45, SHAIKH, AMAN  (AMAN) wrote:

Hi Iwase

I am a little bit confused by your response below. What I'll do is send a more 
detailed description of what routes I expect to see with VRFs -- both for 
ingress traffic (coming from the CEs), and egress traffic (going to the CEs).

aman

-----Original Message-----
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Wednesday, February 7, 2018 9:42 PM
To: SHAIKH, AMAN (AMAN) <asha...@research.att.com>
Cc: gobgp-devel@lists.sourceforge.net
Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes

Hi Aman,

Thank you for your explanation!
It is so helpful for me!


  > Given this, if I want to add vrf blue, I will use the following gobgp 
command:
  > gobgp vrf add blue id 6 <rest_of_the_parameters>

I understood the VRF ID on Zebra has the same value with the nexthop interface 
index and users are required to create GoBGP's VRF with the same VRF ID.


  > Given this, if we assume that a GoBGP user will supply appropriate VRF ID  > 
during configuration (through gobgp CLI), what will it take to make GoBGP adds  > a 
route for incoming MPLS packets in the default routing table? The route, as  > I 
mentioned in my previous post, should look something like this:
  > <vrf_label> dev <vrf_name>
  >
  > So, for the above example, if GoBGP assigns a label of 16 to VRF blue, then  
> the route will be:
  > 16 dev blue

With the current implementation, GoBGP always send routes with the IP address 
nexthops even with the VPN routes.
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osrg_gobgp_blob_5322e63522e9320bc460f5a68538d24d11c5a0ef_server_zclient.go-23L241-2DL249&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=OWyrO4MdO4DzrKZnT5ArsDvwEeJj3zbXtSaHVhiiCDA&s=FH80CVHhUgekpdUL5H18O9rhGuTKZM1sDMIvJ6e3qR8&e=

But, you mean the VPN routes' nexthop should be specified as the interfaces, 
right? For example, the current implementation will issue:
<vrf_label> via <nexthop address>

For example, the following patch replaces the IP address nexthop addresses by 
the interface indexes. Might be too rough way though...

$ git diff
diff --git a/zebra/zapi.go b/zebra/zapi.go index f86e39a..3d8efb1 100644
--- a/zebra/zapi.go
+++ b/zebra/zapi.go
@@ -782,12 +782,20 @@ func (c *Client) SendIPRoute(vrfId uint16, body 
*IPRouteBody, isWithdraw bool) e
                                  command = FRR_IPV4_ROUTE_DELETE
                          } else {
                                  command = FRR_IPV4_ROUTE_ADD
+                               if vrfId != 0 {
+                                       body.Nexthops = nil
+                                       body.Ifindexs = []uint32{uint32(vrfId)}
+                               }
                          }
                  } else {
                          if isWithdraw {
                                  command = FRR_IPV6_ROUTE_DELETE
                          } else {
                                  command = FRR_IPV6_ROUTE_ADD
+                               if vrfId != 0 {
+                                       body.Nexthops = nil
+                                       body.Ifindexs = []uint32{uint32(vrfId)}
+                               }
                          }
                  }
                  if body.Tag != 0 {


Thanks,
Iwase


On 2018年02月08日 01:04, SHAIKH, AMAN  (AMAN) wrote:

Hi Iwase

Thanks for the explanation. You're right that GoBGP does not automatically use 
the VRF ID that FRR/Zebra (or more precisely the Linux Kernel) uses for a given 
VRF name. What I do is that while adding a VRF to GoBGP through command-line, I 
make sure to use the same ID that Linux kernel and FRR/Zebra uses.

For example,

In Linux/kernel:
[ashaikh@vsp-vpe-east:~]$ ip link
...<snip>...
6: blue: <NOARP,MASTER,UP,LOWER_UP> mtu 65536 qdisc noqueue state UP mode 
DEFAULT group default qlen 1000
      link/ether 92:6d:bc:8c:55:e6 brd ff:ff:ff:ff:ff:ff

The '6' above serves as the VRF-id.

FRR/Zebra uses the same id as can be seen below:
vsp-vpe-east# show vrf
vrf blue id 6 table 1

Given this, if I want to add vrf blue, I will use the following gobgp command:
gobgp vrf add blue id 6 <rest_of_the_parameters>

Once I use the correct vrf-id, gobgp is able to resolve next-hops with FRR/Zebra for VRF routes (due to 
the change that was added with this commit -- 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osrg_gobgp_commit_e36879ff7b8d9f42491766951cdff91b7f3812fd&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=OWyrO4MdO4DzrKZnT5ArsDvwEeJj3zbXtSaHVhiiCDA&s=Nm_2QERvj3N4VLhOWGjuHkYbl7P55C3EJxGVf5B2IKg&e=
 ).

Given this, if we assume that a GoBGP user will supply appropriate VRF ID 
during configuration (through gobgp CLI), what will it take to make GoBGP adds 
a route for incoming MPLS packets in the default routing table? The route, as I 
mentioned in my previous post, should look something like this:

<vrf_label> dev <vrf_name>

So, for the above example, if GoBGP assigns a label of 16 to VRF blue,
then the route will be:  16 dev blue

thx
aman

-----Original Message-----
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Tuesday, February 6, 2018 7:09 PM
To: SHAIKH, AMAN (AMAN) <asha...@research.att.com>
Cc: gobgp-devel@lists.sourceforge.net
Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes

Hi Aman,

Hmmmm...

I didn't understand the mechanism of VRFs on FRR and how to configure VRFs for 
the MPLS routing on FRR, so the following is just guessing...
If need to install any route into the specific VRF on Zebra, GoBGP should send Zebra 
message with VRF ID of "Zebra side". Currently, GoBGP assigns a new VRF ID 
independently from Zebra's assignment.

Current:
         GoBGP              Zebra
AddVrf  |                  |
------->| Request Labels   |
           |----------------->|
           | Allocated Labels |
           |<-----------------|
           |                  |
AddPath |                  |
------->| Add Route with   |
           | "GoBGP's" VRF ID |
           |----------------->| !!No such VRF ID!!
           |                  |

Required:
         GoBGP              Zebra
           |                  | Add VRF (via vtysh?)
           | Call AddVrf with |<--------------------
           | "Zebra's" VRF ID |
           |<-----------------|
           | Request Labels   |
           |----------------->|
           | Allocated Labels |
New VRF |<-----------------|
           |                  |
AddPath |                  |
------->| Add Route with   |
           | "Zebra's" VRF ID |
           |----------------->|
           |                  |


Thanks,
Iwase


On 2018年02月07日 08:26, SHAIKH, AMAN  (AMAN) wrote:

Hi Iwase

I checked latest patch in the
zclient-Enable_to_request_MPLS_label_range branch of your gobgp fork.
It works as expected. See

[ashaikh@vsp-vpe-west ~]$ gobgp global rib -a vpnv4
      Network              Labels     Next Hop             AS_PATH              
Age        Attrs
*> 100:1:192.168.0.0/24 [16]       10.200.0.2           65001                
00:10:49   [{Origin: i} {Med: 0} {Extcomms: [100:1]}]

I have a follow-up question though. I don't see any route in the default MPLS 
FIB which instructs Linux kernel to direct incoming traffic with label 16 to be 
forwarded to the blue VRF (or appropriate table-id). I'd expect to see 
something akin to this.

[ashaikh@vsp-vpe-west ~]$ ip -f mpls route
16 dev blue                                                          <= 
expected entry for the route above...

I believe that to achieve this, you will have to push such an MPLS route to the 
Zebra daemon. Let me know your thoughts.

thx
aman

-----Original Message-----
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Monday, February 5, 2018 11:06 PM
To: SHAIKH, AMAN (AMAN) <asha...@research.att.com>
Cc: gobgp-devel@lists.sourceforge.net
Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes

Hi Aman,

Hmmmm... it might be complicated some though, how about the following?
With "mpls-label-range-size = 1" option, GoBGP should request a MPLS allocation 
every time when adding VRF.
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_iwase
y
usuke_gobgp_compare_master...iwaseyusuke-3Azclient-2DEnable-5Fto-5Fre
q
uest-5FMPLS-5Flabel-5Frange&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2Um
L
83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=TdGJjOKuBMLxHOPXehiGl4RRoFxfL
c 4RqJAkSHslcKg&s=rZVh23aOLleOYpYr_kFWlQkzupE8ATC0NTlkhVa-Ucw&e=

Thanks,
Iwase

On 2018年02月06日 02:00, SHAIKH, AMAN  (AMAN) wrote:
Hi Iwase

Thanks for your patch. I will try out the patch in a day or two and let you 
know how things go.

I have one suggestion though. The current patch asks zebra client ***only 
once*** for a label allocation of configured size. Couldn't this be enhanced 
where GoBGP can ask for more chunks of labels if it runs out of the most recent 
chunk? This will be a more complete solution in my opinion.

thanks again for working on this Iwase...

aman


-----Original Message-----
From: Iwase Yusuke [mailto:iwase.yusu...@gmail.com]
Sent: Sunday, February 4, 2018 11:42 PM
To: SHAIKH, AMAN (AMAN) <asha...@research.att.com>
Cc: gobgp-devel@lists.sourceforge.net
Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes

Hi Aman,

With the following patches, I could get the allocated MPLS label range from 
FRR/Zebra and assign a MPLS label per VRF.
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_osrg
_
g
obgp_compare_master...iwaseyusuke-3Azclient-2DEnable-5Fto-5Frequest-
5
F
MPLS-5Flabel-5Frange&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQf
O
E
oCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=a8uZ5z9JfpkdyduLAq0G3l3bbd-0glNdqNK
i E gMSu1U&s=lr7g09z0VZHzzbXuGw4IbW25nKsXwZLGTEDmhoSZZTk&e=

```toml
[zebra.config]
       enabled = true
       url = "unix:/var/run/frr/zserv.api"
       redistribute-route-type-list = ["connect"]
       version = 4
       mpls-label-range-size = 100
```

$ gobgp vrf add VRF_A rd 65000:100 rt both 65000:100 $ gobgp vrf VRF_A rib add 
10.0.0.0/24 # "16" is MPLS label value which FRR/Zebra allocated $ gobgp global 
rib -a vpnv4
        Network               Labels     Next Hop             AS_PATH
Age        Attrs
*> 65000:100:10.0.0.0/24 [16]       0.0.0.0
00:00:00   [{Origin: ?} {Extcomms: [65000:100]}]

Could you try this patches?

Thanks,
Iwase


On 2018年02月05日 10:31, Iwase Yusuke wrote:
Hi Aman,


     > Thanks for the pointer. Can GoBGP communicate with FRR/Zebra
for label  > assignment instead of assigning a label of 0 to VPNv4 routes?

Currently, GoBGP does not have the feature to request the label
allocation to FRR/Zebra, also the message implementation to send requests.
FYI, FRR/BGPd also does not have such:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FRR
o
u
t
ing_frr_issues_1207&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQf
O
E
o
CVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=a8uZ5z9JfpkdyduLAq0G3l3bbd-0glNdqNK
i E g MSu1U&s=0FBImI3HgUJTVr5jHMwYcIY10fri5S7OpdbBrFNm_1Q&e=


     > One possibility is to communicate with FRR/Zebra at the time
of VRF creation  > and deletion for label allocation and freeing respectively?

I read some FRR/Zebra code, Zebra client should send request to
allocate MPLS label as a chunk of MPLS label range, not per VRF create and 
deletion.
We need to some more implementation if need to support this feature.


Thanks,
Iwase


On 2018年02月01日 00:23, SHAIKH, AMAN  (AMAN) wrote:

Hi Fujita

-----Original Message-----
From: FUJITA Tomonori [mailto:fujita.tomon...@gmail.com]
Sent: Tuesday, January 30, 2018 6:38 PM
To: SHAIKH, AMAN (AMAN) <asha...@research.att.com>
Cc: gobgp-devel@lists.sourceforge.net
Subject: Re: [GoBGP-devel] MPLS label issue with VPNv4 routes

Hi,

2018-01-31 0:02 GMT+09:00 SHAIKH, AMAN  (AMAN) <asha...@research.att.com>:


As on my previous mail, sorry I don't know why this PR was not accepted...

GoBGP had the feature to allocate vpn labels but it was removed.

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_o
s
r
g
_g
obgp_commit_c7653aa9d4276098a7a6b5ade5ffce5bf5d089e8&d=DwIFaQ&c=L
F
Y
Z
-o
9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=
7
V
c
8Y
RSyefU_kBjFkPq3yBYho_aHr7X9aghZ6ZihzSk&s=MTpXR6wkh_EDImcmDx-f18aa
4
n
h
lT
Pz1PrhPbJ-oXYI&e=

I assume that there is a label allocation component out of GoBGP.
For example, if you create MPLS VPN, you needs two types of
labels, vpn label, and mpls label.
GoBGP needs to work with ldpd to avoid using the same label.

-> The VPN label needs to be allocated by GoBGP. And this label
-> can be same
as the PE (i.e., MPLS) label. It would be great if you can add
the label allocation and assignment component back into GoBGP.
Without this, it's impossible to use GoBGP with VPNv(4|6) and BGP-LU NLRIs.

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_FR
R
o
u
ting_frr_blob_master_zebra_label-5Fmanager.c&d=DwIFaQ&c=LFYZ-o9_HU
M
e
M
TSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=yeOT6hlw
H
b
4
kNO7lFNfwiwLIf-w7HvCWRF0ciwQ4a6U&s=yYPnxj35T53xtHwdhn1kQ1X2NUdDnZH
N
w
B
NnmUMeQIo&e=


As frr does, label users (including bgpd) ask a label manager to
allocate / free a label. I think that it's the appropriate approach.

--> Thanks for the pointer. Can GoBGP communicate with FRR/Zebra
--> for label
assignment instead of assigning a label of 0 to VPNv4 routes? One
possibility is to communicate with FRR/Zebra at the time of VRF
creation and deletion for label allocation and freeing respectively?


aman

2018-01-29 16:04 GMT+09:00 Iwase Yusuke <iwase.yusu...@gmail.com>:
Hi Aman,

As on my previous mail, sorry I don't know why this PR was not accepted...

But, your suggestion is reasonable to me.
How about the following patches?
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_
o
s
r
g_
g
obgp_compare_master...iwaseyusuke-3Aserver-2DAuto-5FMPLS-5Flabel
-
5
F
as
s
ignment-5Fon-5FVRF&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83H
Q
f
O
Eo
C
VzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=7Vc8YRSyefU_kBjFkPq3yBYho_aHr7X9a
g h Z 6Z i hzSk&s=NNBfvxFq2jodV04XmJD6uWtmUTkXfltpjRFKYgUJ-sY&e=

The first patch does not directly fix this issue, but is
convenient to update neighbor settings, and with the second one,
you can configure VRF like;

# Configure VRFs on router "10.0.0.1" (r1)
r1> gobgp vrf add blue rd 65000:100 rt both 65000:100 gobgp vrf
r1> add red rd 65000:200 rt both 65000:200 gobgp neighbor update
r1> 10.0.0.2 vrf blue gobgp neighbor update 10.0.0.3 vrf red

# Add a prefix on router "10.0.0.2" (r2)
r2> gobgp global rib -a ipv4 add 192.168.1.0/24 gobgp global rib
r2> -a
r2> ipv4
        Network              Next Hop             AS_PATH Age
Attrs *> 192.168.1.0/24       0.0.0.0
00:00:00
[{Origin: ?}]

# Add the same prefix on router "10.0.0.3" (r3)
r3> gobgp global rib -a ipv4 add 192.168.1.0/24 gobgp global rib
r3> -a
r3> ipv4
        Network              Next Hop             AS_PATH Age
Attrs *> 192.168.1.0/24       0.0.0.0
00:00:00
[{Origin: ?}]

# Show VPN routes on r1
r1> gobgp global rib -a vpnv4
        Network                  Labels     Next Hop AS_PATH  Age
Attrs *> 65000:100:192.168.1.0/24 [1000]     10.0.0.2
00:00:00   [{Origin: ?}
{LocalPref: 100} {Extcomms: [65000:100]}] *>
65000:200:192.168.1.0/24 [1001]     10.0.0.3 00:00:00   [{Origin:
?}
{LocalPref: 100} {Extcomms: [65000:200]}]

Thanks,
Iwase



On 2018年01月27日 06:28, SHAIKH, AMAN  (AMAN) wrote:

Hi Iwase

--> I looked at the PR in some detail. Seems quite reasonable
--> to me in
terms of changes. Do you know the reason why it was not accepted?

FYI, the auto assignment feature seems to be posted, but not merged.
(sorry, I don't know why...)

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com
_
o
s
rg
_
gobgp_pull_366&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfO
E
o
C
Vz
C
hS_fiJdy8vxHF4_JM0AhcKK4Y&m=XsNqliUbM-wXJ4BIRg17Ql3I4zlbKtrslZX
u w i iS S j0&s=BuzaMx-UPDZUk8TQkyyyrRJMDX5faq5YG3mVHMetuLs&e=

thx
aman

---------------------------------------------------------------
-
-
-
--
-
--------- Check out the vibrant tech community on one of the
world's most engaging tech sites, Slashdot.org!
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_sl
a
s
h
do
t
&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy
8
v
x
HF
4
_JM0AhcKK4Y&m=7Vc8YRSyefU_kBjFkPq3yBYho_aHr7X9aghZ6ZihzSk&s=ZKS
x l J kc a P-nUGEu2yJmVbKJfB2tr5-jz2ILYgjv300&e=
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sour
c
e
f
or
g
e.net_lists_listinfo_gobgp-2Ddevel&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQi
c
v
j
Ig
&
r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=7Vc8YRSyefU_kBj
F
k
P
q3
y
BYho_aHr7X9aghZ6ZihzSk&s=aHmtUI0UsXL4J3DAQXvNeholruVqcnCoSMjhNN
6
s
R
Ws
&
e=


----------------------------------------------------------------
-
-
-
--
-
-------- Check out the vibrant tech community on one of the
world's most engaging tech sites, Slashdot.org!
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_sla
s
h
d
ot
&
d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8v
x
H
F
4_
J
M0AhcKK4Y&m=7Vc8YRSyefU_kBjFkPq3yBYho_aHr7X9aghZ6ZihzSk&s=ZKSxlJ
k
c
a
P-
n
UGEu2yJmVbKJfB2tr5-jz2ILYgjv300&e=
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourc
e
f
o
rg
e
.net_lists_listinfo_gobgp-2Ddevel&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicv
j
I
g
&r
=
I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=7Vc8YRSyefU_kBjFkP
q
3
y
BY
h
o_aHr7X9aghZ6ZihzSk&s=aHmtUI0UsXL4J3DAQXvNeholruVqcnCoSMjhNN6sRW
s
&
e
=

aman
------------------------------------------------------------------
-
-
-
--------- Check out the vibrant tech community on one of the
world's most engaging tech sites, Slashdot.org!
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slash
d
o
t
&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vx
H
F
4
_JM0AhcKK4Y&m=a8uZ5z9JfpkdyduLAq0G3l3bbd-0glNdqNKiEgMSu1U&s=BBVDLw
6
6
0 juZnrLPKS1kIFaB2_HV34rj6zDYJyZOe3U&e=
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourcef
o
r
g
e.net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvj
I
g
&
r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=a8uZ5z9JfpkdyduLAq
0
G
3
l3bbd-0glNdqNKiEgMSu1U&s=P0epHjnmGV3uE28Rfi1Qg7FQVYzWUhc8nkqaq_br6
i
I
&
e=

--------------------------------------------------------------------
-
-
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org!
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdo
t
&
d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4
_
J
M0AhcKK4Y&m=TdGJjOKuBMLxHOPXehiGl4RRoFxfLc4RqJAkSHslcKg&s=8wrxv3qSSE
Z
K
XvD16KqNTTT_0Mwc2J95BbEVCp0EiCM&e=
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourcefor
g
e
.net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&
r
=
I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=TdGJjOKuBMLxHOPXehiGl4
R
R
oFxfLc4RqJAkSHslcKg&s=SoQIHnhhY7WMLVMHINZWoZVwQ0eM2U8WvcX_eFJpcSk&e=

---------------------------------------------------------------------
-
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org!
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot
&
d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_
J
M0AhcKK4Y&m=0fmKvlo4YvTCaRurGsgaRq3XX1x4mGRadWtdfFSuPrQ&s=bUzIDRxhhG4
G
99Z5iTwUEqRhGkncXqio1dqNXEuqyak&e=
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforg
e
.net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r
=
I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=0fmKvlo4YvTCaRurGsgaRq3
X
X1x4mGRadWtdfFSuPrQ&s=jwS6SAQjlMYyJc6j9kZA7nSxhGV8SkNytyEb7mhLnRU&e=

----------------------------------------------------------------------
-------- Check out the vibrant tech community on one of the world's
most engaging tech sites, Slashdot.org!
https://urldefense.proofpoint.com/v2/url?u=http-3A__sdm.link_slashdot&;
d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_J
M0AhcKK4Y&m=OWyrO4MdO4DzrKZnT5ArsDvwEeJj3zbXtSaHVhiiCDA&s=AOYGKl201Ra5
37lA_bFMLczxCvlf3g0Iny7dv0LRGg8&e=
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge
.net_lists_listinfo_gobgp-2Ddevel&d=DwIDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=
I_2UmL83HQfOEoCVzChS_fiJdy8vxHF4_JM0AhcKK4Y&m=OWyrO4MdO4DzrKZnT5ArsDvw
EeJj3zbXtSaHVhiiCDA&s=YPL7bLCPzaAhhG9vUvtKmUtWypAahqPBk2XluiMzWtY&e=

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gobgp-devel


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
gobgp-devel mailing list
gobgp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gobgp-devel

Reply via email to