Thanks for following up, and for the re-send. Just to be clear, I do not mean these as blocking points.
On the former point, I might just suggest a minor edit to the introduction: OLD: "This document specifies the options for determination and selection of next-hop Ethernet MAC addressing under these circumstances." NEW: "This document specifies the options for determination and selection of next-hop Ethernet MAC addressing when MPLS-TP is used in a "pure Ethernet" manner, without any IP forwarding capability." On the latter point, I can understand the desire to make the simple case simple, and the text at the end of Section 2 sends a clear warning. It does seems like GAP would also allow autoconfiguration without further NMS interaction. (Unless the NMS is configuring per-Ethernet-address policies, e.g., "forward packets with this label to 00:11:22:33:44:55". Is that the case?) On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant <stbry...@cisco.com> wrote: > 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 > >
