[trill] Review of draft-ietf-trill-oam-framework-01

[Olen Stokes <[e-mail]>]

Based on a review of the subject document, please consider the following comments:


1)  Section 2.6 states that "a CFM MEP resides in the "802.1Q Port VLAN Processing" block" of Figure 2.  I was not able to find a block with that title in Figure 2.



2)  Section 2.6 states that "A TRILL OAM solution that conforms to this framework" MAY support UP MEP's and MAY support DOWN MEP's on TRILL physical ports.  I was unclear about the implications of these statements.  Does that imply that a solution could be acceptable even though it does not support either UP or DOWN MEP's?



3)  Section 3.1 at the top of Page 16 states, "The TRILL Header is as specified in [RFC6325]".  Should this paragraph include some discussion or reference to the TRILL Header as specified in the Fine Grained Labeling (FGL) document, especially since the FGL document "changes the description of the TRILL Header" in its Section 2.2?



4)  Section 3.3 states, "The use of [802.1Q] CFM encoding format for the OAM Message channel is one possible choice."  Given the amount of Y.1731 terminology used in this document, it might be helpful to at least make some statement about the possibility of using Y.1731 formatting.  I understand that the formats are compatible, but there are some differences.



5)  Section 3.3 references [TRILL-OAM] which is listed as "draft-tissa-trill-8021ag".  This document is expired.  Has it been replaced by "draft-tissa-trill-oam-fm-01.txt"?



6)  Section 3.4 suggests "using a reserved MAC address as the inner MAC SA" to identify a TRILL OAM packet.  It is unclear to me how this is more backwards compatible than using previously unused fields or bits in the TRILL Header as suggested in the preceding paragraph.  Is not the inner MAC SA used in some configurations for hashing at hops with equal-cost paths?



7)  Section 4.1.2.2 describes Reverse Defect Indication (RDI).  Given that Section 4.1.1 states that fault detection must be able to exercise each equal-cost path individually, Section 4.1.2.2 should probably state that RDI must be able to identify on which equal-cost path the failure was detected.



8)  Section 4.2.1 discusses carrying "test patterns as defined in [RFC2544]."  RFC 2544 is a substantial document but it does not contain the word "pattern".  Is this a reference to the frame formats in Appendix C or to some other section of the RFC?



9)  Section 4.2.1.2 discusses an un-pruned tree and a campus wide diagnostic VLAN. A campus wide diagnostic FGL is probably also required.



10) Section 4.2.2 discusses fault isolation.  It would be helpful to include a statement that fault isolation has to work for both known unicast and multi-destination packets.

As a general comment, Section 1.2 states that the document "leverages concepts and draws upon elements defined and/or used" in multiple existing OAM standards including 802.1ag CFM and Y.1731.  The document contains a mixture of terms from these two standards.  For example, the Y.1731 term Maintenance Entity Group (MEG) is used as opposed to the 802.1ag term Maintenance Association (MA).  However, the 802.1ag term Maintenance Point (MP) is used as opposed to the Y.1731 term Maintenance Entity (ME).  It does not appear to affect the technical content but it is unclear why the terminology is mixed.  Some statement about the method used to determine which terms to use might be helpful.

Please let me know if you would like to discuss any of these items further.

Cheers,
Olen