[mpls] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt

[Lou Berger <[e-mail]>]

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-mpls-tp-ethernet-addressing-05.txt
Reviewer: Lou Berger
Review Date: 2013-02-17
IETF LC End Date: 2013-02-18
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be
resolved before publication.

Comments:

This document is pretty straight forward and I don't have any major
issues with it.  I found the "MAC address discovery" a bit thinly
defined.  This document relies on the mechanisms defined in
draft-ietf-mpls-gach-adv which has just entered last call.


Major Issues:

I think the "MAC address discovery" mechanisms defined in Section 4,
need some additional details in order to ensure independent
interoperable implementations. I don't think any of these issues should
difficult or controversial, but I think they should be blocking.

I think the following really needs to be covered:

- The frequency in which the discovery information needs to be (re)sent
& retained.  (I think this is simply 1 or 2 sentences that relate back
to Lifetime defined in gach-adv.)

- Some guidance on how address changes should be handled.

- Some guidance on how MTU changes should be handled.

- MTU scope needs to be defined.  It is completely unclear if MTU is
intended to be the MTU based on the maximum frame size supported by the
sending physical interface represented in the Source MAC Address TLV, or
the MTU supported by the logical (IP) interface associated with the
Source Address TLV.  The ability to advertise the latter is IMO the
minimum required, which I assume was the intent of the document, and
just needs to be clarified.  Also the basic term should be defined (via
appropriate reference).


Minor Issues:

Section 4:
- since assignment of the mac address is not in this document:
  s/01-00-5e-80-00-0d/defined in Section 7 of [mpls-gach-adv]

- TLV formats should be provided for the defined TLVs

- "Persistent loss" should be defined in quantitative terms.  Also which
GAP messages, all?  What about handling of the case where GAP messages
are received, but no MAC address TLVs are included?

Section 5:
- Earlier in Section 4 you say, "...must behave as configured for this
eventuality.", but such configuration isn't mentioned in section 5.

- Reporting of MTU mismatch counts and/or details is probably worth
mentioning (and optionally reporting).

Section 6:
- I think it would be worth mentioning that Section 5 based Address
Discovery allows the advertised MAC to be different than the MAC frame
source address, and covering related security implications.

Nits:

Section 2:
- for clarity,
    s/these forms of/broadcast or multicast
  in
   "not known to be point-to-point, these forms of addressing MUST ..."

One final comment: While I'm sure it's too late to make such a change, I
think including MTU in the [mpls-gach-adv] Source Address TLV (in place
of the reserved field) would have simplified the protocol.  -- clearly
this is not a blocking comment or one that really needs to be addressed.

That's it,
Lou