Subject: Re: [OSPF] Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with DISCUSS and COMMENT)

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Sep 2017 09:39:11 +0200

Dear authors,

I see that a new version has been posted.
Can you let me know how my DISCUSS point 2 has been addressed?

Regards, Benoit
> Benoit Claise has entered the following ballot position for
> draft-ietf-ospf-encapsulation-cap-06: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 1. I agree with Tim Wicinski's OPS DIR point about IANA.
>
>      The content appears to be fine, but there are some outdated (the biggest
>      one is 5226 replaced by 8126), but its the IANA section which appears the
>      most confusing.
>
>      7.1 OSPF Router Information (RI) Registry -  appears fine
>
>      7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry
>
>      This one defines the values being defined/allocated from "This Document"
>      but in Section 5, each Sub-TLV is defined in other documents, so it's
>      totally confusing.
>
> 2. It's not clear which of the following sub-TLVs are
> required/relevant/interconnected in the Encapsulation Capability TLV
>
>              0    Reserved                                  This document
>              1    Encapsulation                             This document
>              2    Protocol Type                             This document
>              3    Endpoint                                  This document
>              4    Color                                     This document
>              5    Load-Balancing Block                      This document
>              6    IP QoS                                    This document
>              7    UDP Destination Port                      This document
>
> The only hint is:
>
>        Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
>        TLVs as defined in Section 5.
>
> Zero? really, what's the point?
> Now, from an operational point of view, which sub-TLVs are required/make sense?
> Are some sub-TLVs irrelevant without others? Ex: Color without Encapsulation
> Could we have multiple identical sub-TLVs? Ex: Color
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - Sometimes you use "Encapsulation Capability TLV" (section 3), sometimes "The
> Tunnel Encapsulation Type Sub-TLV" I guess that: OLD:
>
>   The Tunnel Encapsulation Type Sub-TLV is structured as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                            Sub-TLVs                           |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> NEW:
>   The Encapsulation Capability TLV is structured as follows:
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                            Sub-TLVs                           |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> In section 7.1, should it be?
> OLD:
>      Value   TLV Name                                  Reference
>         -----   ------------------------------------   -------------
>         TBD1    Tunnel Capabilities                    This document
>
> NEW:
>      Value   TLV Name                                  Reference
>         -----   ------------------------------------   -------------
>         TBD1    Encapsulation Capabilities             This document
>
> OR:
>      Value   TLV Name                                  Reference
>         -----   ------------------------------------   -------------
>         TBD1    Tunnel Encapsulation Capabilities      This document
>
> - Then there is a discrepancy between Sub-TLVs and Value in the related text
>
>         0                   1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                                                               |
>        |                            Sub-TLVs                           |
>        |                                                               |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation Attribute
> Sub-TLVs", and the following text updated:
>
>    Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
>        TLVs as defined in Section 5.
>
> - Then, reading section 5, I see yet another name: "OSPF Tunnel Encapsulation
> Attribute Sub-TLVs" Section 7.2.
>
> You should re-read the document to be consistent with your naming convention,
> in the text and in the IANA sections.
>
>
> .
>

---

From: Xuxiaohu <[email-masked]>
Date: Mon, 11 Sep 2017 08:20:54 +0000

Hi Benoit,

The Tunnel Encapsulation Capabilities TLV contains one or more Tunnel Encapsulation Type Sub-TLVs which in turn contain Zero or more Tunnel Encapsulation Attribute Sub-TLVs. More specifically, the intent of Tunnel Encapsulation Attribute Sub-TLVs contained in a given Tunnel Encapsulation Type Sub-TLV is to describe the specific parameters to be used for the tunnel indicated by the Type of that Tunnel Encapsulation Type Sub-TLV. 

I wonder whether I have understood your points correctly.

Best regards,
Xiaohu 

