Skip to main content

Telechat Review of draft-ietf-mpls-tp-ethernet-addressing-07

Request Review of draft-ietf-mpls-tp-ethernet-addressing
Requested revision No specific revision (document currently at 08)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-04-23
Requested 2013-04-12
Authors Dan Frost , Stewart Bryant , Matthew Bocci
I-D last updated 2013-04-19
Completed reviews Genart Telechat review of -07 by Martin Thomson (diff)
Secdir Last Call review of -05 by Tobias Gondrom (diff)
Assignment Reviewer Martin Thomson
State Completed Snapshot
Review review-ietf-mpls-tp-ethernet-addressing-07-genart-telechat-thomson-2013-04-19
Reviewed revision 07 (document currently at 08)
Result Ready w/issues
Completed 2013-04-19
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other (post) Last Call comments
you may receive.

Document: draft-ietf-mpls-tp-ethernet-addressing-07
Reviewer: Martin Thomson
Review Date: 2013-04-19
IETF LC End Date: 2013-02-18 (!)
IESG Telechat date: 2013-04-25

Summary: This document is almost ready for publication as proposed
standard.  There are some minor issues

Major issues: None

Minor issues:

The structure of the document is odd.  The individual pieces of
explanation are good, it's just that different bits are revealed in a
strange order.  If the intent is to describe a method of selecting an
Ethernet address to attach to MPLS-TP packets, I would have thought
that structuring the document to correspond to the prioritization of
methods would make sense.  That is, from what I can infer:
If unicast, use a unicast address (MUST for multipoint attachment,
SHOULD for others)
  1. from G-ACh, if available
  2. from static configuration, if operationally feasible
otherwise, for point-to-point links you can use
  3. the IANA-assigned special address
Reordering might help with understanding the process.

If multicast/broadcast LSPs, there doesn't seem to be any actual
recommendations or advice in the document.  There is only an
admonition to use encapsulation, which is probably necessary for other
reasons anyhow.  So it's not clear how Section 3, paragraph 1 is
relevant to this document.  It doesn't offer any guidance on how one
might select an appropriate Ethernet address for those frames.
Presumably these could be unicast, multicast or broadcast depending on
routing requirements for the LSP, in which case maybe there is no good
advice to give. If there really is no good advice to give, or there is
no intent to provide advice for multicast/broadcast LSPs, a statement
to that effect would be helpful.

Section 3, Paragraph 2 just reiterates parts of Section 2, it could be removed.

S5: I can't reconcile "The advertised information SHOULD be persistent
across restarts."  with "Received advertisements MUST be discarded
across restarts."

S4, pp5: Why force a mapping to EUI-64?  Is canonicalization important
for some reason?

S4, pp5: The paragraph beginning with "In the event a GAP message is
not received within the previously received associated Lifetime, ..."
is a little confusing (and I'm familiar with G-ACh already).  This
could be clearer.  Maybe:  "A node could cease transmission of G-ACh
advertisements, or cease to include a Source MAC Address TLV in
advertisements, either of which cause the TLV lifetime to elapse.
After the Source MAC Address TLV lifetime has elapsed, this value
SHOULD no longer be used to select a MAC address; the node SHOULD
return to selecting MAC addresses as though no advertisements were

S7.3: IETF review is a pretty high bar.  (Sadly, I missed this on
G-ACh, or I would have made the same comment.)  Did you consider
allowing IESG Approval as an alternative?

Nits/editorial comments:
There are a couple of lowercase instances of RFC2119 keywords that
could be confusing.  The very last line of S4, the second last
sentence of S2.  Consider alternative wordings for these statements.

S2, pp3: s/i.e.  /i.e., /