Transparent Interconnection of Lots of Links (TRILL): Fault Management
draft-ietf-trill-oam-fm-11

[Ballot comment]

Thanks  for handling my discuss points.

The comments below are old, I didn't check them against
the latest draft.

-----------------------

- 8.4.4 - is there a possible DoS issue here?

- 8.4.13 - why is an authentication TLV OAM specific?

- 8.4.13 - I don't (think I have) access to [IS-IS] so I've no
idea how this works in general - why not just say that rfc5310
is must-implement and [IS-IS] is a MAY?  And why not go further
and make HMAC-SHA256 the MTI auth type?

- Section 14 says: "Generally, a single operator manages each
TRILL campus, hence there is no risk of security exposure." I
think that's just bogus if you're trying to say that there are
no security issues in managing a campus network. But I guess
that's not it, so what are you trying to say?

[Ballot discuss]

Mail on -09 sent. Discussion continues.

- 8.4.13 - can you explain why automated key management (see
BCP107) is not needed here? I don't see how the symmetric
keys required would get to all the relevant boxes, or at
least I don't see that specified here or a reference that
I can access.

[Ballot comment]
I stand baffled that you won't fix this, but I'm certainly not going to DISCUSS it any longer:

8.4.3:

OLD
  Reserved2: Set to zero on transmission and ignored on reception.
NEW
  Reserved2 (12 bits): Set to zero on transmission and ignored on reception.

[Ballot comment]
My ABSTAIN here is because Donald Eastlake is both chair of the WG and editor of many of its documents.  This undermines the consensus process in TRILL to the degree that I cannot support the publication of documents on which he is editor.

[Ballot comment]
Thanks for the additional information to clear my discuss.  The scope of the threat mentioned is limited and I'm okay with leaving out mention of it.

[Ballot discuss]

- 8.4.13 - can you explain why automated key management (see
BCP107) is not needed here? I don't see how the symmetric
keys required would get to all the relevant boxes, or at
least I don't see that specified here or a reference that
I can access.

[Ballot comment]

- 8.4.4 - is there a possible DoS issue here?

- 8.4.13 - why is an authentication TLV OAM specific?

- 8.4.13 - I don't (think I have) access to [IS-IS] so I've no
idea how this works in general - why not just say that rfc5310
is must-implement and [IS-IS] is a MAY?  And why not go further
and make HMAC-SHA256 the MTI auth type?

- Section 14 says: "Generally, a single operator manages each
TRILL campus, hence there is no risk of security exposure." I
think that's just bogus if you're trying to say that there are
no security issues in managing a campus network. But I guess
that's not it, so what are you trying to say?

[Ballot comment]
Donald helpfully points out that my Discuss has confused

> "TRILL Verison Sub-TLV" which is initially specified in
> [RFC7176], Section 2.3.1
and
> "the so-similar-as-to-be-confusingly named "Port TRILL
> Version Sub-TLV" in Section 2.2.4 of [RFC7176].

...so I am happy to clear my Discuss.

The following Comments remain and are being discussed with the authors.

===

A recent conversation with an ITU-T OAM expert wrt a different I-D
yielded the following. I think this aplies to your document, too.

> Please note that the reference to Y.1731 is not correct.
> Since the approval in 2011 the recommendation number
> has changed to indicate that it is under responsibility of
> SG15. Also the most recent version is dated 11/2013.
>
> So I suggest that the current reference:
>    [ITU-T.Y.1731-2011]
>              ITU, "ITU-T Recommendation Y.1731: OAM functions and
>              mechanisms for Ethernet based networks", ITU-T
>              Recommendation Y.1731, 2011.
> Is changed into:
>    [ITU-T.Y.8013-2013]
>              ITU, "ITU-T Recommendation G.8013/Y.1731: OAM functions and
>              mechanisms for Ethernet based networks", ITU-T
>              Recommendation G.8013/Y.1731, 2013.

---

You might look for consistency between "Ethertype" [RFC7174], and
"Ether Type" and "EtherType" as used in this document.

---

3.2.1

  Such frames MUST be discarded.

Do you advise this to be silent, counted, logged?

---

I think a short piece of text is needed (somewhere around 3.2.1 or
3.3?) to describe how a legacy implementation will react to receiving a
frame with the A flag set. In fact, 3.3 of 6325 tells us about this, so
most of this can be done by reference. But it is important in the
context of OAM to consider what happens when the intended transit
recipient of an OAM frame simply and legally forwards a packet.
Similarly, it is important to consider what happens at an end station
that does not recognise the A flag.

