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

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

Donald:

 

All the changes you suggest are fine.  See comments inline below.   Will you be releasing a -07 to resolve these comments? 

 

Sue 

 

From: trill [mailto:[e-mail]] On Behalf Of Donald Eastlake
Sent: Thursday, August 13, 2015 4:14 PM
To: Susan Hares
Cc: [e-mail]; Jon Hudson; [e-mail]
Subject: Re: [trill] Shepherd write-up for draft-ietf-trill-channel-tunnel-06.txt

 

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]

 

[Donald] 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]

 

[Sue 2]: No changes – just indicating why I think the changes below are necessary. 

 

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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-...

 

 [Sue]: This resolves my comment 

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

 

[Sue 2]: This would be fine. 

 

Thanks,

Donald

=============================

 Donald E. Eastlake 3rd   [phone] (cell)

 155 Beaver Street, Milford, MA 01757 USA

 [e-mail]