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

[Lou Berger <[e-mail]>]

On 5/22/2017 10:51 AM, Eric C Rosen wrote:
> 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.  
Well I did make this comment ~ 2 years ago, so you shouldn't be
surprised that I'm raising it now.  I'm not saying the WG has to follow
my preferred path (of having this doc replace 5566 as well), but I think
something has to be done to not leave 5566 "orphaned".

> 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.)
my memory is that I put together a rough google doc at the time we
discussed whether your doc would deprecate 5512 or not.  (See
https://docs.google.com/document/d/1PSVTwf_QaRVWqhmkfaoRuP2JoGq_Nq9mlICUv6Z2BOQ/edit)


To have tunnel-encaps deprecate 5566 as well, I think the following is
needed:
- Include the 5566 defined tunnel types (particularly 4, 5 and 6)
- include section 3.4.1 and 3.6 from the google doc (which is just edit
text from 5566 sections 3 and 4)
- perhaps include the 2nd paragraph of the Security Considerations section

Given that the text is mostly lifted from 5566, I'd hope this qualifies
as "simple and non-controversial".


(new issue 6) In looking at the google doc, I was reminded of a
deficiency of  in 5512 that still exists in the wg draft.  Neither ever
define the format of the Tunnel TLV.  Don't you think it should?
Obviously, I do. Feel free to lift Section 3 of the google doc.

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

Perfect.  That's what I was hoping for/expecting, but I couldn't parse
your text in a way that made sense (at least to me). I also think the
current phasing goes beyond what some implementations do, e.g., send a
barebones EC all the time.

> 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.
How about replacing the quoted paragraph with:
 
   An Encapsulation Extended Community MUST be included when a barebones
   Tunnel TLV is used to identify a tunnel endpoint. The corresponding
barebones
   Tunnel Encapsulation attribute MAY be omitted in this case.

BTW our implementation always includes a "barebones" Encapsulation
Extended Community ;-)

>
>> 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.
okay, this works -- we solved this using multiple updates.   That said,
do you think the complexity of multiple tunnel tlvs in the same update
is needed or really used today (vs just using multiple/per tunnel tlv
updates)?  The encap safi certainly resulted in some pretty complex code
in order to "optimize" update sizes.  It seems that this too is a
similar trade off, and would be a good additional area of complexity
that can be simplified.  If it's not used today, I think we should
restrict the Tunnel Encapsulation Attribute to one Tunnel-TLV.

 If this is kept, it seems like there's some special aggregation rules
that could apply.

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

I don't think this is the case for *new* registries.  We can defer to
the Doc shepherd on this and not discuss further.

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

"never used" is not the same as "not currently used".  The latter is
accurate, the former is not.  I can live with this (pedantic)  inaccuracy.

Lou