Resending due to Richards change of address.
Stewart
On 11/02/2013 23:45, Richard Barnes wrote:
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART,
pleaseseehttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or AD before posting a
new version of the draft.
Document: draft-ietf-mpls-tp-ethernet-addressing-05
Reviewer: Richard Barnes
Review Date: 2013-02-11
IETF LC End Date: 2013-02-18
IESG Telechat date: TBD
Summary: Ready, with a couple of minor questions / clarifications.
Comment:
The document is mostly very clearly written. (Thanks!) It would have helped me
understand if it could have been clarified up front that the mechanism in this document
is intended for "pure Ethernet" MPLS-TP (without assumptions about layer 3+).
The current introduction says as much, but in a negative way, in terms of ARP or ND not
being available.
I have some minor unease about the distinction that this document makes between
point-to-point and multipoint links. The document correctly notes that a
point-to-point link might become multipoint without either end being aware. I
would have thought this would argue for using GAP in all cases, but instead the
document carries on with addressing the point-to-point case separately..
Richard
It is always difficult when writing a simple draft dealing with a small
component of a larger technology to know how much tutorial to include,
but I believe the point about operation in the absence IP would be well
known
to anyone implementing this. In particular we assume that anyone
implementing the draft would have read the required references called
up in the first paragraph of the Introduction:
" The MPLS Transport Profile (MPLS-TP) [RFC5921] is the set of protocol
functions that meet the requirements [RFC5654] for the application of
MPLS to the construction and operation of packet-switched transport
networks. The MPLS-TP data plane consists of those MPLS-TP functions
concerned with the encapsulation and forwarding of MPLS-TP packets
and is described in [RFC5960]."
RFC5654 says:
" 36 It MUST be possible to operate and configure the MPLS-TP data
plane without any IP forwarding capability in the MPLS-TP data
plane. That is, the data plane only operates on the MPLS label."
Thus I think that the text is complete as it stands and requires no
further clarification for anyone that needs to consider the technology
it describes.
With regard to your second point, the issue that we are have, is that
there are a number of deployment scenarios where the operator knows
that the link is Pt-Pt, and there is a reluctance by that community to
use anything other than NMS configuration. That has lead them
to use Ethernet broadcast addressing which allows the crafts to
change h/w without the need for reconfiguration by the NMS.
Against that background moving them onto the use of a Ethernet m/c
address is a step forward. To require using the GAP to that
community would illustrate that the IETF is out of touch with
their needs and methods of network operation.
Hopefully this additional background, which I believe is well
known to the MPLS-TP community to which this draft is directed,
satisfies your concern on the latter point.
- Stewart
--
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html