Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 20 Jun 2017 02:44:47 +0000

Hi Tiger/Bruno,

See one inline.

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Xiaohu Xu <[email-masked]<mailto:[email-masked]>>
Date: Monday, June 19, 2017 at 9:19 PM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>, OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Alia,

Thanks a lot for your AD review. Please see our response inline.

发件人: Alia Atlas [mailto:[email-masked]]
发送时间: 2017年6月15日 6:56
收件人: OSPF List; [email-masked]<mailto:[email-masked]>
主题: AD review of draft-ietf-ospf-encapsulation-cap-03

As is customary, I have done my AD review of draft-ietf-ospf-encapsulation-cap-03.
First, I would like to thank the authors - Xiaohu, Bruno, Robert, Luis, and Luay - for their work on this useful document.

I do have a few concerns that need addressing before the draft can progress.

[Bruno/Xiaohu] Many thanks for your useful comments.
Following your comments, we believe it would be simpler and better to not create a new IANA registry for ”IGP  Tunnel Encapsulation Attribute Types” but rather reuse the existing BGP one:
https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types

[Bruno/Xiaohu] BTW when this OSPF extension has been defined, it has been modeled based on RFC 5512. However, as of today, the BGP extension is been redefined in draft-ietf-idr-tunnel-encaps, sometimes. Which normative reference should be use?
- as of today, RFC 5512 is probably the right one as draft-ietf-idr-tunnel-encaps has not passed WG LC and may never be published as RFC (IDR requires 2 implementations. I think RFC 5512 has not been implemented hence we may question whether draft-ietf-idr-tunnel-encaps will be…)
- in some hypothetical future, draft-ietf-idr-tunnel-encaps may obsolete RFC 5512

I agree that you should use RFC 5512 as that is the RFC that created the reference. At this point, the status of draft-ietf-idr-tunnel-encaps is irrelevant.

Thanks,
Acee

Major:

1)  First, the draft talks about what information is sent - but nothing about how it is to be understood or used.  That'd be ok if there were a clear reference to a document that discussed the related procedures.  A quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be the right place to start - but it's procedures are BGP-focused and while there are many similarities, there may be interesting differences as well.

[Bruno/Xiaohu] We’ll clarify that the 3 sub-TLV (§5.1-§5.3) are normatively defined in RFC 5512, from a format, semantic and usage standpoint. And that there code point are allocated in respectively the following IANA registries: BGP Tunnel Encapsulation Attribute Tunnel Types, BGP Tunnel Encapsulation Attribute Sub-TLVs. As per you comment, we need to clarify the 5.4 color Sub-TLV. Proposed text:
The Color Sub-TLV value is a 4-octet unsigned integer. Its semantic and usage are the same as the Color Value, from the Color Sub-TLV defined in RFC 5512 section 4.3 (*)

For instance, for the Color sub-TLV, is the 4 byte color value expected to represent the same meaning in OSPF as in BGP?

[Bruno/Xiaohu]Yes.

  Can a BGP route with a particular color extended community then have the OSPF tunnel to use selected from only those tunnels with the same color?

  What does the Color TLV mean in a purely OSPF context?

[Bruno/Xiaohu] idem as in the IDR context.  It’s a color used to define policy. The application using those tunnels, may use this color as an input for its policy when choosing the tunnel to use (or not use).
We can add this text if needed.

  Sec 7 of draft-ietf-idr-tunnel-encaps-06 ("However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains the Color Sub-TLV.  In that case, packet P SHOULD
   NOT be sent through the tunnel identified in that TLV, unless U1 is
   carrying the Color Extended Community that is identified in U2's
   Color Sub-TLV.") doesn't seem to strictly apply.

[Bruno/Xiaohu] Would new clarification added above (*) be enough? If not, a priori, I’d rather improve the definition of section 5.4 defining this color sub-TLV, in order for it to generally apply to any text. (rather than trying to patch the specific above text from Sec 7)

Semantics and behavior need to be specified - not just the encodings, and that is all this draft currently has.

2)  Sec 5.1 and Sec 5.2 refer to the format of the Encapsulation Sub-TLV and Protocol Sub-TLV coming from draft-ietf-idr-tunnel-encaps-06 - but that draft defines not merely the format, but allocates an IANA registry for additional sub-types that can appear and defines the format and contents of the sub-TLV based upon the tunnel type.   I'm nearly certain that you mean that these sub-tlvs use not merely the same format (does variable length fields based upon the allocated type cause issues for OSPF sub-TLV parsing???) but can contain any values and sub-TLVs defined in the relevant IANA registry. As it is written now, there is no reference to the registry or ability to easily support more tunnel types in the future.