Probably you would be noting in 3.3 that a legacy implementation will
not know about the O and B flags to say that it does not support OAM,
but that according to RFC 7176 those lags will be transmitted as zero
so the absence of OAM support will be inferred. Furthermore, I think
that the TRILL Version sub-TLV could be absent, so you need to state
that this must be taken to mean that OAM is not supported.

---

3.2.1

  Frames with the "A" flag set that do not contain CFM EtherType
  are not considered as OAM frames. Such frames MUST be discarded.

No objection if you have thought through the consequences. In the future
there is the posibility that a new use of the Alert flag will motivate
the use of a diferent EtherType. However, in that case, you will not be
able to get frames to pass through legacy nodes. That might be OK (all
nodes on the path are assumed to have been upgraded) or very annoying
(the new function is only needed at key RBridges on the path).

I don't need to dicuss this: just be sure you are doing what you want to
do.

---

Format of 4.3.1 is messed up by tabs.

---

I find it a little bit bothersome that this document and RFC 7174 uses
slightly different terminology from that set out in Y.1731. For example,
MEP is "MEP - Maintenance End Point" with a reference to [RFC7174] and
[8021Q], while Y.1731 (and correlated in RFC 6371 etc.) has "MEG end
point".

Pretty sure this ship has sailed and that the authors will claim that
allignment with 8021Q is more important than allignment within the IETF,
but there you go... I'm bothered.

---

I tend to agree with you in 6.1 that
  Hence,
  explicit addressing of MIPs is not required for the purpose of
  fault isolation.
But I would like to raise the concern expressed by ITU-T OAM experts
wrt multiple MIPs within a single RBridge. We saw this discussion in
MPLS-TP (see RFC 7054) and it led to the need for some identification
of MIPs.

BTW, I think that, technically, you are talking about the addressing of
MIPs in OAM request messages. I think that when a MIP responds it does
need to identify itself, so you *do* need MIP identifiers.

---

Shouldn't 8.1 describe the OpCode field? Just a smmary and pointer to
8.2.

---

In 8.4.4 you have...

  Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
  nickname. All other values reserved.

  Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge
  nickname.

  Reply Address (variable): Address where the reply needed to be
  sent. Length depends on the address specification.

The description of the Repply Address accurately states that the length
of the field depends on the address specification, but that's not the
future-proof model you are aiming for when you include the Addr Length
field. I think you need...

  Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
  nickname. All other values reserved.

  Addr Length (1 Octet). Dependent on the Address Type. Currently
  defined values are 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge nickname.
  Other lengths may be acceptable for future Address Types.

  Reply Address (variable): Address where the reply needed to be
  sent. The length of this field is defined by the value of the Addr
  Length field.

Also

  Length (2 octets) = Variable. Minimum length is 2.

Surely you have to have at least a TRILL nickname, so the minimum value
is 4 (Address Type, Addr Length, nickname).

---

8.4.5 needs to describe the Reserved field.

Maybe best to take the text in 8.4.3 and lift it to some common part of
the document where you can say "all fields in this document marked as
reserved..."

---

8.4.7 and 8.4.9

  Length (2 octets) = variable. Minimum value is 2.

Surely 1.
That is nOfnicknames could be set to 0.

Also, please describe the nOfnicknames field and clarify how it relates
to the Length field.

---

8.4.8

  Length (2 octets) = 4.

Are you sure? it looks like 5 in the figure.

---

8.4.12

    Length (1 octet) =97.

8.4.13

  Length (1 octet) = variable length

I think it is a 2 octet field in both cases.

---

10.1.2 provides a list of TLVs for inclusion. The way this is presented
implies that the ordering is sensitive. The text should clarify this
point.

Similar issues in other sections.

[Ballot discuss]
Piling on with Adrian:

8.4.3: Length is 9, not 6. Also, it would be useful to indicate the first "Reserved" field is 3 octets, and the second is 12 bits.

8.4.10: Like 8.4.5, you never define Reserved.

[Ballot comment]
Thanks for writing this document. I've read through it (not claiming full understanding), and only had two small comment:

There are several statements of the form:

  The CPU of the RBridge validates the frame ...

