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

Hi Linda,

In addition to your comment what needs to also be highlighted in bold is
that new SAFI will help the co-existence with number of existing SD-WAN
deployments. Loading currently deployed controllers with any of the
existing unicast SAFIs no matter how well filtered will not be a great idea
operationally.

The point about missing DTLS has been communicated to Eric the same day his
and Ron's draft got posted. It was accepted well :).

Best,
R.

On Mon, Jul 9, 2018 at 11:34 PM, Linda Dunbar <linda.dunbar@huawei.com>
wrote:

> Thanks Robert’s suggesting of having a new ARI/SAFI for SD-WAN.
>
>
>
> An independent SAFI for SD-WAN would make our implementation easier. In
> addition in SD-WAN deployment the RR and CPE might be connected by
> TLS/DTLS.
>
>
>
> Linda
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, July 09, 2018 4:29 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>
> *Cc:* 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 ?
>
>
>
> IMO both are needed.
>
>
>
> The original drivers for tunnel encapsulation attribute clearly proved
> that new SAFI is an excessive thing. Please note that in any SAFI you can
> easily craft independent BGP MSG without need for separate AFI/SAFI type.
>
>
>
> Said this however for the SD-WAN application we are discussing here I
> would be actually in favor of separating it from any other BGP use by
> dedicating a new AFI/SAFI for it.
>
>
>
> Thx,
> R.
>
>
>
> On Mon, Jul 9, 2018 at 11:20 PM, Linda Dunbar <linda.dunbar@huawei.com>
> wrote:
>
> That is one of the main reason we think it is better to have a dedicated
> message to pass “Tunnel Encap attributes” instead of appended to the BGP
> update message.
>
> It is so much easier for CPEs to process an Independent “tunnel attribute”
> information instead of filtering out which field can/can’t be distribute to
> others.
>
>
>
> Linda
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Monday, July 09, 2018 4:13 PM
> *To:* Linda Dunbar <linda.dunbar@huawei.com>
> *Cc:* Jeff Tantsura <jefftant.ietf@gmail.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 ?
>
>
>
>
>
> Because the NO_ADVERTISE is about the property of the NLRI - entire BGP
> UPDATE MSG get's blocked while in section 10 it is about just dropping a
> single attribute which happened to be attached to a perhaps still valid
> UPDATE MSG.
>
>
>
>
>
>
>
> On Mon, Jul 9, 2018 at 11:05 PM, Linda Dunbar <linda.dunbar@huawei.com>
> wrote:
>
> Eric,
>
>
>
> Why not using “NO_ADVERTISE” in the Section 10 of
> draft-ietf-idr-tunnel-encaps-09?
>
>
>
>
>
> 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 <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
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>