Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
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). 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
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
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.commailto: 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.htmlhttp://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html http://www.alvestrand.no/**ietf/gen/art/gen-art-FAQ.htmlhttp://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
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
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
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
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
Re: Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
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
Gen-ART review of draft-ietf-mpls-tp-ethernet-addressing-05
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.
