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