Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Linda,

You meant to say – you’d use RR to distribute information injected from and by a controller?

Reflector (as the name suggests) reflects the routes, it doesn’t originates them as part of the reflector functionality  (it for sure could as a BGP speaker if such functionality is collocated with RR)

Please read my initial questions, it looks like what you are trying to achieve could be done with the existing technology.

Thanks!

Cheers,

Jeff

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, July 9, 2018 at 13:28
To: Jeff Tantsura <jefftant.ietf@gmail.com>, Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: RE: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Jeff, 

We would like to use RR as controller to distribute more detailed tunnel information, such as IPsec configuration & keys because in managed large scale Overlay deployment (SD-WAN), it doesn’t scale to allow all CPEs to negotiate IPsec keys. 

Linda

From: Jeff Tantsura [mailto:jefftant.ietf@gmail.com] 
Sent: Monday, July 09, 2018 3:25 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; Eric C Rosen <erosen@juniper.net>; idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
Subject: Re: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Hi Linda,

Why would you want to build what you are trying to do into protocol?

#1 local policy

#2  NO_ADVERTISE does that exactly 

Cheers,

Jeff

From: Idr <idr-bounces@ietf.org> on behalf of Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, July 9, 2018 at 13:14
To: Eric C Rosen <erosen@juniper.net>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Subject: [Idr] Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

Eric, 

draft-ietf-idr-tunnel-encaps-09 discussed ways to resolve conflicts of multiple UPDATE messages with Tunnel Encap attributes. 

Is it possible to have following capability? 
Have a bit indicating a specific UPDATE is from authoritative source, therefore overwrite all other Tunnel Attributes for the Prefix X to avoid recursive next hop issues and tunnel selection at the receiving Router? 
Have a bit indicating that a specific UPDATE only contain Tunnel attributes for the receiving Router, therefore can’t be forwarded? 

You said that SAFI 7 is deprecated because no one seemed interested in using it. We are very interested in using it because 
it can be easily distinguished from normal  BGP UPDATE
 The receiving router doesn’t have to “Filter” the tunnel attributes before forwarding to others.  
Can even be used for passing reconfigured IPsec keys to two ends of a tunnel. 

Therefore we think SAFI 7 should be reserved. 

Thanks, Linda Dunbar

From: Eric C Rosen [mailto:erosen@juniper.net] 
Sent: Tuesday, July 03, 2018 12:21 PM
To: Linda Dunbar <linda.dunbar@huawei.com>; idr@ietf.org; draft-ietf-idr-tunnel-encaps@ietf.org
Subject: Re: What are side effect for having Encap SAFI? can draft-ietf-idr-tunnel-encaps-09 preserve trigger tunnel creation before VPN is established?

On 7/2/2018 6:31 PM, Linda Dunbar wrote:

Eric, IDR group, 

It is indicated that RFC5512 is to be replaced by draft-ietf-idr-tunnel-encaps. But draft-ietf-idr-tunnel-encaps-09 stated that it deprecates the

Encapsulation SAFI. 

We find the Encapsulation SAFI is quite useful for CPE based EVPN.  For example, a Controller (say RR) can send an update with Encapsulation SAFI to two end points to trigger a tunnel establishment between them. 

What are side effect for having Encap SAFI? Can we preserve it in draft-ietf-idr-tunnel-encaps?

Thanks, Linda Dunbar

SAFI 7 was deprecated because no one seemed interested in using it, it creates additional operational issues, there is no real need for it, and it was discouraging folks from actually using the Tunnel Encapsulation attribute.  This is discussed briefly in section 1.2 of the draft.

You can get a similar effect by using the technique described in section 7 of the draft.

If PE1 is the egress point of a tunnel, have PE1 originate an UPDATE whose NLRI is PE1's loopback address.  Put the Tunnel Encapsulation attribute (with PE1 as remote endpoint) on this UPDATE.  (The next hop field of this UPDATE doesn't really matter, as long as it is resolvable.)  When PE1 originates VPN routes, it sets the next hop to be its loopback address.  Per section 7, this will result in packets being sent to PE1 though the specified tunnel.

_______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr 