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

From: Linda Dunbar <[email-masked]>
Date: Mon, 9 Jul 2018 20:13:42 +0000

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:[email-masked]]
Sent: Tuesday, July 03, 2018 12:21 PM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
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.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 10 Jul 2018 10:59:34 -0400

If you want a controller to use BGP to convey instructions for a 
particular node, there is a draft that does something very similar: 
draft-ietf-idr-segment-routing-te-policy.  That draft defines a new 
AFI/SAFI for conveying segment routing te policies, and the policies are 
encoded as Tunnel Encapsulation attributes.  That draft does require the 
use of the NO_ADVERTISE community when an UPDATE is a command targeted 
to a single router.  The draft also allows the use of Route Targets to 
cover the case where a given  command is targeted to a set of routers, 
as well as the case where the targeted router is separated from the 
controller by a RR or ASBR.  While your application is not about 
sr-te-policies, the way a controller would use BGP to pass the commands 
to the targeted routers is similar; you should take a look.

On 7/9/2018 4:13 PM, Linda Dunbar wrote:
>
> Eric,
>
> draft-ietf-idr-tunnel-encaps-09 discussed ways to resolve conflicts of 
> multiple UPDATE messages with Tunnel Encap attributes.
>
> -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?
>

This is not a good idea.  If you want to verify that a particular UPDATE 
is from an authoritative source, you need a lot more than can be 
conveyed in a single bit.

> -Have a bit indicating that a specific UPDATE only contain Tunnel 
> attributes for the receiving Router, therefore can’t be forwarded?
>

Please compare draft-ietf-idr-segment-routing-te-policy, and its use of 
NO_ADVERTISE and Route Targets.

> 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.
>

It sounds like you need to write a draft proposing the specifics of how 
you would like to use BGP as part of your SD-WAN control.  The draft 
would then be free to propose a new SAFI, much as 
draft-ietf-idr-segment-routing-te-policy did.

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Jul 2018 21:59:21 +0000

Eric,

We also believe what is proposed by draft-ietf-idr-segment-routing-te-policy will be very useful for SD-WAN.
But:

-        The SAFI proposed in the draft is explicitly for SR

-        SD-WAN control will need more field than what is proposed by draft-ietf-idr-segment-routing-te-policy.

-        It might be convoluted  to expand the fields for SD-WAN purpose

Other comments/questions are inserted below:

Linda

From: Eric C Rosen [mailto:[email-masked]]
Sent: Tuesday, July 10, 2018 10:00 AM
To: Linda Dunbar <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Possible to set up priority for Tunnels established by draft-ietf-idr-tunnel-encaps-09 ?

If you want a controller to use BGP to convey instructions for a particular node, there is a draft that does something very similar: draft-ietf-idr-segment-routing-te-policy.  That draft defines a new AFI/SAFI for conveying segment routing te policies, and the policies are encoded as Tunnel Encapsulation attributes.  That draft does require the use of the NO_ADVERTISE community when an UPDATE is a command targeted to a single router.  The draft also allows the use of Route Targets to cover the case where a given  command is targeted to a set of routers, as well as the case where the targeted router is separated from the controller by a RR or ASBR.  While your application is not about sr-te-policies, the way a controller would use BGP to pass the commands to the targeted routers is similar; you should take a look.
On 7/9/2018 4:13 PM, Linda Dunbar wrote:
Eric,

This is not a good idea.  If you want to verify that a particular UPDATE is from an authoritative source, you need a lot more than can be conveyed in a single bit.
[Linda] how many bits do you think are needed?

Please compare draft-ietf-idr-segment-routing-te-policy, and its use of NO_ADVERTISE and Route Targets.

It sounds like you need to write a draft proposing the specifics of how you would like to use BGP as part of your SD-WAN control.  The draft would then be free to propose a new SAFI, much as draft-ietf-idr-segment-routing-te-policy did.

[Linda] Yes, we would like to. That is why we sent out so many questions.

Linda