> -----邮件原件-----
> 发件人: Benoit Claise [mailto:[email-masked]]
> 发送时间: 2017年9月11日 15:39
> 收件人: The IESG
> 抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 主题: Re: Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with
> DISCUSS and COMMENT)
> 
> Dear authors,
> 
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> >              0    Reserved                                  This
> document
> >              3    Endpoint                                  This
> document
> >              4    Color                                     This
> document
> >              6    IP QoS                                    This
> document
> > Are some sub-TLVs irrelevant without others? Ex: Color without
> > Encapsulation Could we have multiple identical sub-TLVs? Ex: Color
> >
> >
> > - Sometimes you use "Encapsulation Capability TLV" (section 3),
> > sometimes "The Tunnel Encapsulation Type Sub-TLV" I guess that: OLD:
> >
> >         0                   1                   2
> 3
> >        |
> |
> >        |                            Sub-TLVs
> |
> >        |
> |
> >         0                   1                   2
> 3
> >        |
> |
> >        |                            Sub-TLVs
> |
> >        |
> |
> >         0                   1                   2
> 3
> >        |
> |
> >        |                            Sub-TLVs
> |
> >        |
> |
> > Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation
> > Attribute Sub-TLVs", and the following text updated:
> >
> > - Then, reading section 5, I see yet another name: "OSPF Tunnel
> > Encapsulation Attribute Sub-TLVs" Section 7.2.
> >
> > You should re-read the document to be consistent with your naming
> > convention, in the text and in the IANA sections.
> >
> >
> > .
> >

---

From: Benoit Claise <[email-masked]>
Date: Mon, 11 Sep 2017 12:19:55 +0200

Hi Xiaohu,

My DISCUSS is at 
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ballot/
Let me try to rephrase the second DISCUSS point.
The following sentence is so generic

Basically, it says: you can receive 0, 1, or more instance of

           0    Reserved               This document
           1    Encapsulation          This document & [I-D.ietf-idr-tunnel-encaps]
           2    Protocol Type          This document & [I-D.ietf-idr-tunnel-encaps]
           3    Endpoint               This document
           4    Color                  This document
           5    Load-Balancing Block   This document & [RFC5640]
           6    IP QoS                 This document & [I-D.ietf-idr-tunnel-encaps]
           7    UDP Destination Port   This document & [I-D.ietf-idr-tunnel-encaps]
     8-65499    Unassigned
65500-65534    Experimental           This document
       65535    Reserved               This document

And my question/point: really, you want to be that open/liberal in terms 
of Tunnel Encapsulation Attribute Sub-TLVs?
You have really no rules? What if some combinations don't even make sense?

     None of sub-TLVs are compulsory? Not even the Endpoint?
     What does a Color mean without an Endpoint?
     What do two IP QoS mean?
     What do two Endpoints mean?
     What do two different IP QoS with two different Endpoints mean?
     etc...

I wonder how you could inter-operate?

Regards, Benoit

---

From: <[email-masked]>
Date: Mon, 18 Sep 2017 15:25:55 +0000

Hi Benoit,

Thanks for you review and comments.
Please see inline [Bruno]

> From: Benoit Claise [mailto:[email-masked]]
 > Sent: Wednesday, August 30, 2017 9:57 AM
> 
 >     one is 5226 replaced by 8126),

[Bruno] Thanks. Fixed.

 >  but its the IANA section which appears the
 >     most confusing.
 > 
 
[Bruno] Your comment is in line with other comments. We are proposing the two below changes. Would this address your point?

1) In sections 5.x, clarifies that the Type values are defined in this document. Only the Value field is defined in the BGP document.
More specifically, the propose change is
OLD:
        This Sub-TLV of type 2 is defined in Section 3.4.1 "Protocol Type
        sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/> from a
        syntactic, semantic, and usage standpoint.

NEW:
        This Sub-TLV type is 2. The syntax, semantic, and usage of its value field is defined in Section 3.4.1 "Protocol Type
        sub-TLV" of <xref target="I-D.ietf-idr-tunnel-encaps"/>.