[Bruno/Xiaohu] Good point. Does the previous change address that point?

3) It is unfortunate that Geneve, which is the agreed encapsulation for NVO3, is not included in the set of tunnels but VXLAN-GPE, which is not going to be a standard, is.
I know this is duplicating what is in draft-ietf-idr-tunnel-encaps-06 but it emphasizes the need to assume additional Tunnel Types and related Encapsulation Sub-TLVs will be defined.

[Bruno/Xiaohu] I agree that this is unfortunate.
But as the this new change, this draft will just refer to the existing BGP tunnels types. No duplication, no new tunnel types.
I’d rather define new types in an independent document. Home of this document, and possibly additional WGs to cross-post, would already be a good question ;-) (candidates could be OSPF, IS-IS, IDR, NVO3, RTGWG, softwires, possibly BESS…)

4) Sec 4: Is there a reason to create a new IGP Tunnel Encapsulation Types registry instead of reusing BGP Tunnel Encapsulation Attribute Tunnel Types (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types)?  The latter is FCFS and the proposed registry is Standards Action.   There are already differences and collisions between the two (i.e. value 15).
What would happen if an Encapsulation Sub-TLV needed to include a Tunnel Type? Which registry would it pull from? Would the value used depend on the protocol it was signaled in?

[Bruno/Xiaohu] Not anymore. (in early version of the OSPF draft, the code point was 1 octet, while IDR was 2). As indicated above, we’ll change to use the BGP one.

5) I-D.ietf-idr-tunnel-encaps has to be a normative reference.

[Bruno/Xiaohu] see the above.

6) Given that some of the references are to in progress documents for the tunnel types, is it expected that the values will correspond to future versions or are they nailed to this particular version or something else?

[Bruno/Xiaohu] I think the reference to existing “BGP”/IANA registry address this point

Nits:

a) Sec 1:"Partial deployment of IPv6 in IPv4 networks or IPv6 in IPv4
      networks as described in [RFC5565]"
s/IPv6 in IPv4/IPv4 in IPv6 for one of the two

[Bruno/Xiaohu] will fix it. Thanks again for your detailed AD review of this doc.

Regards,
Alia

Best regards,
Xiaohu/Bruno

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 26 Jun 2017 13:51:52 +0000

Thanks Bruno - I think this update provides simplification and brings us
closer to publication. It will be, however, now be gated on the IDR tunnel
encaps draft which has staled due to implementation discussions.

Thanks,
Acee 

