Hi Stewart, I think this resolves my issues.
Thanks, --Richard On Mon, Apr 8, 2013 at 6:53 AM, Stewart Bryant <stbry...@cisco.com> wrote: > On 02/04/2013 15:28, Richard Barnes wrote: > >> 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." >> > > After various rounds of tweeking: > > "This document specifies the options for the determination and selection > of the next-hop Ethernet MAC address when MPLS-TP is used between nodes > that do not have an IP dataplane." > > The subtly is the network may be mixed IP capable and non-IP capable. > > > > >> 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?) >> > Yes. One case is a network that is generally NMS configured, and wants to > use unicast MAC addresses, but wants to allow the craft people to plug in a > new linecard without talking to the NMS. In such circumstances the only > auto config would be teh MAC addresses. > > Stewart > > >> >> >> >> On Tue, Apr 2, 2013 at 9:10 AM, Stewart Bryant <stbry...@cisco.com<mailto: >> 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<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html> >>> >>> <http://www.alvestrand.no/**ietf/gen/art/gen-art-FAQ.html<http://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<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> >> >> >> > > -- > For corporate legal information go to: > > http://www.cisco.com/web/**about/doing_business/legal/**cri/index.html<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> > >
