Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

[Eric C Rosen <[e-mail]>]

On 5/21/2017 3:58 PM, Lou Berger wrote:
>
> Overall I support this document being published, but after addressing
> some comments, most importantly the first one:
>
> 1. I think this document needs to cover its impact on RF5566.  My
> personal preference is for this document to subsume/obsolete 5566, but
> the types defined in 5566 shouldn't be lost. (BTW I previously provided
> authors with text to allow this draft to obsolete 5566 as well, and can
> do so to the list if it would be helpful.)

It is true that this document orphans RFC 5566 by obsoleting a document 
on which 5566 has a normative dependency.  However, incorporating the 
security-related material from 5566 in a way that makes it useful is 
going to be a fair amount of work, and the rest of the document 
shouldn;'t be held up waiting for that.  If you have some simple and 
non-controversial text to suggest, let's consider it.  (I checked my old 
emails on this topic but couldn't find it.)

>
> 2. WRT the Encapsulation Extended Community.  I find the following rule
> very hard to parse:
>
>        A Tunnel Encapsulation attribute MUST NOT include a barebones
>        Tunnel TLV.  Instead of placing such a TLV in the Tunnel
>        Encapsulation attribute attached to a particular route, the
>        corresponding Encapsulation Extended Community MUST be attached to
>        the route.
>
> Are you saying the extended community MUST be "barebones".  If so, I
> agree as this matches 5512 formatting.  If you want this extended
> community to carry sub-tlv information, then I see no backwards
> compatibility basis for this and don't support this.  Either way, I
> think this rule needs to be clarified.

I'm not sure I understand what you are objecting to.  An extended 
community cannot carry sub-TLVs.

A number of existing applications exist that use the Encapsulation EC to 
specify a tunnel type, with no parameters.  The above-quoted paragraph 
attempts to encourage backwards compatibility with those applications by 
saying that if you want to specify a single tunnel type with no 
parameters, use the Encapsulation EC.  The Tunnel Encaps attribute would 
be used whenever the Encapsulation EC  is not sufficient.

>
> 3. I'm not sure why the color sub-tlv is still needed. why not just use
> the Color Extended Community alone?  (Is there really a case where the
> recursive lookup in section 7 would have a different color?)

The color sub-TLV is per-tunnel, the color EC is per route.  You could 
have multiple tunnels to a given endpoint, each with a different color.

>
> 4. In section 12.4, values should be defined by this document fo the
> newly established Tunnel Encapsulation Attribute Sub-TLVs registry.

I am under the impression that the preferred procedure is for the values 
to be assigned by IANA, not by the drafts.

>
> 5. Nit: the document says "This document deprecates the Encapsulation
> SAFI (which has never been used)".  The use part of this statement isn't
> strictly true as it can be found implemented in FRRouting (a fork of
> quagga). This said, I fully support its depreciation and look forward to
> submitting the patch that will remove it!  Just drop the two never used
> comments.

Since you are looking forward to removing the Encapsulation SAFI, I 
guess it is safe to say that there is no production deployment of it.  
If that's the case, I think "never used" is accurate.