[trill] comments on draft-tissa-trill-oam-fm-01.txt

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi,

I read draft-tissa-trill-oam-fm-01.txt. It needs a lot of editorial cleaning, both in organization of the material and details of editing. The principal challenge is the separation of work between the IETF and IEEE 802.1 - as much of what is described in this I-D is an extension of the IEEE 802.1Q CFM OAM. We need a clear separation of what is defined in TRILL and what is expected from the IEEE 802.1 and this needs to receive positive acknowledgment from the IEEE 802.1 WG in order to make progress. 

Please find below a set of comments divided into Technical and Editorial. Please address the issues raised below in the coming reviews. 


Technical

T1. In Figure 1 the TRILL Header is said to be 8 bytes, while the explanation speaks about 'Minimum of 8 bytes when the Extended Header is not included'. If there are reasons to believe that the Extended Header may be used for OAM Messages this needs to be specified clearly, including the cases where this happens. The information in Section 3.1 and Figure 5 of draft-ietf-trill-oam-framework-01 would also need to be corrected. However this would be problematic, as the OAM EtherType is expected at a deterministic offset from the TRILL Header.

T2. In section 3: 

> This document specifies using
   the EtherType allocated for 802.1ag for this purpose.

Is this what was agreed with IEEE 802.1? Is this true also if the backwards compatibility method in 3.3 is used?

Further in section 16 I see: 

> 16.1. IEEE Allocation Considerations

   The IEEE 802.1 Working Group is requested to allocate a separate
   opcode and TLV space within 802.1QCFM messages for TRILL purpose.

Did you discuss with IEEE 802.1 how this allocation will be performed. Does this need to be included in an update of IEEE 802.1Q?

T3. In Section 5: 

>  We propose to augment the [8021Q] MIB to add the TRILL specific
   information. Figure 6, below depicts the augmentation of the CFM MIB
   to add the TRILL specific Flow Entropy.

The augmentation of the MIB as described in this section is a challenge, as MIB development is now under the responsibility of the IEEE 802.1 WG. Here also there would be a need to cooperate closely with the IEEE 802.1 WG - was this agreed? 

T4. Section 7 seems to contain information that is not related to the bits on the wire but to the internal implementation. Should not this be moved to an appendix?  

T5. Section 9.1: 

>     o MD-L: Maintenance Domain Level (3 bits). Identifies the
        maintenance domain level. For TRILL, this MAY be always set to
        zero. However, in multilevel TRILL, backbone MAY be of a
        different MD-LEVEL. (Please refer to [8021Q] for the definition
        of MD-Level)

What does 'MAY be always' mean? 

T6. Section 9.1: 

>     o Version: Indicates the version (5 bits). As specified in
        [8021Q].

Is this document an update of the version? 



E1. There is more work to put references in order. I suggest to run idnits before submission, this immediately will point on most of the references-related problems. Currently idnits points to the following problems: 

Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'TRLLOAMMIB' is mentioned on line 977, but not
     defined
     'raise SNMP TRAPs [TRLLOAMMIB] as Alarms when a connectivity failu...'

  == Unused Reference: 'RFC5226' is defined on line 2039, but no explicit
     reference was found in the text
     '[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an I...'

  == Outdated reference: draft-ietf-trill-oam-req has been published as RFC
     6905
 
E2. In the Introduction section: 

>    The OAM message channel, if defined properly, can be shared between
   different technologies. A common OAM channel allows a uniform user
   experience for the customers, savings on operator training, re-use
   of software code base and faster time to market.

This sounds a little bit 'marketing'. I would rather replace this with a shorter definition and explanation about the role of the OAMA channel of ensuring consistency between message formats whatever transport TRILL runs on. Also avoid to say 'if defined properly' - there is no reason not to define properly in IETF documents :-)

E3. Also in the Introduction: 

> The ITU-T Y.1731 standard utilizes the same messaging format as
   [8021Q] and OAM messages where applicable.

Probably better: 

> The ITU-T Y.1731 [REFERENCE] standard utilizes the same messaging format as
   [8021Q] and reuses OAM messages where applicable.

Note the need to provide a reference to Y.1731

E4. The acronyms section is incomplete - for example ECMP, ISS should be added, probably more

E5. Section 3.4 (and other  sections in the document) - avoid the 'We propose' language - this is a specification, not just a proposal

Also here s/the implementation is OAM capable but utilize backwards compatible method defined in section 3.3/the implementation is OAM capable and utilizes the backwards compatible method defined in section 3.3/

E6. Section 16.2 - the different registries and sub-registries maintained by IANA need to point back to specific sections in the document, also need to use consistent naming in these sections and here. 

E7. [8021Q] must be a normative reference. 


Regards,

Dan