While this represents the typical implementation, or perhaps even the only reasonable implementation at this point in time, I'd suggest that an IETF specification should not dictate what part of an implementation performs packet validation and other tasks. Just saying the RBridge validates the frame should be enough, in my opinion.

Also, the document has statements of the form:

  Registry: TRILL OAM Return Codes.
  Registration Procedure: Standards Action.

and I believe it would be useful to reference RC 5226 for understanding what is meant by the various procedure names.

[Ballot comment]
Thanks for writing this document. I've read through it (not claiming full understanding), and only had one comment:

There are several statements of the form:

  The CPU of the RBridge validates the frame ...

While this represents the typical implementation, or perhaps even the only reasonable implementation at this point in time, I'd suggest that an IETF specification should not dictate what part of an implementation performs packet validation and other tasks. Just saying the RBridge validates the frame should be enough, in my opinion.

[Ballot comment]
>  A (1 bit) - Indicates this is a possible OAM frame and is subject
>  to specific handling as specified in this document.

I'd prefer saying more explicitly what value indicates an OAM frame. E.g., "A (1 bit) - When set to 1, indicates this is a possible ..."

[Ballot discuss]
I may have missed it, but didn't see any mention in the security considerations section of network reconnaissance activity using the path trace, CCM, and other techniques described to map networks (path and endpoint/RBridges) to be used later in exploits.  I may have missed this, but did also check the referenced RFCs (7174 & 6325), please let me know if I missed something.  Reconnaissance could be active by an attacker using the described techniques to discover the network or could be a passive observer collecting data from valid uses of the described techniques.

[Ballot discuss]
I have a number of small comments on this document, but only this one
merits a Discuss. I would point out that the volume of minor editorial,
but technically substantive Comments should be cause for concern about
this document.

---

I read the description of the Capabilities and Header Flags Supported
field in section 2.2.4 of RFC 7176 and found...

      Bits 3 through 13
      indicate that the corresponding TRILL Header hop-by-hop extended
      flags [RFC7179] are supported.  Bits 0 through 2 and 14 to 31 are
      reserved to indicate support of optional capabilities.

Now, it looks to me that you are defining the O-flag at bit 2 and the
B-flag at bit 3 (with A and F at 0 and 1). Am I right to be confused
about this?

[Ballot comment]
A recent conversation with an ITU-T OAM expert wrt a different I-D
yielded the following. I think this aplies to your document, too.

> Please note that the reference to Y.1731 is not correct.
> Since the approval in 2011 the recommendation number
> has changed to indicate that it is under responsibility of
> SG15. Also the most recent version is dated 11/2013.
>
> So I suggest that the current reference:
>    [ITU-T.Y.1731-2011]
>              ITU, "ITU-T Recommendation Y.1731: OAM functions and
>              mechanisms for Ethernet based networks", ITU-T
>              Recommendation Y.1731, 2011.
> Is changed into:
>    [ITU-T.Y.8013-2013]
>              ITU, "ITU-T Recommendation G.8013/Y.1731: OAM functions and
>              mechanisms for Ethernet based networks", ITU-T
>              Recommendation G.8013/Y.1731, 2013.

---

You might look for consistency between "Ethertype" [RFC7174], and
"Ether Type" and "EtherType" as used in this document.

---

3.2.1

  Such frames MUST be discarded.

Do you advise this to be silent, counted, logged?

---

I think a short piece of text is needed (somewhere around 3.2.1 or
3.3?) to describe how a legacy implementation will react to receiving a
frame with the A flag set. In fact, 3.3 of 6325 tells us about this, so
most of this can be done by reference. But it is important in the
context of OAM to consider what happens when the intended transit
recipient of an OAM frame simply and legally forwards a packet.
Similarly, it is important to consider what happens at an end station
that does not recognise the A flag.

Probably you would be noting in 3.3 that a legacy implementation will
not know about the O and B flags to say that it does not support OAM,
but that according to RFC 7176 those lags will be transmitted as zero
so the absence of OAM support will be inferred. Furthermore, I think
that the TRILL Version sub-TLV could be absent, so you need to state
that this must be taken to mean that OAM is not supported.

---

3.2.1

  Frames with the "A" flag set that do not contain CFM EtherType
  are not considered as OAM frames. Such frames MUST be discarded.

