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

[Linda Dunbar <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, July 10, 2018 10:00 AM
To: Linda Dunbar <[e-mail]>; [e-mail]; [e-mail]
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,

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?

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?



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

Therefore we think SAFI 7 should be reserved.

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