Subject: [mpls] AD review of draft-ietf-mpls-tp-ethernet-addressing

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 11 Jan 2013 22:29:25 -0000

Hi,

I have conducted my usual AD review of your document as part of the
publication request processing. The aim of my review is to catch any
issues that might show up in IETF last call, directorate reviews, or
IESG evaluation. The intent is to resolve the issues by text changes
or through email discussion to smooth the passage of the document
through the later stages of the process.

I have reviewed this document jointly with draft-ietf-mpls-gach-adv
and since the author team is the same for the two documents, I
recommend that you process the comments for the two documents at the
same time.

As usual, all my comments are open for disagreement and discussion. I
think that you will probably want to produce a revision of this 
document to address my comments, so I have put it into "Revised I-D
Needed" state in the data tracker.

Thanks for the work,
Adrian

===

The abbreviations GAL and OAM are not used in the document and can be 
removed from Section 1.1.

---

Am I missing something? Why do you only support 48-bit MAC addresses?

---

I am *really* surprised that this document does not mention LLDP. In
[I-D.ietf-mpls-gach-adv] you state...

   Where
   it is anticipated that the sole purpose of the GAP will be to provide
   Ethernet MAC address learning, the use of LLDP SHOULD be considered.

So this document needs to say the same thing (all over and in 18pt red
bold). Furthermore, it needs to define what "HOULD" means in this
context. 

---

In Section 4...

Could you please identify (with TBD1 - to be assigned by IANA) the
application ID of the new "Ethernet Interface Parameters" application.

Could you please state: "The format of the TLVs is as defined in 
[I-D.ietf-mpls-gach-adv].

Could you please include the type values for the two TLVs you are
defining (so that people don't have to look ahead to the IANA section).

Since the two TLVs you are defining have predictable lengths, it would
be nice if you included the specific length values to be used.

---

I think section 4 is missing something. It is clear from
[I-D.ietf-mpls-gach-adv] that at least one TLV must be present in the 
Ethernet Interface Parameters" ADB element. Is there a requirement that
the Source MAC Address TLV is always present? What are the rules for
multiple occurrences of either of the TLVs you have defined?
                 
---

Somewhere, probably Section 4, should leverage the stated intention in
[ID.ietf-mpls-gach-adv] by stating that the values received in the new
ADB element SHOULD (or probably MUST) be made accessible for inspection
by network operators, and where local configuration is updated by the
received information, it MUST be clear why the configured value has
been changed. Furthermore, you probably need to discuss whether
information learned in this way is allowed to be persistent across
node or interface discontinuities. (The last point suggests to me that
you might want to include a brief section on handling changes in
adjacent MAC addresses - a point that you have given as a motivation
for the work.)

---

In my comments on [I-D.ietf-mpls-gach-adv] I ask about the consequences
of message loss. This issue seems to apply to this document so, 
depending on how you handle the issue in [I-D.ietf-mpls-gach-adv] you
may need to add something to this document.

---

Section 5 should reference [I-D.ietf-mpls-gach-adv] for the security
properties of the GAP. It should probably note that an effective 
attack is modifying the Source MAC Address value, while modifying the
MTU value may also have significant consequences. Furthermore, it may
be the case that visibility into the contents of either of the TLVs
could provide information that is useful for an attacker.

---

In section 6.1, please include an IANA action to update the reference
for the MAC address to point to the RFC number assigned to this 
document on publication.

---

In section 6.2, could you please replace 0x0001 with TBD1.

---

Trivial point, but there are precisely three authors, all marked as 
editors. You could safely dispense with the "editor" designation (on
the front page and in the Authors' Addresses section).