No objection if you have thought through the consequences. In the future
there is the posibility that a new use of the Alert flag will motivate
the use of a diferent EtherType. However, in that case, you will not be
able to get frames to pass through legacy nodes. That might be OK (all
nodes on the path are assumed to have been upgraded) or very annoying
(the new function is only needed at key RBridges on the path).

I don't need to dicuss this: just be sure you are doing what you want to
do.

---

Format of 4.3.1 is messed up by tabs.

---

I find it a little bit bothersome that this document and RFC 7174 uses
slightly different terminology from that set out in Y.1731. For example,
MEP is "MEP - Maintenance End Point" with a reference to [RFC7174] and
[8021Q], while Y.1731 (and correlated in RFC 6371 etc.) has "MEG end
point".

Pretty sure this ship has sailed and that the authors will claim that
allignment with 8021Q is more important than allignment within the IETF,
but there you go... I'm bothered.

---

I tend to agree with you in 6.1 that
  Hence,
  explicit addressing of MIPs is not required for the purpose of
  fault isolation.
But I would like to raise the concern expressed by ITU-T OAM experts
wrt multiple MIPs within a single RBridge. We saw this discussion in
MPLS-TP (see RFC 7054) and it led to the need for some identification
of MIPs.

BTW, I think that, technically, you are talking about the addressing of
MIPs in OAM request messages. I think that when a MIP responds it does
need to identify itself, so you *do* need MIP identifiers.

---

Shouldn't 8.1 describe the OpCode field? Just a smmary and pointer to
8.2.

---

In 8.4.4 you have...

  Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
  nickname. All other values reserved.

  Addr Length (1 Octet). 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge
  nickname.

  Reply Address (variable): Address where the reply needed to be
  sent. Length depends on the address specification.

The description of the Repply Address accurately states that the length
of the field depends on the address specification, but that's not the
future-proof model you are aiming for when you include the Addr Length
field. I think you need...

  Address Type (1 Octet): 0 - IPv4. 1 - IPv6. 2 - TRILL RBridge
  nickname. All other values reserved.

  Addr Length (1 Octet). Dependent on the Address Type. Currently
  defined values are 4 - IPv4. 16 - IPv6, 2 - TRILL RBridge nickname.
  Other lengths may be acceptable for future Address Types.

  Reply Address (variable): Address where the reply needed to be
  sent. The length of this field is defined by the value of the Addr
  Length field.

Also

  Length (2 octets) = Variable. Minimum length is 2.

Surely you have to have at least a TRILL nickname, so the minimum value
is 4 (Address Type, Addr Length, nickname).

---

8.4.5 needs to describe the Reserved field.

Maybe best to take the text in 8.4.3 and lift it to some common part of
the document where you can say "all fields in this document marked as
reserved..."

---

8.4.7 and 8.4.9

  Length (2 octets) = variable. Minimum value is 2.

Surely 1.
That is nOfnicknames could be set to 0.

Also, please describe the nOfnicknames field and clarify how it relates
to the Length field.

---

8.4.8

  Length (2 octets) = 4.

Are you sure? it looks like 5 in the figure.

---

8.4.12

    Length (1 octet) =97.

8.4.13

  Length (1 octet) = variable length

I think it is a 2 octet field in both cases.

---

10.1.2 provides a list of TLVs for inclusion. The way this is presented
implies that the ordering is sensitive. The text should clarify this
point.

Similar issues in other sections.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-trill-oam-fm-06.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about some of the actions requested in the IANA Considerations section of this draft document.

IANA understands that, upon approval of this document there are six actions which IANA must complete.

First, in the TRILL Neighbor TLV NEIGHBOR RECORD Flags subregistry in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry located at:

http://www.iana.org/assignments/trill-parameters/

two new capability flags are to be registered as follows:

Bit: [ TBD-at-registration ]
Description: OAM capable
Reference: [ RFC-to-be ]

Bit: [ TBD-at-registration ]
Description: Backwards compatible OAM
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested bits 2 and 3 for these capability flags.

Second, in the CFM OAM IETF OpCodes subregistry of the Connectivity Fault Management (CFM) OAM IETF Parameters registry located at:

http://www.iana.org/assignments/cfm-oam/

four new Op-Codes are to be registered as follows:

Value: [ TBD-at-registration ]
Description: Path Trace Reply
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: Path Trace Message
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: Multicast Tree Verification Reply
Reference: [ RFC-to-be ]