On 6/26/17, 5:59 AM, "OSPF on behalf of [email-masked]"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Alia, 
>
>Many thanks for the useful review.
>-04 has just been published. I believe it address your first pass of
>comments.
>Htmlized:       
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04
>Diff:           
>https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-encapsulation-cap-04
>
>
>
>Main changes:
>- aligning with  I-D.ietf-idr-tunnel-encaps rather than RFC 5512.
>- adding 2 sub-TLV coming from I-D.ietf-idr-tunnel-encaps: IP QoS Field,
>UDP Destination Port. Note that the first one is currently called "IPv4
>DS Field" in the IDR draft. I've commented on IDR that this is IPv4
>specific with no IPv6 counterpart. Waiting for the resolution. We need
>the BGP and IGP draft to be aligned.
>- removed registry "IGP Tunnel Encapsulation Type" and pointing to
>existing registry "BGP Tunnel Encapsulation Type"
>- (editorial) Sub-TLV of the Tunnel Encapsulation Attribute are grouped
>in a dedicated section (§6)
>- clarification that for all but one, those sub-TLV are defined in
>I-D.ietf-idr-tunnel-encaps, from a syntax, semantic and usage standpoint.
>- color Sub-TLV better defined (as not aligned with the IDR draft)
>- added a section about the usage of the Tunnel Encapsulation attribute
>(§7)
>- a significant rule added: " A tunnel MUST NOT be used if there is no
>route toward the IP address
>   specified in the Endpoint Sub-TLV or if the route is not advertised
>   by the router advertising the Tunnel Encapsulation attribute
>   advertising this tunnel. "
>
>
>Some follow up on some of your points that I had missed in previous
>answer:
>
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Thursday, June 15, 2017 12:56 AM
>[...]
>> (does variable length fields based upon the allocated type cause issues
>>for OSPF sub-TLV parsing???)
>
>I guess that you are referring to
>"   o  Sub-TLV Length (1 or 2 octets): the total number of octets of the
>      sub-TLV value field.  The Sub-TLV Length field contains 1 octet if
>      the Sub-TLV Type field contains a value in the range from 1-127.
>      The Sub-TLV Length field contains two octets if the Sub-TLV Type
>      field contains a value in the range from 128-254."
>https://datatracker.ietf.org/doc/html/draft-ietf-idr-tunnel-encaps-06#sect
>ion-2
>
>The IGP draft does not use this. It uses a fixed 1-octet length field:
>    " Sub-TLV Length (1 octet): Unsigned 8-bit integer indicating the
>      total number of octets of the Sub-TLV value field."
>https://datatracker.ietf.org/doc/html/draft-ietf-ospf-encapsulation-cap-04
>#section-5
>
>
>> Semantics and behavior need to be specified - not just the encodings
>
>Agreed.
>Note however that the behavior is more complex in the BGP draft, because
>the Tunnel Attribute is attached to BGP routes, which can be of various
>SAFI with their own semantic and usage (e.g. GRT vs VPN/overlay case,
>labeled/unlabeled...) and their interaction with the different kind of
>tunnels (GRT vs VPN, labeled vs unlabeled). This is not the case in the
>IGP draft which only signals the tunnel itself (discovery, parameters).
>
>
>Thanks again for the careful review and the useful comments.
>
>Regards,
>--Bruno 
>
>> From: Alia Atlas [mailto:[email-masked]]  > Sent: Tuesday, June 20,
>>2017 5:27 PM
>> 
> > On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu <[email-masked]> wrote:
> > 
> > > Hi Alia,
> > >
> > >
> > >
> > > *发件人**:* Alia Atlas [mailto:[email-masked] <[email-masked]>]
> > > *发送时间**:* 2017年6月15日 6:56
> > > *收件人**:* OSPF List; [email-masked]
> > > *主题**:* AD review of draft-ietf-ospf-encapsulation-cap-03
> > >
> > >
> > >
> > > First, I would like to thank the authors - Xiaohu, Bruno, Robert,
>Luis,
> > > and Luay - for their work on this useful document.
> > >
> > >
> > >
> > > Following your comments, we believe it would be simpler and better
>to not
> > > create a new IANA registry for ”IGP  Tunnel Encapsulation Attribute
>Types”
> > > but rather reuse the existing BGP one:
> > >
> > Given that the sub-TLVs available depend on the tunnel type, I think
>this
> > makes sense.
> > 
> > 
> > 
> > > [Bruno/Xiaohu] BTW when this OSPF extension has been defined, it has
>been
> > > modeled based on RFC 5512. However, as of today, the BGP extension
>is been
> > > redefined in draft-ietf-idr-tunnel-encaps, sometimes. Which normative
> > > reference should be use?
> > >
> > > - as of today, RFC 5512 is probably the right one as
> > > draft-ietf-idr-tunnel-encaps has not passed WG LC and may never be
> > > published as RFC (IDR requires 2 implementations. I think RFC 5512
>has not
> > > been implemented hence we may question whether
>draft-ietf-idr-tunnel-encaps
> > > will be…)
> > >
> > > - in some hypothetical future, draft-ietf-idr-tunnel-encaps may
>obsolete
> > > RFC 5512
> > >
> > 
> > Judging from the two partial implementations in the IDR wiki, I'm not
>quite
> > as concerned.  That said, are you certain that there aren't
>explanations
> > and behaviors that are clarified in draft-ietf-idr-tunnel-encaps that
> > aren't in RFC 5512?  Certainly, some of the tunnel types that were
> > mentioned in the OSPF registry are from the former.
> > 
> > 
> > > Major:
> > >
> > >
> > >
> > > 1)  First, the draft talks about what information is sent - but
>nothing
> > > about how it is to be understood or used.  That'd be ok if there
>were a
> > > clear reference to a document that discussed the related procedures.
> A
> > > quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be
>the
> > > right place to start - but it's procedures are BGP-focused and while
>there
> > > are many similarities, there may be interesting differences as well.
> > >
> > >
> > >
> > > [Bruno/Xiaohu] We’ll clarify that the 3 sub-TLV (§5.1-§5.3) are
> > > normatively defined in RFC 5512, from a format, semantic and usage
> > > standpoint. And that there code point are allocated in respectively
>the
> > > following IANA registries: BGP Tunnel Encapsulation Attribute Tunnel
>Types,
> > > BGP Tunnel Encapsulation Attribute Sub-TLVs. As per you comment, we
>need to
> > > clarify the 5.4 color Sub-TLV. Proposed text:
> > >
> > > The Color Sub-TLV value is a 4-octet unsigned integer. Its semantic
>and
> > > usage are the same as the Color Value, from the Color Sub-TLV
>defined in
> > > RFC 5512 section 4.3 (*)
> > >
> > >
> > >
> > > For instance, for the Color sub-TLV, is the 4 byte color value
>expected to
> > > represent the same meaning in OSPF as in BGP?
> > >
> > >
> > >
> > > [Bruno/Xiaohu]Yes.
> > >
> > >
> > >
> > >   Can a BGP route with a particular color extended community then
>have the
> > > OSPF tunnel to use selected from only those tunnels with the same
>color?
> > >
> > >
> > >
> > > [Bruno/Xiaohu] idem as in the IDR context.  It’s a color used to
>define
> > > policy. The application using those tunnels, may use this color as
>an input
> > > for its policy when choosing the tunnel to use (or not use).
> > >
> > Yes, I think that is needed.  In BGP, since a route can have
>communities,
> > it is easy to just have a "must match color" rule (though one could
>picture
> > a community that means match-any-tunnel-but-this-color).  For OSPF, if
>the
> > intention of the use for this information is an external application,
>that
> > needs to be clearly stated.
> > 
> > There needs to be enough text so that two implementations can actually
>use
> > the functionality - not merely signal it - and that is generally what
>is
> > missing in the document.
> > 
> >    Sec 7 of draft-ietf-idr-tunnel-encaps-06 ("However, suppose that
>one of
> > > the TLVs in U2's Tunnel Encapsulation attribute contains the Color
> > > Sub-TLV.  In that case, packet P SHOULD
> > >
> > > [Bruno/Xiaohu] Would new clarification added above (*) be enough? If
>not,
> > > a priori, I’d rather improve the definition of section 5.4 defining
>this
> > > color sub-TLV, in order for it to generally apply to any text.
>(rather than
> > > trying to patch the specific above text from Sec 7)
> > >
> > 
> > I would be happy for you to fix it where makes the most sense to you.
>My
> > review suffers from the usual issue of commenting mostly on what is
>there
> > in the order and location it is presented.
> > 
> > 
> > > Semantics and behavior need to be specified - not just the
>encodings, and
> > > that is all this draft currently has.
> > >
> > >
> > >
> > >
> > >
> > > 2)  Sec 5.1 and Sec 5.2 refer to the format of the Encapsulation
>Sub-TLV
> > > and Protocol Sub-TLV coming from draft-ietf-idr-tunnel-encaps-06 -
>but
> > > that draft defines not merely the format, but allocates an IANA
>registry
> > > for additional sub-types that can appear and defines the format and
> > > contents of the sub-TLV based upon the tunnel type.   I'm nearly
>certain
> > > that you mean that these sub-tlvs use not merely the same format
>(*does
> > > variable length fields based upon the allocated type cause issues
>for OSPF
> > > sub-TLV parsing???*) but can contain any values and sub-TLVs defined
>in
> > > the relevant IANA registry. As it is written now, there is no
>reference to
> > > the registry or ability to easily support more tunnel types in the
>future
>
>__________________________________________________________________________
>_______________________________________________
>
>Ce message et ses pieces jointes peuvent contenir des informations
>confidentielles ou privilegiees et ne doivent donc
>pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>recu ce message par erreur, veuillez le signaler
>a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>Orange decline toute responsabilite si ce message a ete altere, deforme
>ou falsifie. Merci.
>
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>they should not be distributed, used or copied without authorisation.
>If you have received this email in error, please notify the sender and
>delete this message and its attachments.
>As emails may be altered, Orange is not liable for messages that have
>been modified, changed or falsified.
>Thank you.
>
>_______________________________________________
>OSPF mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ospf