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

[Benoit Claise <[e-mail]>]

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

       Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
       TLVs as defined in Section 5.

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
> 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:[e-mail]]
>> 发送时间: 2017年9月11日 15:39
>> 收件人: The IESG
>> 抄送: [e-mail]; [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> 主题: Re: Benoit Claise's Discuss on draft-ietf-ospf-encapsulation-cap-06: (with
>> DISCUSS and COMMENT)
>>
>> 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.
>>>
>>>
>>> .
>>>