MPLS Transport Profile (MPLS-TP) Next-Hop Ethernet Addressing
draft-ietf-mpls-tp-ethernet-addressing-08

No objection to the publication of this document, but please address the two points below.
Note: I discussed those points with Stewart, and we agreed that the text needs to be improved.

1.
There are 2 SHOULD in the following paragraphs:
   ...
   If existing mechanisms are available in an MPLS-TP network to
   determine the destination unicast MAC addresses of peer nodes -- for
   example, if the network also happens to be an IP/MPLS network, or if
   Link Layer Discovery Protocol (LLDP) [LLDP] is in use, or if it
   implements the procedures in Section 4 of this document -- such
   mechanisms SHOULD be used.  The remainder of this section discusses
   the available options when this is not the case.

   ...
   In view of the above considerations, the approach which SHOULD be
   used, is therefore to configure both nodes to use the method
   described in this document which uses, as a destination MAC address,
   an Ethernet multicast address reserved for MPLS-TP for use over
   point-to-point links. 

If I have ARP or LLDP, the first SHOULD apply. However, there is also a SHOULD for the new mechanism in this document. So which method should I use as a default?

Discussing with Stewart, the authors should make it clear that  
1. If ARP/LLDP is/are available, they are the preferred methods
2. If ARP/LLDP is/are not available, rather than using the hand configured unicast or the broadcast address mechanisms, use the 01-00-5E-90-00-00 mechanism

2.
Manageability Considerations

Because this mechanism proposed in this document relies on point-to-point interfaces only, you're missing that the interface type, whether point-to-point or multi-point, must be clearly labeled, and this information must be available to the network operator. Any changes of interface type must be notified to the network operator.
See my next email to the OPS-DIR on this topic.

Just a couple of editorial nit-picks...

1. I don't think I have ever heard of "Ethernet Address Resolution Protocol (ARP)".  Since ARP works on links other than Ethernet, I would suggest dropping reference to Ethernet.  This standardizes the description of ARP in the same way NDP is described.

2. The references [EUI-64] and [LLDP] have all sorts of extraneous punctuation that can be cleaned up.

(Updated to a comment, based on feedback.)

A new Gen-ART review recently arrived on this document. Can the authors, shepherds, or sponsoring ADs take a look and see if there is something that you think should be addressed? The review is at http://www.ietf.org/mail-archive/web/gen-art/current/msg08439.html and also copied below.

Also, regarding the S7.3 comment, we do often use IANA policies of the form "<policy> or IESG Approval", because it allows an IESG approval for the eventual special case. I would consider this model for this document as well.

-------

Martin Thomson's Gen-ART review:

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
 4. FF-FF-FF-FF-FF-FF
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
received."

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., /

I would observe that you should never use garp or ndp  messages for 01-00-5E-90-00-00 to update an L2 next hop which gets back to the question of what is or isn't point to point.

I don't know that, that observation needs to make it into the text so no objection.

"You might want to review your RFC 2119 usage before passing this to the RFC Editor."

- section 2, 2nd last para on p3: I'm not clear whether an
implementation MUST process frames sent to 01-00-5e-90-00-00
if the implementation doesn't know that the link is
point-to-point or knows that the link is not point-to-point.
You could also maybe be clearer about what "MUST process"
means, not sure if that's obvious or not (maybe it is), but
if I send a huge chunk of garbage bytes to that MAC address,
would all be well? Maybe such fuzzing would also be worth a
security consideration? (Not sure, maybe that's covered
elsewhere or ought be covered elsewhere.)

- section 4, is "maximum frame size octets" a typo? Maybe "in
octets" was meant?

- section 4, MFS == 2^32-1 seems very big. Is there a
potential DoS vector there? Maybe a bad node could set this
huge to try get the peer to buffer too much stuff or
something? Ought implementatations also have their own
max-max value or generate an alert or something if a too-big
MFS is received? You already mention a too-small MFS in the
security considerations, so maybe this is also worth a
mention?

- section 6: I'm not sure of the real use-cases for this, but
are there cases where you really really ought to be turning
on the authentication defined in mpls-gach-adv? If there
are, wouldn't it be good to describe those a bit and say
that they do really need to use the crypto stuff?