Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

[Donald Eastlake <[e-mail]>]

Hi Sue,

Thanks for the comments. See below.

On Thu, Aug 13, 2015 at 9:18 AM, Susan Hares <[e-mail]> wrote:

> Donald, Mohammed, Yizhou, and Trill-WG:
>
>
>
> <document shepherd hat on>
>
>
>
> I have completed my Shepherd review of
> draft-ietf-trill-channel-tunnel-06.txt.   Below is the shepherd write-up
> for this draft.   I will be uploading the Shepherd write-up today – so
> please let me know if you have any questions regarding this write-up.
>
>
>
> Sue Hares
>
> <document shepherd hat off>
>
>
>
> ========
>
> *Shepherd write-up: *
>
>
>
> Status of document: No major errors, minor technical,   3 minor editorial
> issues
>
> Quality of text:  Text provides  clear description of additions.   If you
> are re-writing section, it would be useful to rephrase complex sentences in
> groups of “less” complex sentences could help the general readability of
> the drafts.
>
>
>
> *Minor technical issues *
>
>
>
> #1 – Bridge Channel Tunnel Protocol = TBD
>
>
>
> My understanding is there is just one RBridge Channel protocol which will
> be used for the tunnels:
>
>
>
> An example assignment is in red:
>
>
>
> CSV
>
> *Range   Registration Procedures               Note *
>
> 0x002-0x0FF       Standards Action
>
> 0x100-0xFF7       RFC Required                     allocation of a single
> value
>
> 0x100-0xFF7       IESG Approval                   allocation of multiple
> values
>
>
>
> *Protocol               Description                         Reference *
>
> 0x000                    Reserved                             [RFC7178]
>
> 0x001                    RBridge Channel Error    [RFC7178]
>
> 0x002                    BFD Control                        [RFC7175]
>
> 0x003                    BFD Echo                             [RFC7175]
>
> 0x004                    Tunnel                                  [This
> RFC]
>
> 0x004-0xFF7       Unassigned
>
> 0xFF8-0xFFE       Reserved for Private Use  [RFC7178]
>
> 0xFFF    Reserved                                             [RFC7178]
>

I'm not sure what change, if any, you are suggesting immediately above. In
the IANA Considerations Section, the draft says:

         Protocol   Description    Reference
         --------  --------------  ---------

           TBD     Tunnel Channel   [this document]



> p. 6  final paragraph reads:
>
>                 “The RBridge Tunnel Channel Protocol Specific Data Fields
> are as follows: “
>
>
>
> I believe based on figure 2.4 this should be:
>
>                 “The RBridge Channel Tunnel Protocol Specific Data Fields
> are the following fields: “
>

Yes.


> p. 9 figure 3.1 – Do you want the text in the possible security
> information to be changed from:
>
>
>
> from:
>
>
>
> RBridge-channel (0x8946) | CHV=0 | channel Protocol
>
>
>
> to:
>
>
>
> RBridge-channel (0x8946) | CHV=0 | Tunnel Protocol = TBD
>

Yup, good catch.


> *#2 – Figure 3.3 is unclear*
>
>
>
> The text states
>
>
>
>    A PType of 2 and an initial L2-IS-IS Ethertype indicates that the
>
>    payload of the Tunnel protocol message is an encapsulated TRILL IS-IS
>
>    PDU packet as shown in the figure below.
>
>
>
> Please change to
>
>    A PType of 2 and an initial L2-IS-IS Ethertype indicates that the
>
>    payload of the Tunnel protocol message is an encapsulated TRILL IS-IS
>
>    PDU packet as shown in the figure 3.3.
>
>
OK.


> The possible security information  has a possible security information
> with the following format
>
>
>
>                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |    RBridge-Channel (0x8946)   | CHV=0 | Tunnel Protocol = TBD |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |          Flags        |  ERR  | SubERR| RESV4 | SType |  0x2  |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |  Possible Security information
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
>
>       |  L2-IS-IS (0x22F4)            |
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       |  0x83     | rest of IS-IS PDU
>
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-...
>
>
>
> IT is unclear how many bytes are between the [L2-IS-IS (0x22F4) and
>
> [0x83]
>

The 0x83 occurs immediately after the 0x22F4. I guess it should be moved to
the end of the previous line although this make the beginning of the "rest
of IS-IS PDU" a bit ragged:

      ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Flags        |  ERR  | SubERR| RESV4 | SType |  0x2  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Possible Security information
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
      |  L2-IS-IS (0x22F4)            |     0x83      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                    rest of IS-IS PDU
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-...



> #3 – section 4.2 paragraph 1
>
>
>
> The text in this sentence is technically correct, but the complex sentence
> makes it difficult to understand:
>
>
>
>    To be more precise, the covered area starts with the byte immediately
>
>    after the TRILL Header ingress nickname unless the optional flag word
>
>    [rfc7180bis] is present in which case it starts after the flag word,
>
>    and extends to just before the TRILL Data packet link trailer, for
>
>    example just before the FCS for Ethernet.
>
>
>
> How about:
>
>
>
>    To be more precise, the covered area starts with the byte immediately
>
>    after the TRILL Header ingress nickname unless the optional flag word
>
>    [rfc7180bis] is present.  If the optional flag word is present,
>
>    then the covered area starts after the flag word,
>
>    and extends to just before the TRILL Data packet link trailer.  For
>
>    example, for the Ethernet packet this would be just before the FCS.
>
>
Sure but how about:

   To be more precise, the covered area starts with the byte
   immediately after the TRILL Header ingress nickname unless the
   optional flag word [rfc7180bis] is present.  If the optional flag
   word is present, then the covered area starts after that flag
   word. In either case, it extends to just before the TRILL Data
   packet link trailer.  For example, for an Ethernet packet it would
   extend to just before the FCS.


Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]