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

["Susan Hares" <[e-mail]>]

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]

 

 

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

 

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

 

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

 

 

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] 

 

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