Subject: [Idr] What are side effect for having Encap SAFI? can draft-ietf-idr-tunnel-encaps-09 preserve trigger tunnel creation before VPN is established?

From: Linda Dunbar <[email-masked]>
Date: Mon, 2 Jul 2018 22:31:51 +0000

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

From: Linda Dunbar
Sent: Friday, June 29, 2018 2:54 PM
To: 'Eric C Rosen' <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]' <[email-masked]>
Subject: Can draft-ietf-idr-tunnel-encaps-09 trigger tunnel creation before VPN is established?

Eric,

Thank you very much for the reply.
Can draft-ietf-idr-tunnel-encaps-09 trigger tunnel creation before VPN is established?
For example, having RR sending down the Encap extended community to both end points of a tunnel? Instead of tunnel's one end point to send to others?

Thank you very much.

Linda Dunbar

From: Eric C Rosen [mailto:[email-masked]]
Sent: Tuesday, June 26, 2018 2:28 PM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Questions to RFC5512: Encapsulation sub-TLV and Opaque extended community to indicate the Encapsulation protocol?

I think it would be better if you looked at draft-ietf-idr-tunnel-encaps instead of RFC 5512.  The draft has passed WG LC, and if it ever gets sent to the IESG, it will obsolete RFC 5512.
On 6/26/2018 1:56 PM, Linda Dunbar wrote:
BGP experts:

If the RFC5512 has "distinguished SAFI value" and "the Encapsulation SAFI". Do those two terms have the same meaning?
The Section 3 of RFC5512 has SAFI value of 7 to represent Encapsulation SAFI.

Does it mean that the "distinguished SAFI value" is just "7" for speaker to advertise its supported Tunnel information?

Yes, per RFC 5512 the Tunnel Encapsulation attribute can only be carried on UPDATEs of SAFI 7.

Draft-ietf-idr-tunnel-encaps deprecates this SAFI, and explicitly allows the Tunnel Encapsulation attribute to be carried on UPDATEs whose AFI/SAFI is 1/1, 1/4, 2/4, 1/128, 2/128, and 25/70.  Use of the attribute on other AFI/SAFIs is outside the scope of the draft.

The Section 4 goes on defining the Tunnel Encapsulation Type (such as L2TPv3 with Type =1; etc), and a list of sub-TLVs, one of the SubTLV is Protocol Type (section 4.2) which can be used to represent the Encapsulation Protocol (i.e. protocol type of data frames carried by the tunnel)

Just to be clear, the Protocol Type sub-TLV identifies the protocol type of the payload.  If a Protocol Type sub-TLV identifying "IPv4" appears inside a Tunnel Type of "GRE", the meaning is that IPv4 packets may be carried inside a GRE tunnel.

Why need the Opaque extended community to indicate the Encapsulation protocol?

Well, the argument was "I just want to indicate that packets directed to a given prefix need to be encapsulated in GRE.  I don't want to have to use a new SAFI to say that, all it takes is putting a community on the UPDATE that mentions that prefix in its NLRI".  That's fine as long as you don't want to convey any additional information about how to construct the encapsulation.  In practice, people have invented additional extended communities to carry information that should have been carried in the Tunnel Encapsulation attribute, in order to avoid the use of SAFI 7.

This extended community is not really necessary when draft-ietf-idr-tunnel-encaps is used, but it is preserved for backwards compatibility purposes; see section 4.5 of that draft.

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 3 Jul 2018 13:21:03 -0400

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

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.