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

From: Alia Atlas <[email-masked]>
Date: Wed, 14 Jun 2017 18:56:28 -0400

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.

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.
For instance, for the Color sub-TLV, is the 4 byte color value expected to
represent the same meaning in OSPF as in BGP?  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?  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.

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.

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.

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?

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

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?

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

Regards,
Alia

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 18 Jun 2017 18:37:43 +0000

Authors,
Please submit a revision addressing Alia’s comments.
Thanks,
Acee

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 14, 2017 at 6:56 PM
To: OSPF WG List <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [OSPF] 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.

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.
For instance, for the Color sub-TLV, is the 4 byte color value expected to represent the same meaning in OSPF as in BGP?  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?  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.

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.

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.

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?

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?

Nits:

Regards,
Alia

---

From: Xuxiaohu <[email-masked]>
Date: Tue, 20 Jun 2017 01:19:00 +0000

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

[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

Major:

[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)

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

[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…)

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

[Bruno/Xiaohu] see the above.

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

Nits:

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

Regards,
Alia

Best regards,
Xiaohu/Bruno

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Jun 2017 11:26:56 -0400

On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu <[email-masked]> wrote:

> *发件人**:* 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…)
>

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.

> [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 (*)
>
>
>
> 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.

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

Simply changing to the BGP registry helps - but it isn't quite sufficient.
Are there cases where a BGP tunnel type wouldn't be supported?  How should
an unknown sub-TLV or unknown tunnel type be treated?

Also - are OSPF parsers ready to handle variability in terms of the number
of bytes for the length for a  sub-TLV?  I see that
draft-ietf-idr-tunnel-encaps Sec 2 defines that the sub-TLV length can be 1
or 2 bytes - but this draft says that the sub-TLV length is 1 byte (Sec
5).  If the tunnel type isn't understood, then I can see that the OSPF
parser would know about the number of bytes for the length of a sub-TLV
based upon the type value & which range it falls into.

As I investigate this, I actually have more concerns.   Generally, for
OSPF, TLVs and sub-TLVs are padded to a 4-byte boundary that includes the
type and length.  The format for the sub-TLVs in
draft-ietf-idr-tunnel-encaps appear to be mostly aligned to 4-bytes
ignoring the type and length.   In Sec 3.2.4, the L2TPv3 sub-TLV isn't
padded to a 4-byte boundary and its length is how the cookie size is
determined.

At the bottom of Sec 4, the length is defined as the total number of octets
in the value field.  Since this doesn't indicate that it requires or adds
padding to a 4-byte boundary, this could throw off the alignment for the
rest of the LSA.

Is there an implementation of this draft?  Have these types of concerns
been thought through?

> 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…)
>
>
>
> (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).
>
> [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.
>
>
>

Regards,
Alia

---

From: <[email-masked]>
Date: Mon, 26 Jun 2017 09:59:46 +0000

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 29 Jun 2017 17:09:03 -0400

Hi Bruno,

Thanks for the updated draft - more in-line.

On Mon, Jun 26, 2017 at 5:59 AM, <[email-masked]> wrote:

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

[Alia] The text for the UDP Destination Port (Sec 6.6) is wrong - it's just
copied from Sec 6.5.
I agree with you on the need for the IP QoS field to represent both IPv6 as
well as IPv4; it also just talks about the DS field - but that's 6 bits.
Are the ECN bits included?  That's a conversation for IDR.

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

[Alia] I think that there is still clarification on what to do if (in the
future) a sub-TLV that
used the 2-octet length couldn't fit into a 1-octet length. I know this is
currently hypothetical,
so all I'm looking for is a statement about the difference and that such
sub-TLVs are not supported
without further extensions.

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

[Alia] Sure - Sec 7 helps a lot.
What isn't clear though is how tunnels that require setup are handled.  In
Sec 5 of draft-ietf-idr-tunnel-encaps-06, I see
"The tunnel type is supported (i.e., router R knows how to set up tunnels
of that type, how to create the encapsulation header for tunnels of that
type, etc.)" as part of the discussion of what is a "feasible" tunnel.
Similar language would help in Sec 7.

