[Idr] Can draft-ietf-idr-tunnel-encaps-09 trigger tunnel creation before VPN is established?

[Linda Dunbar <[e-mail]>]

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:[e-mail]]
Sent: Tuesday, June 26, 2018 2:28 PM
To: Linda Dunbar <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
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?

[cid:image001.png@01D40FB8.F71AE100]

[cid:image002.png@01D40FB8.F71AE100]



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.