Value: [ TBD-at-registration ]
Description: Multicast Tree Verification Messages
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested values of 64, 65, 66, and 67 for these Op-Codes.

QUESTIONs: 
1) Is this a typo?  Section 10.1.2. Intermediate RBridge, the following
texts talk about TBD1:

/snip/
  Set the Return Code to (1) "Reply" and Return sub code to zero
  (2) "Intermediate RBridge". Update the TRILL OAM opcode to TBD1
  (Path Trace Message  Reply).
/snip/

Is there an extra word in the text "(Path Trace Message  Reply)"?

According to section 15.2, TBD1 reads:

TBD1[64]  Path Trace Reply      [this document]

2) Is "Multicast Tree Verification Messages" (TBD4[67]) plural or
single? 

Third, in the CFM OAM IETF TLV Types subregistry also in the Connectivity Fault Management (CFM) OAM IETF Parameters registry located at:

http://www.iana.org/assignments/cfm-oam/

eleven new TLV Types are to be registered as follows:

Value: [ TBD-at-Registration ]
Description: TRILL OAM Application Identifier TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Out of Band Reply Address TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Diagnostic Label TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Original Data Payload TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: RBridge Scope TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Previous RBridge nickname TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Next Hop RBridge List TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Multicast Receiver Port count TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Flow Identifier TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Reflector Entropy TLV
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: Authentication TLV
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested values 64 through 74 for these eleven new TLV types.

Fourth, in the IANA Unicast 48-bit MAC Addresses subregistry of the IANA MAC ADDRESS BLOCK registry located at:

http://www.iana.org/assignments/ethernet-numbers/

a new unicast MAC address will be assigned as follows:

Address: [ TBD-at-registration ]
Usage: TRILL OAM
Reference: [ RFC-to-be ]

QUESTION: The MAC Address registry has Expert Review in the registry
and Donald Eastlake is the DE.  Since Donald is one of the authors of
the document, is that served as his approval as the primary expert?
Should this be reviewed by the secondary expert?  IANA needs
a clarification on that.

Fifth, in the IANA Multicast 48-bit MAC Addresses subregistry also in the IANA MAC ADDRESS BLOCK registry located at:

http://www.iana.org/assignments/ethernet-numbers/

a new multicast MAC address will be assigned as follows:

Address: [ TBD-at-registration ]
Usage: TRILL OAM
Reference: [ RFC-to-be ]


QUESTION: The MAC Address registry has Expert Review in the registry
and Donald Eastlake is the DE.  Since Donald is one of the authors of
the document, is that served as his approval as the primary expert?
Should this be reviewed by the secondary expert?  IANA needs
a clarification on that.

Sixth, a new registry is to be created called the TRILL OAM Return code sub registry - located in the Transparent Interconnection of Lots of Links (TRILL) Parameters registry at:

http://www.iana.org/assignments/trill-parameters/

IANA Question -> How are the new registry and the subregistries associated with subcodes to be maintained (using the definitions available in RFC 5226)?

There are initial contents for the Return code registry as follows:

Return
Code    Assignment                  Reference
====|==============|===========
  0    Request message            [ RFC-to-be ]
  1    Reply message              [ RFC-to-be ]
2-255  Unassigned

For each Return Code in the registry above, IANA understands that there will be an associated sub-code registry.

Sub Codes for TRILL OAM Return Code 0

Sub    Description                  Reference
Code
===|===============|=========    0  Valid Request                [ RFC-to-be ]
1-255  Unassigned

Sub Codes for TRILL OAM Return Code 1

Sub    Description                  Reference
Code
===|===============|==========
    0  Valid response                [ RFC-to-be ]
    1  Fragment limit exceed        [ RFC-to-be ]
    2  Intermediate RBridge          [ RFC-to-be ]
3-255  Unassigned

IANA understands that these six actions are the only ones that need to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (TRILL Fault Management) to Proposed Standard


The IESG has received a request from the Transparent Interconnection of
Lots of Links WG (trill) to consider the following document:
- 'TRILL Fault Management'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-07-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies TRILL OAM Fault Management. Methods in
  this document follow the IEEE 802.1 CFM (Continuity Fault
  Management) framework and reuse OAM tools where possible.
  Additional messages and TLVs are defined for TRILL specific
  applications or where a different set of information is required
  other than IEEE 802.1 CFM. This document updates RFC 6325.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-trill-oam-fm/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-trill-oam-fm/ballot/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/2082/