[Alia] Finally, from a process perspective, I think that there has been
sufficient technical change that another short WGLC is appropriate.  Please
do update the draft first.  Then, we can do an IETF Last Call targeting an
IESG telechat in August.

Regards,
Alia

>  > > - in some hypothetical future, draft-ietf-idr-tunnel-encaps may
> obsolete
>  > > RFC 5512
>  > >
>  >
> ____________________________________________________________
> _____________________________________________________________
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Fri, 30 Jun 2017 12:31:40 +0000

Hi Alia,

More inline [Bruno2]

From: Alia Atlas [mailto:[email-masked]]
Sent: Thursday, June 29, 2017 11:09 PM
To: DECRAENE Bruno IMT/OLN
Cc: OSPF List; [email-masked]; Xuxiaohu
Subject: Re: AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Bruno,

On Mon, Jun 26, 2017 at 5:59 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

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.

[Alia] The text for the UDP Destination Port (Sec 6.6) is wrong - it's just copied from Sec 6.5.
[Bruno2] thanks, fixed
I agree with you on the need for the IP QoS field to represent both IPv6 as well as IPv4; it also just talks about the DS field - but that's 6 bits.  Are the ECN bits included?  That's a conversation for IDR.
[Bruno2] agreed (that’s for IDR)

Some follow up on some of your points that I had missed in previous answer:

> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
[...]

[Alia] I think that there is still clarification on what to do if (in the future) a sub-TLV that
used the 2-octet length couldn't fit into a 1-octet length. I know this is currently hypothetical,
so all I'm looking for is a statement about the difference and that such sub-TLVs are not supported
without further extensions.

 [Bruno2] There are 2 “Tunnel Encapsulation Attribute Types” registries:
- one for BGP, which allow length of 1 or 2 octets (as per the draft-ietf-idr-tunnel-encaps-06 because RFC 5512 only allowed for 1 octet)
- one for IGP, which allow length of 1 octet

For the IGP, there is no provision/future possibility to use a two-octets  length sub-TLV.
So yes, the length is limited, but this is not specific to this sub-TLV. All IGP/IETF/ISO…. TLVs share the same limitation that the size of the length field is predefined and fixed. So nothing new IMHO.
The only specific thing with this document is the filiation with the BGP document. If BGP were to define a two-octets length sub-TLV, it could not be retro-fitted in the IGP. One option would be to split the information into multiple sub-TLVs, but this is still limited. Is this this relation with the BGP sub-TLV that you’d like to be highlighted? If so, I can propose a new section
“6.7 Future sub-TLV
draft-ietf-idr-tunnel-encaps similarly defines Tunnel Encapsulation Attribute Sub-TLVs but IGP and BGP have separate IANA registries allowing for separate sub-TLV definitions. If the same information is to be advertised for both IGP and BGP tunnel encapsulation, it’s RECOMMENDED to use the same syntax, semantic and code point. However, it is to be noted that the "BGP Tunnel
   Encapsulation Attribute Sub-TLVs" registry allows for sub-TLV with two octets of length, while the “IGP Tunnel Encapsulation Attribute Types” registry only allows to octet of length. Hence the two-octets BGP Tunnel
   Encapsulation Attribute Sub-TLVs won’t be able to be defined for IGP Tunnels. Eventually, their information may be split over multiple sub-TLVs.”

Is this what you are looking for?
Alternatively the IGP registry could also define such two lengths, but to be honest, I’m reluctant to introduce such a “hack” in IGP. I would fear bugs with the introduction of a type having a two-octet length, with possibly significant consequences in a link state IGP.

BTW, I’ve just noticed that BGP and IGP registries have different names as the name of the BGP registry has changed since RFC 5512. I’m fixing this
OLD: IGP Tunnel Encapsulation Attribute Types
NEW: IGP Tunnel Encapsulation Attribute Sub-TLVs

Agreed.

[Alia] Sure - Sec 7 helps a lot.
What isn't clear though is how tunnels that require setup are handled.  In Sec 5 of draft-ietf-idr-tunnel-encaps-06, I see
"The tunnel type is supported (i.e., router R knows how to set up tunnels of that type, how to create the encapsulation header for tunnels of that type, etc.)" as part of the discussion of what is a "feasible" tunnel.   Similar language would help in Sec 7.
[Bruno2]

