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

[Donald Eastlake <[e-mail]>]

On Thu, Aug 13, 2015 at 4:40 PM, Susan Hares <[e-mail]> wrote:

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

Sure, I'll post a new version this evening.

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


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