Re: [Idr] Questions to RFC5512: Encapsulation sub-TLV and Opaque extended community to indicate the Encapsulation protocol?

["Susan Hares" <[e-mail]>]

Eric and Linda: 

 

I agree with Eric.  The draft-ietf-idr-tunnel-encaps has past WG LC, and it
is awaiting a second implementation. 

 

Sue 

 

PS - Linda, I've sent a more detailed message to you directly.  

 

From: Idr [mailto:[e-mail]] On Behalf Of Eric C Rosen
Sent: Tuesday, June 26, 2018 3:28 PM
To: Linda Dunbar; [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?

 



 



 

 


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.