Both IDR and OSPF drafts have the same text regarding tunnel setup: “   Note that some tunnel types may require the execution of an explicit
   tunnel setup protocol before they can be used for carrying data.
   Other tunnel types may not require any tunnel setup protocol.”

As the IDR draft defines the IANA registry for encapsulation type, it also have the following sentence “Whenever a new Tunnel Type TLV is defined, the specification of that

   TLV must describe (or reference) the procedures for creating the

   encapsulation header used to forward packets through that tunnel

   type. » I don’t think that this is needed in the IGP draft since it does not define such registry.

Since you specifically refer to a text in section 5 of draft-ietf-idr-tunnel-encaps-06, I think that for the ospf draft the related text is in section 7 and I’m proposing the following change
OLD: The decision to use that tunnel, is driven by policy on the ingress router.
NEW: The decision to use that tunnel is driven by the capability of the ingress router to support the encapsulation type and the policy on the ingress router.

[Alia] Finally, from a process perspective, I think that there has been sufficient technical change that another short WGLC is appropriate.  Please do update the draft first.  Then, we can do an IETF Last Call targeting an IESG telechat in August.
[Bruno2] ok. Waiting for your feedback before uploading the new version.

Thanks,
Regards,
--Bruno

Regards,
Alia

Regards,
--Bruno

> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]  > Sent: Tuesday, June 20, 2017 5:27 PM
>
 > On Mon, Jun 19, 2017 at 9:19 PM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
 >
 > > Hi Alia,
 > >
 > >
 > >
 > > *发件人**:* Alia Atlas [mailto:[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>]
 > > *收件人**:* OSPF List; [email-masked]<mailto:[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 30 Jun 2017 11:30:09 -0400

Hi Bruno,

On Fri, Jun 30, 2017 at 8:31 AM, <[email-masked]> wrote:

> Hi Alia,
>
>
>
> More inline [Bruno2]
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Thursday, June 29, 2017 11:09 PM
> *To:* DECRAENE Bruno IMT/OLN
> *Cc:* OSPF List; [email-masked]; Xuxiaohu
> *Subject:* Re: AD review of draft-ietf-ospf-encapsulation-cap-03
>
>
>
> Hi Bruno,
>
>
>
> I agree with you on the need for the IP QoS field to represent both IPv6
> as well as IPv4; it also just talks about the DS field - but that's 6
> bits.  Are the ECN bits included?  That's a conversation for IDR.
>
> - one for BGP, which allow length of 1 or 2 octets (as per the
> draft-ietf-idr-tunnel-encaps-06 because RFC 5512 only allowed for 1 octet)
>
> So yes, the length is limited, but this is not specific to this sub-TLV.
> All IGP/IETF/ISO…. TLVs share the same limitation that the size of the
> length field is predefined and fixed. So nothing new IMHO.
>
> The only specific thing with this document is the filiation with the BGP
> document. If BGP were to define a two-octets length sub-TLV, it could not
> be retro-fitted in the IGP. One option would be to split the information
> into multiple sub-TLVs, but this is still limited. Is this this relation
> with the BGP sub-TLV that you’d like to be highlighted? If so, I can
> propose a new section
>
> “6.7 Future sub-TLV
>
> draft-ietf-idr-tunnel-encaps similarly defines Tunnel Encapsulation
> Attribute Sub-TLVs but IGP and BGP have separate IANA registries allowing
> for separate sub-TLV definitions. If the same information is to be
> advertised for both IGP and BGP tunnel encapsulation, it’s RECOMMENDED to
> use the same syntax, semantic and code point. However, it is to be noted
> that the "BGP Tunnel
>
>    Encapsulation Attribute Sub-TLVs" registry allows for sub-TLV with two
> octets of length, while the “IGP Tunnel Encapsulation Attribute Types”
> registry only allows to octet of length. Hence the two-octets BGP Tunnel
>
>    Encapsulation Attribute Sub-TLVs won’t be able to be defined for IGP
> Tunnels. Eventually, their information may be split over multiple
> sub-TLVs.”
>
>
>
> Alternatively the IGP registry could also define such two lengths, but to
> be honest, I’m reluctant to introduce such a “hack” in IGP. I would fear
> bugs with the introduction of a type having a two-octet length, with
> possibly significant consequences in a link state IGP.
>
>
>
> BTW, I’ve just noticed that BGP and IGP registries have different names as
> the name of the BGP registry has changed since RFC 5512. I’m fixing this
>
[Alia] I thought the draft was now using the BGP Tunnel Encapsulation
Attribute Sub-TLVs??
This draft just needs a statement that says "In BGP, as defined in
[draft-ietf-idr-tunnel-encaps], Sub-TLVs with types 128-254 have a
two-octet length field.  In OSPF, there is no support for a two-octet
length field; sub-TLVs in this range cannot be used in OSPF unless the
value field's length is known to fit in one octet."

>    Other tunnel types may not require any tunnel setup protocol.”

As the IDR draft defines the IANA registry for encapsulation type, it
also have the following sentence “Whenever a new Tunnel Type TLV is
defined, the specification of that
> Since you specifically refer to a text in section 5 of
> draft-ietf-idr-tunnel-encaps-06, I think that for the ospf draft the
> related text is in section 7 and I’m proposing the following change
>
> NEW: The decision to use that tunnel is driven by the capability of the
> ingress router to support the encapsulation type and the policy on the
> ingress router.
>

[Alia] That sounds good.

> [Bruno2] ok. Waiting for your feedback before uploading the new version.

[Alia] Please do.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 30 Jun 2017 15:52:09 +0000

Hi Alia, Bruno,

From: OSPF <[email-masked]<mailto:[email-masked]>> on behalf of Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 30, 2017 at 11:30 AM
To: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Cc: 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 Bruno,

On Fri, Jun 30, 2017 at 8:31 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

More inline [Bruno2]

Cc: OSPF List; [email-masked]<mailto:[email-masked]>; Xuxiaohu

Hi Bruno,

Main changes:

[...]

 [Bruno2] There are 2 “Tunnel Encapsulation Attribute Types” registries:
- one for BGP, which allow length of 1 or 2 octets (as per the draft-ietf-idr-tunnel-encaps-06 because RFC 5512 only allowed for 1 octet)
- one for IGP, which allow length of 1 octet
Even though it is unlikely to be required, can we just go with 2 octet type and length for the tunnel attribute Sub-TLVs consistent with the TLV format in RFC 7770? Seems like this would simplify things – I guess we are worried about IS-IS consistency?

Thanks,
Acee

[Alia] I thought the draft was now using the BGP Tunnel Encapsulation Attribute Sub-TLVs??
This draft just needs a statement that says "In BGP, as defined in [draft-ietf-idr-tunnel-encaps], Sub-TLVs with types 128-254 have a two-octet length field.  In OSPF, there is no support for a two-octet length field; sub-TLVs in this range cannot be used in OSPF unless the value field's length is known to fit in one octet."

Agreed.

[Alia] That sounds good.

[Alia] Please do.

Thanks,
Regards,
--Bruno

Regards,
Alia

Regards,
--Bruno

---

From: Alia Atlas <[email-masked]>
Date: Fri, 30 Jun 2017 11:59:21 -0400

Hi Acee,

On Fri, Jun 30, 2017 at 11:52 AM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Alia, Bruno,
>
> From: OSPF <[email-masked]> on behalf of Alia Atlas <
> [email-masked]>
> To: Bruno Decraene <[email-masked]>
> Cc: OSPF WG List <[email-masked]>, "draft-ietf-ospf-
> [email-masked]" <[email-masked]>
>> 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:
> Even though it is unlikely to be required, can we just go with 2 octet
> type and length for the tunnel attribute Sub-TLVs consistent with the TLV
> format in RFC 7770? Seems like this would simplify things – I guess we are
> worried about IS-IS consistency?
>

That works too & is a cleaner solution.  I had forgotten about the sizes of
sub-tlvs in RFC 7770.

Thank you,
Alia

>> BTW, I’ve just noticed that BGP and IGP registries have different names
>> as the name of the BGP registry has changed since RFC 5512. I’m fixing this
>>
>> What isn't clear though is how tunnels that require setup are handled.
>> In Sec 5 of draft-ietf-idr-tunnel-encaps-06, I see
>>

---

From: <[email-masked]>
Date: Fri, 30 Jun 2017 16:00:13 +0000

Hi Alia,

Many thanks for your time on this.
More inline [Bruno3]

Sent: Friday, June 30, 2017 5:30 PM

Hi Bruno,

More inline [Bruno2]

Hi Bruno,

Main changes:

[...]

[Bruno3] Sorry for not being clear.

Draft is now using (sharing) the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry.

For “Tunnel Encapsulation Attribute Sub-TLVs” draft is creating a new registry dedicated to the IGP called “IGP Tunnel Encapsulation Attribute Sub-TLVs”. That’s why this draft needs to re-specify those in section 6.

https://tools.ietf.org/html/draft-ietf-ospf-encapsulation-cap-04#section-6

So IMO, there is no technical issue. Yet, we can still add a text related to BGP TLVs which may have a two-octets length. e.g. the text I proposed. On the other hand, such text may also introduce confusion by speaking about BGP Tunnel Encapsulation Attribute Sub-TLVs which are just not used by this document.
As you wish.
Whatever the status of our discussion, I’ll upload a version Monday before the deadline.

--Bruno

Agreed.

[Alia] That sounds good.

[Alia] Please do.

Thanks,
Regards,
--Bruno

Regards,
Alia

Regards,
--Bruno

Thank you.

---

From: <[email-masked]>
Date: Fri, 30 Jun 2017 16:07:25 +0000

Hi Acee, Alia,

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, June 30, 2017 5:59 PM
To: Acee Lindem (acee)
Cc: DECRAENE Bruno IMT/OLN; OSPF List; [email-masked]
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Acee,

On Fri, Jun 30, 2017 at 11:52 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia, Bruno,

Hi Bruno,

More inline [Bruno2]

Hi Bruno,

Main changes:

[...]

That works too & is a cleaner solution.  I had forgotten about the sizes of sub-tlvs in RFC 7770.

[Bruno] That work and we could align the IS-IS document with this. The cost is using extra bytes in the IGP in order to accommodate for hypothetical future usage (in particular RFC 5512 did not assume that this would be useful)
But still, we wouldn’t have alignment with the BGP document… unless the BGP document is also changed.
Would moving to 2 octets be ok for the whole WG?
--Bruno

Thank you,
Alia

Thanks,
Acee

Agreed.

[Alia] That sounds good.

[Alia] Please do.

Thanks,
Regards,
--Bruno

Regards,
Alia

Regards,
--Bruno

Thank you.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 30 Jun 2017 19:05:13 +0000

Hi Bruno,

From: Bruno Decraene <[email-masked]<mailto:[email-masked]>>
Date: Friday, June 30, 2017 at 12:07 PM
To: Alia Atlas <[email-masked]<mailto:[email-masked]>>, Acee Lindem <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: OSPF WG List <[email-masked]<mailto:[email-masked]>>
Subject: RE: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Acee, Alia,

From: Alia Atlas [mailto:[email-masked]]
Sent: Friday, June 30, 2017 5:59 PM
To: Acee Lindem (acee)
Cc: DECRAENE Bruno IMT/OLN; OSPF List; [email-masked]<mailto:[email-masked]>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Hi Acee,

Hi Bruno,

More inline [Bruno2]

Hi Bruno,

Main changes:

[...]

If you mean the entire OSPF WG, I’m sure it would. OSPF TLVs have historically been 32-bit aligned and we’ve maintained that convention.

Thanks,
Acee

--Bruno

Thank you,
Alia

Thanks,
Acee

Agreed.

[Alia] That sounds good.

[Alia] Please do.

Thanks,
Regards,
--Bruno

Regards,
Alia

Regards,
--Bruno

Thank you.