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

[Stewart Bryant <[e-mail]>]

Lou

Thanks for the review. Please see inline.

On 17/02/2013 13:55, Lou Berger wrote:
> 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.)
I have added

The choice of lifetime for the TLV is an operational issue and not an 
inter-working
issue, and thus the operator is free to set the lifetime according to 
their own
preference. There is no requirement for the lifetime to be symmetric. To
expedite the initialization of a link it is RECOMMENDED that a node that
has been reconfigured, rebooted or is aware that it have been disconnected
from its peer send a GAP Ethernet Interface Parameter message, and that it
issues a GAP request message for the Ethernet parameters at the earliest
opportunity.


>
> - Some guidance on how address changes should be handled.
I have added

When the MAC address in the received Source MAC Address TLV changes
the new MAC address MUST be used (see Section 5.2 of 
[I-D.ietf-mpls-gach-adv].

>
> - Some guidance on how MTU changes should be handled.
I have added

If a minimum MTU is configured for a link and the MTU advertised by the 
peer
is lower than that minimum, the link the NMS MUST notified of the event.
Under these circumstances the operator may choose to configure the LSR
to shut the link and trigger thereby triggereing a fault and causing the
end-to-end path to be repaired, or they may choose to leave the link
up so that an OAM message can is used to verify the actual MTU.
>
> - 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).
The MTU definition now says:

MTU (type = 1, length = 4): The Value of this object is a 32-bit unsigned
integer encoded in network byte order that specifies the maximum
transmission unit size in octets of an MPLS label stack plus payload
that can be sent over the sending interface.

I am unconvinced that a reference is needed, although if you can find
one that fits this description I am not averse to including it. However
the new definition seems self defining.

>
>
> 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]
Ref added
>
> - TLV formats should be provided for the defined TLVs
Done
>
> - "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?
The degree of loss is a matter for the operator.

The latter point is already covered in the text.
>
> Section 5:
> - Earlier in Section 4 you say, "...must behave as configured for this
> eventuality.", but such configuration isn't mentioned in section 5.
I am beginning to think that manageability consideration sections are
more of a liability than they are worth. I would assume that the
implementer will read the whole text and provide the required controls
without the need to list them in this section. This section is a reminder
of text in the GAP protocol document and could if you prefer be deleted.
>
> - Reporting of MTU mismatch counts and/or details is probably worth
> mentioning (and optionally reporting).
That is now with the MTU text.
>
> 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.
That would surely be a strange thing to do, but presumably is
what the  operator intended. I would leave it to the
implementation to choose if and how it logged such an event.
>
> 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 ..."
done.
>
> 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.
It is a bit late, but will discuss with the others.

- Stewart