2) As per other comments, draft-07 has changed to IANA section
OLD:
2        Protocol Type        This document  	

NEW:

Note that I'm personally not so found of the above change as draft-ietf-ospf-encapsulation-cap does create this new registry and allocate those initial values. But I can live with those changes if people see value.

 > Zero? really, what's the point?

[Bruno] There is no point in sending zero Sub-TLVs, as per draft-ietf-ospf-encapsulation-cap. But I'm not sure to see a reason to:
- forbid this usage in a future specification
- create an error case with specific error handling associated.

Also this text is taken from RFC 5512 section 4, which originally defined the BGP Tunnel Encapsulation Attribute https://tools.ietf.org/html/rfc5512#section-4

 > Are some sub-TLVs irrelevant without others? Ex: Color without Encapsulation

[Bruno]
RFC5512 did not cover this point, nor does draft-ietf-idr-tunnel-encaps.
In theory, as of today, Sub-TLV type 3 (Endpoint) seems required to minimally define the IP address of the tunnel decapsulator. However, I'm reluctant to define sub-TLV as REQUIRED, as future Sub-TLV/usage could possibly obsolete the initially required Sub-TLV. So we would create error condition which would possibly limit backward compatible improvement. Also the Encapsulation Sub-TLV (type 1) is required for some type of tunnels.

Being a network operator, I'm all in favor of interoperability and operational aspects. However, I don't see this applicable to a generic protocol extension. I'd rather see this in applicability statements.

 > Could we have multiple identical sub-TLVs? Ex: Color
 
[Bruno] Excellent question...
RFC5512 did not cover this point, nor draft-ietf-idr-tunnel-encaps... None of the Sub-TLV defined in this document need more than one instance. Limitation to a single instance could be specified during the definition of the "Tunnel Encapsulation Capabilities" in section 4, which would impose such restriction for future Sub-TLV. Or for each Sub-TLV in sections 5. The former seems an easier path, while the latter more extensible. Given the example of RFC 7770 / 4970, I think I would propose the latter: i.e. allowing the advertisement of multiple instance of a Sub-TLV, but disallowing it for all Sub-TLV defined in this draft.
However, I'd welcome any other opinion. I'm definitely open to follow the easier path.

[Bruno] You are right that names are not consistently used. We had try to have names be aligned both with the BGP encapsulation draft and OSPF RI/TLV names, but finally, that seem difficult. Given that the IDR document is still a draft and its names could change, I think we will favor more independent names.
Text changed to
NEW:

      The Tunnel Sub-TLV is structured as follows:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |               Tunnel Parameter Sub-TLVs                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 > In section 7.1, should it be?

[Bruno] Changed to 
NEW:
TBD1    Tunnel Encapsulations      This document

 > - Then there is a discrepancy between Sub-TLVs and Value in the related text
 
[Bruno] Agreed.

[Bruno] As the names change, changed to

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |               Tunnel Parameter Sub-TLVs                      |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

[...]

Value (variable): Zero or more Tunnel Parameter
          Sub-TLVs as defined in <xref target="ParameterTLVs"/>.

 > Attribute Sub-TLVs" Section 7.2.
 
[Bruno] That one was the name of the _IANA registry_ , not the name of the Sub-TLVs. I believe adding "OSPF" is useful as IDR and IS-IS would have a different registry. However, I'm open to different instructions.
 
 > in the text and in the IANA sections.
  
[Bruno] Yes. Sorry for this. Names had changed. I've re-read the document.

Many thanks for the review.
Regards,
--Bruno

_________________________________________________________________________________________________________________________

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: Benoit Claise <[email-masked]>
Date: Sat, 23 Sep 2017 09:13:56 -0700

Hi Bruno,

At this point, I'll be trusting the group, the doc . shepherd, and the 
responsible AD that the right actions will be taken.
Removing my DISCUSS now.

Regards, B.