Form version: 24 February 2012.
Submission date:
Document Shepherd: Susan Hares
WG Chairs: Jon Hudson and Donald Eastlake
AD: Ted Lemon:

(1) RFC type: Proposed Standard
Correct type because it is OAM for Fault management.  (Standard Track on page)

(2) The IESG approval announcement includes a Document Announcement
Write-Up.

Technical Summary

This document specifies the TRILL OAM Fault management.  Methods in this
document follow the IEEE 802.1 CFM (Continuity Fault Management) framework
and reuse OAM tools wherever possible.  Additional messages are defined
and TLVs are defined for TRILL specific applications or where a different
set of information is required other than IEEE 802.1 CFM.  This proposed
standard does update RFC 6325.

Working Group Summary

The WG has worked on the TRILL OAM FM within the working group, and with
the IEEE 802.1 task group. This solution provides a blended solution
between TRILL and 802.1 OAM.  The final review 3/7 - 3/24 garnered
a editorial comments, but no significant technical comments. 

Document Quality

The TRILL OAM FM has implementations begun in the Cisco, Huawei, and
other router companies (2-3).  The co-authors on this draft are in
touch with the implementation teams at Cisco and Huawei, and in-touch
with some members of the 802.1 Working Group within the IEEE.

The document's text and logic is excellent.  Even with the ~60 page
length, the shepherd found very few editorial issues.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The Shepherd did a detailed review resulting in the numerous changes
from draft version -03 to -04 to -05 including editorials, IANA
Considerations fixes, and reference updates. No technical changes were
made. (There is one remaining glitch, a single missing character in
one occurrence of "[RF7180]" that should be "[RFC7180]". This can be
fixed as part of AD review or the reslution of IETF Last Call
comments.)


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No, the implementers are reviewing the document during coding and
debugging. Textual edits have been done by Tissa Senevirathne.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

IANA needs to review section 15. Shepherd/Secretary will request that
the IANA do an early review.

OPSDIR needs to review all of document. Shepherd/Secretary will request
that OPSDIR Do an early review. 

RTGDIR should do a review of the OAM FM. Shepherd/Secretary will request
that RTGDIR do an early review.

Some members of the IEEE 802.1 WG have been reviewing this document,
and a key contributors (Norm Finn and Donald Eastlake) have worked on
this draft.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of?

No concerns. This draft demonstrates fine collaboration between the
some members of the IEEE 802.1 WG and TRILL.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

WG LC on IPR was issued on 4/14/14 and all authors have now
responded. Cisco disclosed IPR https://datatracker.ietf.org/ipr/2082/


(8) Has an IPR disclosure been filed that references this document?

IPR 2082 filed:
Cisco is the owner of US Published Patent Applications 20120014261
and 20110194403 relating to the  subject matter of "TRILL Fault Management" .

Cisco wil not assert patent on usage if other company does not assert patents.
[mutual patent assertion] if this becomes a standard.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid consensus of those implementing. Current silence occurs after
2-3 years of discussions.

(10) No appeals, no disconnect, only - this is done!

(11)
NITS - Miscellaneous warnings:
1) Warning - but this does not have work before 2008
2) document - 53 days in past -

Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

Document needs IANA, OPSDIR, and RTRDIR Review.
Early reviews will be requested.

(13)/(14)/(15) Normative/informative

All References are normative or informative. All normative references
are specified, and no normative reference is downward.


(16) Will publication of this document change the status of any
existing RFCs?

This updates RFC 6325, and this is listed.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.

To the Best of The shepherd's review, the registries are correctly specified.
Due to the number of IANA assignments, an early review will be requested. 


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

New registry created in Section 15.4 for return codes for PTR (Path
Trace Reply) messages, uses IETF Review so no new Expert required.

Existing registries:

section 15.1 TRILL-VER Sub-TLV Capability Flags - IETF review

section 15.2
CF OAM IETF Parameters registry set up by
draft-eastlake-iana-cfm-considerations-02.txt with assignment by
Standards Action.  This section requests assignment of OpCodes from
this new registry.  This section requests assignment of TLV Types from
this new registry.

section 15.3 requests 2 MACs from the IANA MAC ADDRESS Block.
This block requires expert review (Donald Eastlake, Dan Romascanu)


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No XML, no BNF, No Mib.