From curtis@ipv6.occnc.com Mon Jan 6 09:00:15 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CDE1AE064; Mon, 6 Jan 2014 09:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.261 X-Spam-Level: X-Spam-Status: No, score=0.261 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxwxLm98sDdY; Mon, 6 Jan 2014 09:00:11 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id E0F791AE100; Mon, 6 Jan 2014 09:00:10 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s06H00HS011318; Mon, 6 Jan 2014 12:00:01 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401061700.s06H00HS011318@maildrop2.v6ds.occnc.com> To: Lou Berger In-reply-to: Your message of "Wed, 11 Dec 2013 13:57:47 -0500." <52A8B5AB.4040708@labn.net> From: Curtis Villamizar Date: Mon, 06 Jan 2014 12:00:00 -0500 X-Mailman-Approved-At: Mon, 06 Jan 2014 09:11:19 -0800 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" , curtis@ipv6.occnc.com Subject: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 17:00:15 -0000 Lou et al, Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went through to all recipients. There may have been a problem (due to a self inflicted DNS issue). I did not get a response so I suspect Lou didn't get this email. Curtis In message <52A8B5AB.4040708@labn.net> Lou Berger writes: > > 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. 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-rtgwg-cl-requirement-13.txt > Reviewer: Lou Berger > Review Date: 2013-12-11 > IETF LC End Date: 2013-12-09 > Intended Status: Informational > > Summary: > > I have some minor concerns about this document that I think > should be resolved before publication. > > Comments: > > I think the document is greatly improved since the previous last > call. I have some comments and reservations on the document that are > described below. As discussed on the list, I remain concerned about the > value of defining requirements in terms of nebulous "Performance > Objectives", but as this is acceptable to the WG I will not elaborate on > this concern further. > > Major Issues: > > No major issues found. > > Minor Issues: > > 1. Terminology & consistency: the document coins the term "Advanced > Multipath": > Advanced Multipath is a formalization of multipath techniques > > Do you see this term as a new noun, like LSP, or as an adjective? I > expected the latter, i.e. that it be used like "multipath" is used in > the above sentence, but it seems to be used as a new noun. I'm not sure > coining a new noun really makes sense, but if this the intent then the > last paragraph of section 2 needs to be revised as "Advanced Multipath" > will now have a specific definition as opposed to a generic term. Also I > suggest always capitalizing it (or even using the abbreviation "AM") > will clarify this distinction. I see multipath as a noun and therefore advanced multipath as a noun. Advanced is an adjective, multipath as a noun. Advanced Multipath is the set of techniques that form a solution. An advanced multipath is a collection of componet links. The former is capitalized, the latter is not. I'll check to see if I got that right in all occurances. If you would like I can also add this to the definition making it: OLD Advanced Multipath Advanced Multipath meets the requirements defined in this document. A key capability of advanced multipath is the support of non-homogeneous component links. NEW Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. An "advanced multipath" is a collection of component links. In this document the former is capitalized and the latter is not. If we agree on this I'll just search for "advanced" and make capitalization consistent with the above statements. I don't think the phrase "advanced multipath technique" makes it an adjective any more than a statement such as make-before-break is an MPLS technique" makes MPLS an adjective in normal use. The phrase "an X technique" is simply a shorthand for indicating a "technique applicable to X". Even if that makes it an adjective the phrase "MPLS technique" is common and so that should not be a problem. The paragraph in question might be the following. It seems benign to me. The term Advanced Multipath is intended to be used within the context of this document and the related documents, [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and any other related document. Other advanced multipath techniques may in the future arise. If the capabilities defined in this document become commonplace, they would no longer be considered "advanced". Use of the term "advanced multipath" outside this document, if referring to the term as defined here, should indicate Advanced Multipath as defined by this document, citing the current document name. If using another definition of "advanced multipath", documents may optionally clarify that they are not using the term "advanced multipath" as defined by this document if clarification is deemed helpful. I see no problem with this. Please be more specific if you think there are places where advanced multipath is used as an adjective or where its use is confusing. > 2. Editorial: server and client layer vs upper and lower layer. > > The document uses server and client layer networks and LSPs and, > sometimes interchangeably or redundantly, upper and lower layer networks > and LSPs. I think this issue can be resolved by avoiding the term > client/server when referring to network layers and just using the > lower/upper terminology. The one exception to this is in the definition > Client LSP which should simply be defined in the context of a multipath, > i.e.: > OLD > A client LSP is an LSP which has been set up over a server layer. > NEW > A client LSP is an LSP which has been set up over Advanced Multipath. A client LSP can be set up over a server layer MPLS-TP LSP or any server layer MPLS LSP or over a link layer or over a pseudowire ... or over an advanced multipath. > I think this also means that usage of the term "Client" is limited to > "Client LSP". I searched for all occurances of the word client. All occurances are "client LSP" excexpt the phrase "client of a client LSP" and that is used only in the following paragraph. The ingress and egress of a multipath may be midpoint LSRs with respect to a given client LSP. A midpoint LSR does not participate in the signaling of any clients of the client LSP. Therefore, in general, multipath endpoints cannot determine requirements of clients of a client LSP through participation in the signaling of the clients of the client LSP. THe point is that "A midpoint LSR does not participate in the signaling of any clients of the client LSP" and that non-participation in client (or higher layer) signaling applies to any "client of a client LSP", not just other LSP running over it. I then searched for all occurances of the words upper and lower and higher. There are no occurances of "upper". There were a few occurances of "lower latency" and "higher latency". Other than that, all occurances of lower and higher except one are in the follwoing text: 3.2. Component Links Provided by Lower Layer Networks A component link may be supported by a lower layer network. For example, the lower layer may be a circuit switched network or another MPLS network (e.g., MPLS-TP)). The lower layer network may change the latency (and/or other performance parameters) seen by the client layer. Currently, there is no protocol for the lower layer network to inform the higher layer network of a change in a performance parameter. Communication of the latency performance parameter is a very important requirement. Communication of other performance parameters (e.g., delay variation) is desirable. FR#8 The solution SHALL specify a protocol means to allow a lower layer server network to communicate latency to the higher layer client network. The exception is this sentence: FR#22 The solution SHOULD support the use case where an advanced multipath itself is a component link for a higher order advanced multipath. For example, an advanced multipath comprised of MPLS- TP bi-directional tunnels viewed as logical links could then be used as a component link in yet another advanced multipath that connects MPLS routers. The terms lower layer and higher layer go all the way back to the ISO seven layer model of ancient times (1970s?, 1980s?) and maybe further back but that is before even my time. I don't think this is unclear but I could add the following in definitions: Higher Layers A client layer is the one immediately above a server layer. The client layer and all layers above that layer are higher layers. Lower Layers A server layer is the later immediately below a client laer. The server layer and all layers below are lower layers. Do I really need to put this in the definitions section? If yoy think it is necessary, I will add it. > 3. Technical: The document should make it clear that LSPs can provide > paths from an Advanced Multipath. I suggest adding something like the > the following at the end of page 3 > d. a lower layer LSP. Case "b." is intended to include LSP but is not specifically limited to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, Ethernet Link Aggregation, and all sorts of things that don't involve MPLS at all. For example, a path in Ethernet Link Aggregation Group (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though this would be unknown to the LAG, or in the simplest case each path in the set of LAG members could be supported by a plain Ethernet cable. > and at the end of the Component Link definition: > A component link may be provided via an LSP. I think this is covered in "3.2. Component Links Provided by Lower Layer Networks". 3.2. Component Links Provided by Lower Layer Networks A component link may be supported by a lower layer network. For example, the lower layer may be a circuit switched network or another MPLS network (e.g., MPLS-TP)). This sort of statement could be made earlier. For example in the discussion following the definitions (on page 5) the document covers one case (where a component link is not an LSP) but it is not until later that the other case is mentioned. I could add a paragraph in the discussion following the definitions that mentions that a component link can also be another LSP. OLD: A Component Link may be a point-to-point physical link (where a "physical link" includes one or more link layer plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's Performance Objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub- layers, including those providing physical layer emulation. NEW: A Component Link may be a point-to-point physical link (where a "physical link" includes one or more link layer plus a physical layer) or a logical link that preserves ordering in the steady state. A component link may have transient out of order events, but such events must not exceed the network's Performance Objectives. For example, a component link may be comprised of any supportable combination of link layers over a physical layer or over logical sub- layers, including those providing physical layer emulation, or over MPLS server layer LSP. These are identical except the phrase ", or over MPLS server layer LSP" added to the end of the last sentence. > 4. Editorial: Unless I'm mistaken, the requirements in this document > apply to the Advanced Multipath solution. In most cases the document > states requirements in the form of "The solution", but in a few cases it > just says "advanced multipath". I think these cases should be changed > to apply to an "Advanced Multipath solution". I think this comment > applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. That is not correct. For example: FR#1 An advanced multipath MAY be announced in conjunction with detailed parameters about its component links, such as bandwidth and latency. The advanced multipath SHALL behave as a single IGP adjacency. In this requirement the "advanced multipath" is a specific collection of component links that is announced by way of an MPLS Forwarding Adjaccency (FA) in the IGP. The same is true for the other requirements cited. In all of these cases an advanced multipath is a specific collection of component links. There is a typo in MR#1. OLD MR#1 Management Plane MUST support polling of the status and configuration of an advanced multipath and its individual advanced multipath and support notification of status change. NEW MR#1 Management Plane MUST support polling of the status and configuration of an advanced multipath and its individual component links and support notification of status change. In the last line s/advanced multipath/component links/ > 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > In these cases it is unclear if the requirements apply to > (a) a client's ability to indicate a desired service/LSP constraint or > (b) a selected component link's attribute that will be used by a client > LSP, > (c) both, or > (d) something completely different > The requirements should be clear to which entity the requirement applies. This "indication" can be through signaling or the management plane and both must be supported in later framework and protocol definitions and we can argue then whether both must be supported or if one or the other is a "should" in RFC 2119 speak. There was concern that the word "signal" would exclude providing the same informantion through the management plane and therefore the word "indicate" is used. Rather than spell this out many times we hoped this would be clear. I could add clarifying text up front if you think this is necessary. For example, I could add the following before FR#1. FR#0 In requirements that follow in this document the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents providing framework and protocol definitions both signaling and management plane mechanisms MUST be defined. It would be trivial to make this FR#1 and renumber the rest. Should I add it and renumber? > 6. The last paragraph in section 3.3. strikes me as both odd and out of > place. There are so many possible decisions that must be considered by > network operators relative to disruption and optimization. Why mention > just "power reduction"? Is there something special about the > interactions of multipath and power reduction? What value / information > does this paragraph add? The last paragraph in section 3.3 is: Allowing multipath to contain component links with different characteristics can improve the overall load balance and can be accomplished while still accommodating the more strict requirements of a subset of client LSP. I'm not sure if this is the "odd and out of place" paragraph you refer to. It summarizes the purpose of the requirements in this section. I think you mean section 3.5 and not 3.3. The remainder of your paragraph above discusses power reducetion and this is only mentioned in section 3.5 so I think you mean this paragraph. As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive. Typically the disruption is limited to a change in delay characteristics and the potential for a very brief period with traffic reordering. The network operator when configuring a network for power reduction should weigh the benefit of power reduction against the disadvantage of a minimal disruption. The paragraphs following a set of requirements provide discussion related to that set of requirements. I don't see this as out of place. The prior two paragraphs discuss delay discontinuity. This paragraph is a reminder that "As with any load balancing change, a change initiated for the purpose of power reduction may be minimally disruptive." I don't see this as out of place. For example, to compensate for a less than perfect load balance a subset of LSPs may need to be moved and that subset can be chosen from those which will be least affected (and there are plenty of requirements that compell the fussy LSP to tell the network abour their specifial needs). To power down a component link, *all* LSP on that component link need to be moved, even the very fussy ones. Therefore I think mentioning that disruption should be considered is not out of place in the discussion following these requirements. We like to keep the discussion brief so this level of detail was not included. > 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? At the very least it means something similar to same administrative domain. An AS can be subdivided within an organization. Do you have a better way to define intra-domain and inter-domain without going down the rat hole of defining the term "domain"? No on in the WG had an issue with this so far but I'm open for a suggestion for better wording. > Nits: > > - References should be provided in all cases when referring to > "existing ... techniques" References are not allowed in the abstract. In section 3.3 is the sentence: Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a description of existing techniques and a set of references. Much of that document is dedicated to describing existing techniques and it contains quite a few references. I can move this sentence. Where in the document would you like to see it moved to? > Using line numbers from > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt Using line number is a text editor counts the page headers. What tool are you using? I didn't see anything on tools.ietf.org. So I'll guess. Looks like add 10 lines per page. > Line 112 > s/SHOULD/should s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ Also remove stray comma. > Line 118 > s/MAY/may s/deployment MAY choose to/deployment may choose to/ OK. Could go either way but s/MAY chose to/MAY/ would work too. > Line 149, match intro: > s/Advanced Multipath meets/Advanced Multipath is a formalization of > multipath techniques that meet OK. > Lines 251-254, beginning with "The" through the end of the paragraph. > This should be an FR. Looks like you mean this: The transient period between some service disrupting event and the convergence of the routing and/or signaling protocols MUST occur within a time frame specified by Performance Objective values. OK. I'll add this as FR#6++. > That's it, > Lou There are a few suggestions for changes to the text based on your comments and a few questions for you. Based on your response to this email I will edit the document. Thanks for the thorough review. Curtis - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- ------- End of Forwarded Message From lberger@labn.net Mon Jan 6 15:12:09 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458851AE2D1 for ; Mon, 6 Jan 2014 15:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkLl_BPsyL8o for ; Mon, 6 Jan 2014 15:12:05 -0800 (PST) Received: from alt-proxy16.mail.unifiedlayer.com (alt-proxy16.mail.unifiedlayer.com [70.40.197.35]) by ietfa.amsl.com (Postfix) with SMTP id E0A1F1AE2CE for ; Mon, 6 Jan 2014 15:12:04 -0800 (PST) Received: (qmail 30705 invoked by uid 0); 6 Jan 2014 23:11:56 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 6 Jan 2014 23:11:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XwscWDznVk6EzQ41dBssbWS2FoBmGYgS3pcQchoE0hM=; b=ZI9wA5pmh++NWAs5vUT9Rmv/DdQ4mDpLXI0vZuxugSiTT/+Y32LEN/jnrlMf8vffPVlJrNFrGwtApHbxdwpNwO/MjXzdcmw3jwkxrwHG39Y3KGA4T8h/3kju9+Bi27rm; Received: from box313.bluehost.com ([69.89.31.113]:46664 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W0JKu-0006hj-3I; Mon, 06 Jan 2014 16:11:56 -0700 Message-ID: <52CB3839.6020704@labn.net> Date: Mon, 06 Jan 2014 18:11:53 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401061700.s06H00HS011318@maildrop2.v6ds.occnc.com> In-Reply-To: <201401061700.s06H00HS011318@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2014 23:12:09 -0000 Hi Curtis, Thanks for the response. See below On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > Lou et al, > > Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > through to all recipients. There may have been a problem (due to a > self inflicted DNS issue). > > I did not get a response so I suspect Lou didn't get this email. > > Curtis > > > In message <52A8B5AB.4040708@labn.net> > Lou Berger writes: >> >> 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. 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-rtgwg-cl-requirement-13.txt >> Reviewer: Lou Berger >> Review Date: 2013-12-11 >> IETF LC End Date: 2013-12-09 >> Intended Status: Informational >> >> Summary: >> >> I have some minor concerns about this document that I think >> should be resolved before publication. >> >> Comments: >> >> I think the document is greatly improved since the previous last >> call. I have some comments and reservations on the document that are >> described below. As discussed on the list, I remain concerned about the >> value of defining requirements in terms of nebulous "Performance >> Objectives", but as this is acceptable to the WG I will not elaborate on >> this concern further. >> >> Major Issues: >> >> No major issues found. >> >> Minor Issues: >> >> 1. Terminology & consistency: the document coins the term "Advanced >> Multipath": >> Advanced Multipath is a formalization of multipath techniques >> >> Do you see this term as a new noun, like LSP, or as an adjective? I >> expected the latter, i.e. that it be used like "multipath" is used in >> the above sentence, but it seems to be used as a new noun. I'm not sure >> coining a new noun really makes sense, but if this the intent then the >> last paragraph of section 2 needs to be revised as "Advanced Multipath" >> will now have a specific definition as opposed to a generic term. Also I >> suggest always capitalizing it (or even using the abbreviation "AM") >> will clarify this distinction. > > I see multipath as a noun and therefore advanced multipath as a noun. > Advanced is an adjective, multipath as a noun. Advanced Multipath is > the set of techniques that form a solution. An advanced multipath is > a collection of componet links. The former is capitalized, the latter > is not. I'll check to see if I got that right in all occurances. If > you would like I can also add this to the definition making it: > > OLD > > Advanced Multipath > Advanced Multipath meets the requirements defined in this > document. A key capability of advanced multipath is the support > of non-homogeneous component links. > > NEW > > Advanced Multipath > Advanced Multipath is a formalization of multipath techniques > that meets the requirements defined in this document. A key > capability of Advanced Multipath is the support of > non-homogeneous component links. Okay. Then I suggest using "AM" will help delineate this usage. > An "advanced multipath" is a > collection of component links. In this document the former is > capitalized and the latter is not. > > If we agree on this I'll just search for "advanced" and make > capitalization consistent with the above statements. the distinction based on capitalization seems likely to introduce confusion in this document and in future uses, so I think it is a really bad idea. > > I don't think the phrase "advanced multipath technique" makes it an > adjective any more than a statement such as make-before-break is an > MPLS technique" makes MPLS an adjective in normal use. The phrase "an > X technique" is simply a shorthand for indicating a "technique > applicable to X". Even if that makes it an adjective the phrase "MPLS > technique" is common and so that should not be a problem. The > paragraph in question might be the following. It seems benign to me. > > The term Advanced Multipath is intended to be used within the context > of this document and the related documents, > [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and > any other related document. Other advanced multipath techniques may > in the future arise. If the capabilities defined in this document > become commonplace, they would no longer be considered "advanced". > Use of the term "advanced multipath" outside this document, if > referring to the term as defined here, should indicate Advanced > Multipath as defined by this document, citing the current document > name. If using another definition of "advanced multipath", documents > may optionally clarify that they are not using the term "advanced > multipath" as defined by this document if clarification is deemed > helpful. > > I see no problem with this. Please be more specific if you think > there are places where advanced multipath is used as an adjective or > where its use is confusing. > I believe my confusion was not understanding the differences between "Advanced Multipath" (with words capitalized) and "advanced multipath" (with words lower cased). While I understand this is your intent, I see it as just leading to confusion. Ultimately, it's the author's / WG's call, i.e., not mine, to make. >> 2. Editorial: server and client layer vs upper and lower layer. >> >> The document uses server and client layer networks and LSPs and, >> sometimes interchangeably or redundantly, upper and lower layer networks >> and LSPs. I think this issue can be resolved by avoiding the term >> client/server when referring to network layers and just using the >> lower/upper terminology. The one exception to this is in the definition >> Client LSP which should simply be defined in the context of a multipath, >> i.e.: >> OLD >> A client LSP is an LSP which has been set up over a server layer. >> NEW >> A client LSP is an LSP which has been set up over Advanced Multipath. > > A client LSP can be set up over a server layer MPLS-TP LSP or any > server layer MPLS LSP or over a link layer or over a pseudowire ... or > over an advanced multipath. > Would you accept s/server layer/lower layer/g? >> I think this also means that usage of the term "Client" is limited to >> "Client LSP". > > I searched for all occurances of the word client. All occurances are > "client LSP" excexpt the phrase "client of a client LSP" and that is > used only in the following paragraph. > > The ingress and egress of a multipath may be midpoint LSRs with > respect to a given client LSP. A midpoint LSR does not participate > in the signaling of any clients of the client LSP. Therefore, in > general, multipath endpoints cannot determine requirements of clients > of a client LSP through participation in the signaling of the clients > of the client LSP. > > THe point is that "A midpoint LSR does not participate in the > signaling of any clients of the client LSP" and that non-participation > in client (or higher layer) signaling applies to any "client of a > client LSP", not just other LSP running over it. > > I then searched for all occurances of the words upper and lower and > higher. There are no occurances of "upper". > > There were a few occurances of "lower latency" and "higher latency". > Other than that, all occurances of lower and higher except one are in > the follwoing text: > > 3.2. Component Links Provided by Lower Layer Networks > > A component link may be supported by a lower layer network. For > example, the lower layer may be a circuit switched network or another > MPLS network (e.g., MPLS-TP)). The lower layer network may change > the latency (and/or other performance parameters) seen by the client > layer. Currently, there is no protocol for the lower layer network > to inform the higher layer network of a change in a performance > parameter. Communication of the latency performance parameter is a > very important requirement. Communication of other performance > parameters (e.g., delay variation) is desirable. > > FR#8 The solution SHALL specify a protocol means to allow a lower > layer server network to communicate latency to the higher layer > client network. > > The exception is this sentence: > > FR#22 The solution SHOULD support the use case where an advanced > multipath itself is a component link for a higher order advanced > multipath. For example, an advanced multipath comprised of MPLS- > TP bi-directional tunnels viewed as logical links could then be > used as a component link in yet another advanced multipath that > connects MPLS routers. > > The terms lower layer and higher layer go all the way back to the ISO > seven layer model of ancient times (1970s?, 1980s?) and maybe further > back but that is before even my time. > > I don't think this is unclear but I could add the following in > definitions: > > Higher Layers > A client layer is the one immediately above a server layer. The > client layer and all layers above that layer are higher layers. > > Lower Layers > A server layer is the later immediately below a client laer. > The server layer and all layers below are lower layers. > > Do I really need to put this in the definitions section? If yoy think > it is necessary, I will add it. > Perhaps we've talked (okay written) past each other. I was suggesting using/keeping the "higher and lower layer" terminology, not dropping it. And to use it (consistently) in place of "client and server Layer". >> 3. Technical: The document should make it clear that LSPs can provide >> paths from an Advanced Multipath. I suggest adding something like the >> the following at the end of page 3 >> d. a lower layer LSP. > > Case "b." is intended to include LSP but is not specifically limited > to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > Ethernet Link Aggregation, and all sorts of things that don't involve > MPLS at all. For example, a path in Ethernet Link Aggregation Group > (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > this would be unknown to the LAG, or in the simplest case each path in > the set of LAG members could be supported by a plain Ethernet cable. > okay, how about: OLD b. may be specific paths across a network to a destination node, or NEW b. specific paths across a network to a destination node (e.g., via an LSP), or >> and at the end of the Component Link definition: >> A component link may be provided via an LSP. > > I think this is covered in "3.2. Component Links Provided by Lower > Layer Networks". > > 3.2. Component Links Provided by Lower Layer Networks > > A component link may be supported by a lower layer network. For > example, the lower layer may be a circuit switched network or another > MPLS network (e.g., MPLS-TP)). > > This sort of statement could be made earlier. For example in the > discussion following the definitions (on page 5) the document covers > one case (where a component link is not an LSP) but it is not until > later that the other case is mentioned. > > I could add a paragraph in the discussion following the definitions > that mentions that a component link can also be another LSP. > > OLD: > > A Component Link may be a point-to-point physical link (where a > "physical link" includes one or more link layer plus a physical > layer) or a logical link that preserves ordering in the steady state. > A component link may have transient out of order events, but such > events must not exceed the network's Performance Objectives. For > example, a component link may be comprised of any supportable > combination of link layers over a physical layer or over logical sub- > layers, including those providing physical layer emulation. > > NEW: > > A Component Link may be a point-to-point physical link (where a > "physical link" includes one or more link layer plus a physical > layer) or a logical link that preserves ordering in the steady state. > A component link may have transient out of order events, but such > events must not exceed the network's Performance Objectives. For > example, a component link may be comprised of any supportable > combination of link layers over a physical layer or over logical sub- > layers, including those providing physical layer emulation, or over > MPLS server layer LSP. > > These are identical except the phrase ", or over MPLS server layer > LSP" added to the end of the last sentence. Sure. > >> 4. Editorial: Unless I'm mistaken, the requirements in this document >> apply to the Advanced Multipath solution. In most cases the document >> states requirements in the form of "The solution", but in a few cases it >> just says "advanced multipath". I think these cases should be changed >> to apply to an "Advanced Multipath solution". I think this comment >> applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. > > That is not correct. For example: > > FR#1 An advanced multipath MAY be announced in conjunction with > detailed parameters about its component links, such as bandwidth > and latency. The advanced multipath SHALL behave as a single IGP > adjacency. > > In this requirement the "advanced multipath" is a specific collection > of component links that is announced by way of an MPLS Forwarding > Adjaccency (FA) in the IGP. The same is true for the other > requirements cited. In all of these cases an advanced multipath is a > specific collection of component links. Hereto, the distinction between "advanced multipath" and "Advanced Multipath" was lost on me. > There is a typo in MR#1. > > OLD > > MR#1 Management Plane MUST support polling of the status and > configuration of an advanced multipath and its individual > advanced multipath and support notification of status change. > > NEW > > MR#1 Management Plane MUST support polling of the status and > configuration of an advanced multipath and its individual > component links and support notification of status change. > > In the last line > s/advanced multipath/component links/ > >> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: >> In these cases it is unclear if the requirements apply to >> (a) a client's ability to indicate a desired service/LSP constraint or >> (b) a selected component link's attribute that will be used by a client >> LSP, >> (c) both, or >> (d) something completely different >> The requirements should be clear to which entity the requirement applies. > > This "indication" can be through signaling or the management plane and > both must be supported in later framework and protocol definitions and > we can argue then whether both must be supported or if one or the > other is a "should" in RFC 2119 speak. > > There was concern that the word "signal" would exclude providing the > same informantion through the management plane and therefore the word > "indicate" is used. > > Rather than spell this out many times we hoped this would be clear. I > could add clarifying text up front if you think this is necessary. For > example, I could add the following before FR#1. > > FR#0 In requirements that follow in this document the word > "indicate" is used where information may be provided by either > the combination of link state IGP advertisement and MPLS LSP > signaling or via management plane protocols. In later documents > providing framework and protocol definitions both signaling and > management plane mechanisms MUST be defined. > So is this the IGP/signaling that runs between a client an an AM "LER", between an AM "LSR" and its server network, or between AM LSRs? If I understand AM properly, there may be *up to* there separate instances. Am I missing something? > It would be trivial to make this FR#1 and renumber the rest. > I don't think the FR helped clarify the above question. > Should I add it and renumber? > >> 6. The last paragraph in section 3.3. strikes me as both odd and out of >> place. There are so many possible decisions that must be considered by >> network operators relative to disruption and optimization. Why mention >> just "power reduction"? Is there something special about the >> interactions of multipath and power reduction? What value / information >> does this paragraph add? > > The last paragraph in section 3.3 is: > > Allowing multipath to contain component links with different > characteristics can improve the overall load balance and can be > accomplished while still accommodating the more strict requirements > of a subset of client LSP. > > I'm not sure if this is the "odd and out of place" paragraph you refer > to. It summarizes the purpose of the requirements in this section. I > think you mean section 3.5 and not 3.3. > Correct. > The remainder of your paragraph above discusses power reducetion and > this is only mentioned in section 3.5 so I think you mean this > paragraph. > Right again. > As with any load balancing change, a change initiated for the purpose > of power reduction may be minimally disruptive. Typically the > disruption is limited to a change in delay characteristics and the > potential for a very brief period with traffic reordering. The > network operator when configuring a network for power reduction > should weigh the benefit of power reduction against the disadvantage > of a minimal disruption. > > The paragraphs following a set of requirements provide discussion > related to that set of requirements. I don't see this as out of > place. The prior two paragraphs discuss delay discontinuity. This > paragraph is a reminder that "As with any load balancing change, a > change initiated for the purpose of power reduction may be minimally > disruptive." I don't see this as out of place. > > For example, to compensate for a less than perfect load balance a > subset of LSPs may need to be moved and that subset can be chosen from > those which will be least affected (and there are plenty of > requirements that compell the fussy LSP to tell the network abour > their specifial needs). To power down a component link, *all* LSP on > that component link need to be moved, even the very fussy ones. > Therefore I think mentioning that disruption should be considered is > not out of place in the discussion following these requirements. We > like to keep the discussion brief so this level of detail was not > included. > I guess we see the importance of this topic differently. So will this be the first RFC that uses the term "power reduction"? >> 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? > > At the very least it means something similar to same administrative > domain. An AS can be subdivided within an organization. Do you have > a better way to define intra-domain and inter-domain without going > down the rat hole of defining the term "domain"? I'd use something like "multiple ASes or routing domains". If you really want to avoid domains you could say areas or levels. > No on in the WG had > an issue with this so far but I'm open for a suggestion for better > wording. You're forgetting my "real" name;-) >> Nits: >> >> - References should be provided in all cases when referring to >> "existing ... techniques" > > References are not allowed in the abstract. In section 3.3 is the sentence: > > Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > description of existing techniques and a set of references. > > Much of that document is dedicated to describing existing techniques > and it contains quite a few references. > > I can move this sentence. Where in the document would you like to see > it moved to? > (Lines numbers from URL below.) Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. >> Using line numbers from >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > > Using line number is a text editor counts the page headers. What tool > are you using? I didn't see anything on tools.ietf.org. > huh. enter the above URL in a browser and you should see the line numbers. > So I'll guess. Looks like add 10 lines per page. > >> Line 112 >> s/SHOULD/should > > s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > > Also remove stray comma. > I don't think use of 2119 language being applied to the reader is appropriate, but whatever... >> Line 118 >> s/MAY/may > > s/deployment MAY choose to/deployment may choose to/ > > OK. Could go either way but s/MAY chose to/MAY/ would work too. > No. The issue is that this document doesn't place conformance requirements on a service provider so RFC2119 language isn't appropriate here. >> Line 149, match intro: >> s/Advanced Multipath meets/Advanced Multipath is a formalization of >> multipath techniques that meet > > OK. > >> Lines 251-254, beginning with "The" through the end of the paragraph. >> This should be an FR. > > Looks like you mean this: > > The transient period between some service disrupting > event and the convergence of the routing and/or signaling protocols > MUST occur within a time frame specified by Performance Objective > values. > Right. > OK. I'll add this as FR#6++. > >> That's it, >> Lou > > There are a few suggestions for changes to the text based on your > comments and a few questions for you. Based on your response to this > email I will edit the document. > > Thanks for the thorough review. > Thanks for the responses and the resend! Lou > Curtis > > - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- > > > ------- End of Forwarded Message > > > > From curtis@ipv6.occnc.com Tue Jan 7 18:56:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DAA1AE29D; Tue, 7 Jan 2014 18:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNFgBNWN4llF; Tue, 7 Jan 2014 18:56:41 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 08DF41AE2A7; Tue, 7 Jan 2014 18:56:40 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s082uTjw038207; Tue, 7 Jan 2014 21:56:29 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401080256.s082uTjw038207@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Mon, 06 Jan 2014 18:11:53 -0500." <52CB3839.6020704@labn.net> Date: Tue, 07 Jan 2014 21:56:29 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" , curtis@ipv6.occnc.com Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 02:56:47 -0000 In message <52CB3839.6020704@labn.net> Lou Berger writes: > > Hi Curtis, > Thanks for the response. See below You pointed out a a few things you thought should be changed but left it open for me to propose how to change things, so we'll need at least one more iteration after this. > On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > > Lou et al, > > > > Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > > through to all recipients. There may have been a problem (due to a > > self inflicted DNS issue). > > > > I did not get a response so I suspect Lou didn't get this email. > > > > Curtis FYI - most recent issue I found was an error in IN TXT v=spf1 line. It might be a bad time to be experimenting with IPv6 transition technologies and their effects of email. :-( Go back to plain old dual stack and burn another IPv4 global? Might be the right move. Hopefully mail will get through to everyone now without a resend. If I have to resend I'll put the IPv6 mail server back into the DS subnet before resending. Curtis > > In message <52A8B5AB.4040708@labn.net> > > Lou Berger writes: > >> > >> 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. 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-rtgwg-cl-requirement-13.txt > >> Reviewer: Lou Berger > >> Review Date: 2013-12-11 > >> IETF LC End Date: 2013-12-09 > >> Intended Status: Informational > >> > >> Summary: > >> > >> I have some minor concerns about this document that I think > >> should be resolved before publication. > >> > >> Comments: > >> > >> I think the document is greatly improved since the previous last > >> call. I have some comments and reservations on the document that are > >> described below. As discussed on the list, I remain concerned about the > >> value of defining requirements in terms of nebulous "Performance > >> Objectives", but as this is acceptable to the WG I will not elaborate on > >> this concern further. > >> > >> Major Issues: > >> > >> No major issues found. > >> > >> Minor Issues: > >> > >> 1. Terminology & consistency: the document coins the term "Advanced > >> Multipath": > >> Advanced Multipath is a formalization of multipath techniques > >> > >> Do you see this term as a new noun, like LSP, or as an adjective? I > >> expected the latter, i.e. that it be used like "multipath" is used in > >> the above sentence, but it seems to be used as a new noun. I'm not sure > >> coining a new noun really makes sense, but if this the intent then the > >> last paragraph of section 2 needs to be revised as "Advanced Multipath" > >> will now have a specific definition as opposed to a generic term. Also I > >> suggest always capitalizing it (or even using the abbreviation "AM") > >> will clarify this distinction. > > > > I see multipath as a noun and therefore advanced multipath as a noun. > > Advanced is an adjective, multipath as a noun. Advanced Multipath is > > the set of techniques that form a solution. An advanced multipath is > > a collection of componet links. The former is capitalized, the latter > > is not. I'll check to see if I got that right in all occurances. If > > you would like I can also add this to the definition making it: > > > > OLD > > > > Advanced Multipath > > Advanced Multipath meets the requirements defined in this > > document. A key capability of advanced multipath is the support > > of non-homogeneous component links. > > > > NEW > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > Okay. Then I suggest using "AM" will help delineate this usage. Later you indicate you prefer we don't use the same term. Suggestion follows that. > > An "advanced multipath" is a > > collection of component links. In this document the former is > > capitalized and the latter is not. > > > > If we agree on this I'll just search for "advanced" and make > > capitalization consistent with the above statements. > > the distinction based on capitalization seems likely to introduce > confusion in this document and in future uses, so I think it is a really > bad idea. Clarity is good. If it lacks clarity we'll have to fix it. > > I don't think the phrase "advanced multipath technique" makes it an > > adjective any more than a statement such as make-before-break is an > > MPLS technique" makes MPLS an adjective in normal use. The phrase "an > > X technique" is simply a shorthand for indicating a "technique > > applicable to X". Even if that makes it an adjective the phrase "MPLS > > technique" is common and so that should not be a problem. The > > paragraph in question might be the following. It seems benign to me. > > > > The term Advanced Multipath is intended to be used within the context > > of this document and the related documents, > > [I-D.ietf-rtgwg-cl-use-cases] and [I-D.ietf-rtgwg-cl-framework] and > > any other related document. Other advanced multipath techniques may > > in the future arise. If the capabilities defined in this document > > become commonplace, they would no longer be considered "advanced". > > Use of the term "advanced multipath" outside this document, if > > referring to the term as defined here, should indicate Advanced > > Multipath as defined by this document, citing the current document > > name. If using another definition of "advanced multipath", documents > > may optionally clarify that they are not using the term "advanced > > multipath" as defined by this document if clarification is deemed > > helpful. > > > > I see no problem with this. Please be more specific if you think > > there are places where advanced multipath is used as an adjective or > > where its use is confusing. > > > > I believe my confusion was not understanding the differences between > "Advanced Multipath" (with words capitalized) and "advanced multipath" > (with words lower cased). While I understand this is your intent, I see > it as just leading to confusion. Ultimately, it's the author's / WG's > call, i.e., not mine, to make. OK so here is a suggestion to improve this. OLD Advanced Multipath Advanced Multipath meets the requirements defined in this document. A key capability of advanced multipath is the support of non-homogeneous component links. OLD NEW Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. NEWER Advanced Multipath Advanced Multipath is a formalization of multipath techniques that meets the requirements defined in this document. A key capability of Advanced Multipath is the support of non-homogeneous component links. Advanced Multipath Group (AMG) An Advanced Multipath Group (AMG) is group of component links where Advanced Multipath techniques are applied. This along the lines of "Link Aggregation" and LAG. The first is 802.1ax (or whatever, see the references). The latter is a group of component links. Not to be confused with Absorbed Glass Mat lead-acid batteries... (which is AGM not AMG). But if you see me write AGM, you'll know why (habit, typo). I think if we use these definitions and make if this terminology change is made everywhere in the document we will acheive the improved clarity that you were looking for. Is this OK? > >> 2. Editorial: server and client layer vs upper and lower layer. > >> > >> The document uses server and client layer networks and LSPs and, > >> sometimes interchangeably or redundantly, upper and lower layer networks > >> and LSPs. I think this issue can be resolved by avoiding the term > >> client/server when referring to network layers and just using the > >> lower/upper terminology. The one exception to this is in the definition > >> Client LSP which should simply be defined in the context of a multipath, > >> i.e.: > >> OLD > >> A client LSP is an LSP which has been set up over a server layer. > >> NEW > >> A client LSP is an LSP which has been set up over Advanced Multipath. > > > > A client LSP can be set up over a server layer MPLS-TP LSP or any > > server layer MPLS LSP or over a link layer or over a pseudowire ... or > > over an advanced multipath. > > > > Would you accept s/server layer/lower layer/g? The definition of server layer is not the same as the definition of lower layer. See below. > >> I think this also means that usage of the term "Client" is limited to > >> "Client LSP". > > > > I searched for all occurances of the word client. All occurances are > > "client LSP" excexpt the phrase "client of a client LSP" and that is > > used only in the following paragraph. > > > > The ingress and egress of a multipath may be midpoint LSRs with > > respect to a given client LSP. A midpoint LSR does not participate > > in the signaling of any clients of the client LSP. Therefore, in > > general, multipath endpoints cannot determine requirements of clients > > of a client LSP through participation in the signaling of the clients > > of the client LSP. > > > > THe point is that "A midpoint LSR does not participate in the > > signaling of any clients of the client LSP" and that non-participation > > in client (or higher layer) signaling applies to any "client of a > > client LSP", not just other LSP running over it. > > > > I then searched for all occurances of the words upper and lower and > > higher. There are no occurances of "upper". > > > > There were a few occurances of "lower latency" and "higher latency". > > Other than that, all occurances of lower and higher except one are in > > the follwoing text: > > > > 3.2. Component Links Provided by Lower Layer Networks > > > > A component link may be supported by a lower layer network. For > > example, the lower layer may be a circuit switched network or another > > MPLS network (e.g., MPLS-TP)). The lower layer network may change > > the latency (and/or other performance parameters) seen by the client > > layer. Currently, there is no protocol for the lower layer network > > to inform the higher layer network of a change in a performance > > parameter. Communication of the latency performance parameter is a > > very important requirement. Communication of other performance > > parameters (e.g., delay variation) is desirable. > > > > FR#8 The solution SHALL specify a protocol means to allow a lower > > layer server network to communicate latency to the higher layer > > client network. > > > > The exception is this sentence: > > > > FR#22 The solution SHOULD support the use case where an advanced > > multipath itself is a component link for a higher order advanced > > multipath. For example, an advanced multipath comprised of MPLS- > > TP bi-directional tunnels viewed as logical links could then be > > used as a component link in yet another advanced multipath that > > connects MPLS routers. > > > > The terms lower layer and higher layer go all the way back to the ISO > > seven layer model of ancient times (1970s?, 1980s?) and maybe further > > back but that is before even my time. > > > > I don't think this is unclear but I could add the following in > > definitions: > > > > Higher Layers > > A client layer is the one immediately above a server layer. The > > client layer and all layers above that layer are higher layers. > > > > Lower Layers > > A server layer is the later immediately below a client laer. > > The server layer and all layers below are lower layers. > > > > Do I really need to put this in the definitions section? If yoy think > > it is necessary, I will add it. > > > Perhaps we've talked (okay written) past each other. I was suggesting > using/keeping the "higher and lower layer" terminology, not dropping it. > And to use it (consistently) in place of "client and server Layer". I guess you missed the distinction in the definition above: For layer X layer Y is: client layer === Y = X+1 server layer === Y = X-1 higher layer === Y > X lower layer === Y < X So the definition client layer is not the same as the definition of higher layer. The definition of server layer is not the same as the definition of lower layer. In some discussions we really do mean "the server layer" and not any layer at any arbitrary depth below this one. > >> 3. Technical: The document should make it clear that LSPs can provide > >> paths from an Advanced Multipath. I suggest adding something like the > >> the following at the end of page 3 > >> d. a lower layer LSP. > > > > Case "b." is intended to include LSP but is not specifically limited > > to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > > Ethernet Link Aggregation, and all sorts of things that don't involve > > MPLS at all. For example, a path in Ethernet Link Aggregation Group > > (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > > this would be unknown to the LAG, or in the simplest case each path in > > the set of LAG members could be supported by a plain Ethernet cable. > > > > okay, how about: > OLD > b. may be specific paths across a network to a destination > node, or > NEW > b. specific paths across a network to a destination > node (e.g., via an LSP), or OK. But I like to spell out "for example" and put it after the definition. That would give us: 4. The paths may be: a. parallel links between two nodes, or b. may be specific paths across a network to a destination node, or c. may be links or paths to an intermediate node used to reach a common destination. The paths need not have equal capacity. The paths may or may not have equal cost in a routing protocol. + Paths across a network which serve as a component link in a AMG + may be provided by other LSP acting as server LSP for the + client AMG. Component links of a given AMG need not all use the + same type of server layer technology. For example, one may be a + physical Ethernet, another a Packet Over Sonet (POS) link, + another a pseudowire, and another an LSP with individual hops + using a mix of lower layer technologies. Is that an acceptable clarification? btw - in b. and c. s/may be// since "may be" precedes the list. > >> and at the end of the Component Link definition: > >> A component link may be provided via an LSP. > > > > I think this is covered in "3.2. Component Links Provided by Lower > > Layer Networks". > > > > 3.2. Component Links Provided by Lower Layer Networks > > > > A component link may be supported by a lower layer network. For > > example, the lower layer may be a circuit switched network or another > > MPLS network (e.g., MPLS-TP)). > > > > This sort of statement could be made earlier. For example in the > > discussion following the definitions (on page 5) the document covers > > one case (where a component link is not an LSP) but it is not until > > later that the other case is mentioned. > > > > I could add a paragraph in the discussion following the definitions > > that mentions that a component link can also be another LSP. > > > > OLD: > > > > A Component Link may be a point-to-point physical link (where a > > "physical link" includes one or more link layer plus a physical > > layer) or a logical link that preserves ordering in the steady state. > > A component link may have transient out of order events, but such > > events must not exceed the network's Performance Objectives. For > > example, a component link may be comprised of any supportable > > combination of link layers over a physical layer or over logical sub- > > layers, including those providing physical layer emulation. > > > > NEW: > > > > A Component Link may be a point-to-point physical link (where a > > "physical link" includes one or more link layer plus a physical > > layer) or a logical link that preserves ordering in the steady state. > > A component link may have transient out of order events, but such > > events must not exceed the network's Performance Objectives. For > > example, a component link may be comprised of any supportable > > combination of link layers over a physical layer or over logical sub- > > layers, including those providing physical layer emulation, or over > > MPLS server layer LSP. > > > > These are identical except the phrase ", or over MPLS server layer > > LSP" added to the end of the last sentence. > > Sure. > > > > >> 4. Editorial: Unless I'm mistaken, the requirements in this document > >> apply to the Advanced Multipath solution. In most cases the document > >> states requirements in the form of "The solution", but in a few cases it > >> just says "advanced multipath". I think these cases should be changed > >> to apply to an "Advanced Multipath solution". I think this comment > >> applies to FR1, FR7, FR18, FR23, GR3-5, and MR1-9. > > > > That is not correct. For example: > > > > FR#1 An advanced multipath MAY be announced in conjunction with > > detailed parameters about its component links, such as bandwidth > > and latency. The advanced multipath SHALL behave as a single IGP > > adjacency. > > > > In this requirement the "advanced multipath" is a specific collection > > of component links that is announced by way of an MPLS Forwarding > > Adjaccency (FA) in the IGP. The same is true for the other > > requirements cited. In all of these cases an advanced multipath is a > > specific collection of component links. > > Hereto, the distinction between "advanced multipath" and "Advanced > Multipath" was lost on me. OK. "Advanced Multipath" vs AMG might improve clarity. > > There is a typo in MR#1. > > > > OLD > > > > MR#1 Management Plane MUST support polling of the status and > > configuration of an advanced multipath and its individual > > advanced multipath and support notification of status change. > > > > NEW > > > > MR#1 Management Plane MUST support polling of the status and > > configuration of an advanced multipath and its individual > > component links and support notification of status change. > > > > In the last line > > s/advanced multipath/component links/ > > > >> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > >> In these cases it is unclear if the requirements apply to > >> (a) a client's ability to indicate a desired service/LSP constraint or > >> (b) a selected component link's attribute that will be used by a client > >> LSP, > >> (c) both, or > >> (d) something completely different > >> The requirements should be clear to which entity the requirement applies. > > > > This "indication" can be through signaling or the management plane and > > both must be supported in later framework and protocol definitions and > > we can argue then whether both must be supported or if one or the > > other is a "should" in RFC 2119 speak. > > > > There was concern that the word "signal" would exclude providing the > > same informantion through the management plane and therefore the word > > "indicate" is used. > > > > Rather than spell this out many times we hoped this would be clear. I > > could add clarifying text up front if you think this is necessary. For > > example, I could add the following before FR#1. > > > > FR#0 In requirements that follow in this document the word > > "indicate" is used where information may be provided by either > > the combination of link state IGP advertisement and MPLS LSP > > signaling or via management plane protocols. In later documents > > providing framework and protocol definitions both signaling and > > management plane mechanisms MUST be defined. > > > > So is this the IGP/signaling that runs between a client an an AM "LER", > between an AM "LSR" and its server network, or between AM LSRs? If I > understand AM properly, there may be *up to* there separate instances. > Am I missing something? Please don't abbreviate Advanced Multipath as AM. Link Aggregation is not LA. The word "indicate" is independent of the method of getting the information there. But yes in the example given the IGP advertisement and MPLS LSP signaling that might be one such mechanism does refer to the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there is only one IGP flooding information for both client and server layer, hence the seemingly endless (and mostly pointless) discussion of sub-layer vs layer from certain ITU people in the MPLS WG mailing list who viewed MPLS as broken for not enforcing a strict layering in this regard. But we need not go into that level of detail in this example of how independent of mechanism the "indicate" is and down that years old MPLS WG terminology rat hole again. > > It would be trivial to make this FR#1 and renumber the rest. > > > > I don't think the FR helped clarify the above question. The choice of the word "indicate" in FR10-13, FR14, FR15 does not imply usage by a specific layer. That is a direct answer to your question. In all of these specific cases, the the client layer is passing a requirement to the server layer so in the IGP + RSVP-TE world that would be a function of RSVP-TE. In the absense of control plane, it would have to be done through management plane interaction where the client indicates requirements of an LSP and the server layer is free to figure out how to meet those requirements. Do you want me to add the clarification on the use of the word "indicate" or not? > > Should I add it and renumber? > > > >> 6. The last paragraph in section 3.3. strikes me as both odd and out of > >> place. There are so many possible decisions that must be considered by > >> network operators relative to disruption and optimization. Why mention > >> just "power reduction"? Is there something special about the > >> interactions of multipath and power reduction? What value / information > >> does this paragraph add? > > > > The last paragraph in section 3.3 is: > > > > Allowing multipath to contain component links with different > > characteristics can improve the overall load balance and can be > > accomplished while still accommodating the more strict requirements > > of a subset of client LSP. > > > > I'm not sure if this is the "odd and out of place" paragraph you refer > > to. It summarizes the purpose of the requirements in this section. I > > think you mean section 3.5 and not 3.3. > > > > Correct. > > > The remainder of your paragraph above discusses power reducetion and > > this is only mentioned in section 3.5 so I think you mean this > > paragraph. > > > Right again. > > > As with any load balancing change, a change initiated for the purpose > > of power reduction may be minimally disruptive. Typically the > > disruption is limited to a change in delay characteristics and the > > potential for a very brief period with traffic reordering. The > > network operator when configuring a network for power reduction > > should weigh the benefit of power reduction against the disadvantage > > of a minimal disruption. > > > > The paragraphs following a set of requirements provide discussion > > related to that set of requirements. I don't see this as out of > > place. The prior two paragraphs discuss delay discontinuity. This > > paragraph is a reminder that "As with any load balancing change, a > > change initiated for the purpose of power reduction may be minimally > > disruptive." I don't see this as out of place. > > > > For example, to compensate for a less than perfect load balance a > > subset of LSPs may need to be moved and that subset can be chosen from > > those which will be least affected (and there are plenty of > > requirements that compell the fussy LSP to tell the network abour > > their specifial needs). To power down a component link, *all* LSP on > > that component link need to be moved, even the very fussy ones. > > Therefore I think mentioning that disruption should be considered is > > not out of place in the discussion following these requirements. We > > like to keep the discussion brief so this level of detail was not > > included. > > > > I guess we see the importance of this topic differently. So will this > be the first RFC that uses the term "power reduction"? Perhaps. A co-author originally wanted it added. The set of authors kicked this around and reworded the original. The wording is brief and vague and the use of MAY in the actual requirement means we will not disallow this. So far no one in the WG has objected to this wording and its been there a long time. Would you like me to remove the requirement and discussion of its implications after the WG concensus so far was to keep it? > >> 7. Terminology: In GR4&5: what is a "MPLS network topology"? Do you mean AS? > > > > At the very least it means something similar to same administrative > > domain. An AS can be subdivided within an organization. Do you have > > a better way to define intra-domain and inter-domain without going > > down the rat hole of defining the term "domain"? > > I'd use something like "multiple ASes or routing domains". If you > really want to avoid domains you could say areas or levels. OK. s/MPLS network topology/routing domain/ > > No on in the WG had > > an issue with this so far but I'm open for a suggestion for better > > wording. > > You're forgetting my "real" name;-) You plan on living up to it I see. :-) > >> Nits: > >> > >> - References should be provided in all cases when referring to > >> "existing ... techniques" > > > > References are not allowed in the abstract. In section 3.3 is the sentence: > > > > Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > > description of existing techniques and a set of references. > > > > Much of that document is dedicated to describing existing techniques > > and it contains quite a few references. > > > > I can move this sentence. Where in the document would you like to see > > it moved to? > > > (Lines numbers from URL below.) > Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. > > >> Using line numbers from > >> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > > > > Using line number is a text editor counts the page headers. What tool > > are you using? I didn't see anything on tools.ietf.org. > > > huh. enter the above URL in a browser and you should see the line numbers. > > > So I'll guess. Looks like add 10 lines per page. > > > > >> Line 112 > >> s/SHOULD/should > > > > s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > > > > Also remove stray comma. > > > I don't think use of 2119 language being applied to the reader is > appropriate, but whatever... You want me to downcase "SHOULD be interpreted". I missed a M-l in the s/// edit (emacs downcase next word) and got only the stray comma. > >> Line 118 > >> s/MAY/may > > > > s/deployment MAY choose to/deployment may choose to/ > > > > OK. Could go either way but s/MAY chose to/MAY/ would work too. > > > No. The issue is that this document doesn't place conformance > requirements on a service provider so RFC2119 language isn't appropriate > here. No IETF document truly places conformance requirements on either the service provider or implementor, but we put RFC2119 language in telling them what to do all the time. No one in IETF signed a legal document forcing them to adhere to every RFC2119 keyword in each document. The requirements here are 1) implementor SHOULD provide a per feature knob to turn individual features off, 2) provider MAY use those knobs, including knobs that another implementor made available. This is just trying to avoid unnecessarily inflexible specifications or unnecessarily inflexible implementations where some feature doesn't work when an unrelated feature is disabled. This is in here because this inflexibility happens. The framework can outline any feature dependencies. > >> Line 149, match intro: > >> s/Advanced Multipath meets/Advanced Multipath is a formalization of > >> multipath techniques that meet > > > > OK. > > > >> Lines 251-254, beginning with "The" through the end of the paragraph. > >> This should be an FR. > > > > Looks like you mean this: > > > > The transient period between some service disrupting > > event and the convergence of the routing and/or signaling protocols > > MUST occur within a time frame specified by Performance Objective > > values. > > > Right. > > OK. I'll add this as FR#6++. > > > > >> That's it, > >> Lou > > > > There are a few suggestions for changes to the text based on your > > comments and a few questions for you. Based on your response to this > > email I will edit the document. > > > > Thanks for the thorough review. > > > > Thanks for the responses and the resend! > > Lou Sorry to mess up my own DNS and require a resend and a delay. Curtis > > Curtis > > > > - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- > > > > > > ------- End of Forwarded Message From lberger@labn.net Wed Jan 8 10:48:08 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616691AE0EC for ; Wed, 8 Jan 2014 10:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yc1zFXeXj2h6 for ; Wed, 8 Jan 2014 10:48:04 -0800 (PST) Received: from alt-proxy17.mail.unifiedlayer.com (alt-proxy17.mail.unifiedlayer.com [66.147.241.60]) by ietfa.amsl.com (Postfix) with SMTP id 62EEB1AE0E1 for ; Wed, 8 Jan 2014 10:48:04 -0800 (PST) Received: (qmail 9686 invoked by uid 0); 8 Jan 2014 18:47:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 8 Jan 2014 18:47:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4+UnfA4r4QdiT90TYGFBhpReFG2e7UezK27fBTA3lUM=; b=tA68qU/AfMKJj82KpB2WNIBP9fJ0BqzHKd/cO0QKEzC0HvWvvNpD/mchzh3q+32x5l5UKfToJn6lgd+LgzMeaICOUIYFzq2/7aoKQN4j1m6mMycXFmZxP6tRTmiGIf5u; Received: from box313.bluehost.com ([69.89.31.113]:52439 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W0yAV-0004nS-1I; Wed, 08 Jan 2014 11:47:55 -0700 Message-ID: <52CD9D58.4010109@labn.net> Date: Wed, 08 Jan 2014 13:47:52 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401080256.s082uTjw038207@maildrop2.v6ds.occnc.com> In-Reply-To: <201401080256.s082uTjw038207@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2014 18:48:08 -0000 Hi Curtis, See below. On 01/07/2014 09:56 PM, Curtis Villamizar wrote: > In message <52CB3839.6020704@labn.net> > Lou Berger writes: >> >> Hi Curtis, >> Thanks for the response. See below > > You pointed out a a few things you thought should be changed but left > it open for me to propose how to change things, so we'll need at least > one more iteration after this. > Right, you're the author.... >> On 1/6/2014 12:00 PM, Curtis Villamizar wrote: >>> Lou et al, >>> >>> Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went >>> through to all recipients. There may have been a problem (due to a >>> self inflicted DNS issue). >>> >>> I did not get a response so I suspect Lou didn't get this email. >>> >>> Curtis > > FYI - most recent issue I found was an error in IN TXT v=spf1 line. > It might be a bad time to be experimenting with IPv6 transition > technologies and their effects of email. :-( Go back to plain old > dual stack and burn another IPv4 global? Might be the right move. > > Hopefully mail will get through to everyone now without a resend. If > I have to resend I'll put the IPv6 mail server back into the DS > subnet before resending. > > Curtis > no problem at all on this one, so I think you're up and working! > >>> In message <52A8B5AB.4040708@labn.net> >>> Lou Berger writes: >>>> ... >> I believe my confusion was not understanding the differences between >> "Advanced Multipath" (with words capitalized) and "advanced multipath" >> (with words lower cased). While I understand this is your intent, I see >> it as just leading to confusion. Ultimately, it's the author's / WG's >> call, i.e., not mine, to make. > > OK so here is a suggestion to improve this. > > OLD > > Advanced Multipath > Advanced Multipath meets the requirements defined in this > document. A key capability of advanced multipath is the support > of non-homogeneous component links. > > OLD NEW > > Advanced Multipath > Advanced Multipath is a formalization of multipath techniques > that meets the requirements defined in this document. A key > capability of Advanced Multipath is the support of > non-homogeneous component links. > > NEWER > > Advanced Multipath > Advanced Multipath is a formalization of multipath techniques > that meets the requirements defined in this document. A key > capability of Advanced Multipath is the support of > non-homogeneous component links. > > Advanced Multipath Group (AMG) > > An Advanced Multipath Group (AMG) is group of component links > where Advanced Multipath techniques are applied. > Ahh. I think this is much better/clearer! > This along the lines of "Link Aggregation" and LAG. The first is > 802.1ax (or whatever, see the references). The latter is a group of > component links. > > Not to be confused with Absorbed Glass Mat lead-acid batteries... > (which is AGM not AMG). But if you see me write AGM, you'll know why > (habit, typo). > > I think if we use these definitions and make if this terminology > change is made everywhere in the document we will acheive the improved > clarity that you were looking for. > > Is this OK? Yes! > >>>> 2. Editorial: server and client layer vs upper and lower layer. >>>> >>>> The document uses server and client layer networks and LSPs and, >>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>> and LSPs. I think this issue can be resolved by avoiding the term >>>> client/server when referring to network layers and just using the >>>> lower/upper terminology. The one exception to this is in the definition >>>> Client LSP which should simply be defined in the context of a multipath, >>>> i.e.: >>>> OLD >>>> A client LSP is an LSP which has been set up over a server layer. >>>> NEW >>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>> >>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>> over an advanced multipath. >>> >> >> Would you accept s/server layer/lower layer/g? > > The definition of server layer is not the same as the definition of > lower layer. See below. > >>>> I think this also means that usage of the term "Client" is limited to >>>> "Client LSP". >>> >>> I searched for all occurances of the word client. All occurances are >>> "client LSP" excexpt the phrase "client of a client LSP" and that is >>> used only in the following paragraph. >>> >>> The ingress and egress of a multipath may be midpoint LSRs with >>> respect to a given client LSP. A midpoint LSR does not participate >>> in the signaling of any clients of the client LSP. Therefore, in >>> general, multipath endpoints cannot determine requirements of clients >>> of a client LSP through participation in the signaling of the clients >>> of the client LSP. >>> >>> THe point is that "A midpoint LSR does not participate in the >>> signaling of any clients of the client LSP" and that non-participation >>> in client (or higher layer) signaling applies to any "client of a >>> client LSP", not just other LSP running over it. >>> >>> I then searched for all occurances of the words upper and lower and >>> higher. There are no occurances of "upper". >>> >>> There were a few occurances of "lower latency" and "higher latency". >>> Other than that, all occurances of lower and higher except one are in >>> the follwoing text: >>> >>> 3.2. Component Links Provided by Lower Layer Networks >>> >>> A component link may be supported by a lower layer network. For >>> example, the lower layer may be a circuit switched network or another >>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>> the latency (and/or other performance parameters) seen by the client >>> layer. Currently, there is no protocol for the lower layer network >>> to inform the higher layer network of a change in a performance >>> parameter. Communication of the latency performance parameter is a >>> very important requirement. Communication of other performance >>> parameters (e.g., delay variation) is desirable. >>> >>> FR#8 The solution SHALL specify a protocol means to allow a lower >>> layer server network to communicate latency to the higher layer >>> client network. >>> >>> The exception is this sentence: >>> >>> FR#22 The solution SHOULD support the use case where an advanced >>> multipath itself is a component link for a higher order advanced >>> multipath. For example, an advanced multipath comprised of MPLS- >>> TP bi-directional tunnels viewed as logical links could then be >>> used as a component link in yet another advanced multipath that >>> connects MPLS routers. >>> >>> The terms lower layer and higher layer go all the way back to the ISO >>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>> back but that is before even my time. >>> >>> I don't think this is unclear but I could add the following in >>> definitions: >>> >>> Higher Layers >>> A client layer is the one immediately above a server layer. The >>> client layer and all layers above that layer are higher layers. >>> >>> Lower Layers >>> A server layer is the later immediately below a client laer. >>> The server layer and all layers below are lower layers. >>> >>> Do I really need to put this in the definitions section? If yoy think >>> it is necessary, I will add it. >>> >> Perhaps we've talked (okay written) past each other. I was suggesting >> using/keeping the "higher and lower layer" terminology, not dropping it. >> And to use it (consistently) in place of "client and server Layer". > > I guess you missed the distinction in the definition above: > > For layer X layer Y is: > > client layer === Y = X+1 > server layer === Y = X-1 > higher layer === Y > X > lower layer === Y < X > > So the definition client layer is not the same as the definition of > higher layer. The definition of server layer is not the same as the > definition of lower layer. > > In some discussions we really do mean "the server layer" and not any > layer at any arbitrary depth below this one. > I read your usage of client/server layer to be synonymous with higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense of FR#8 (I think you really mean client layer not lower layer.) Given the current document usage, I still think it makes sense to eliminate the two instances of "client layer": How about the following: OLD Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. NEW Client LSP A client LSP is a LSP which has been set up over Advanced Multipath as opposed to an LSP representing the Advanced Multipath itself or any LSP that is part of an Advanced Multipath Group. and OLD The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by sets of paths across a network provided by server layer LSP. NEW The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by LSPs that are part of an Advanced Multipath Group. >>>> 3. Technical: The document should make it clear that LSPs can provide >>>> paths from an Advanced Multipath. I suggest adding something like the >>>> the following at the end of page 3 >>>> d. a lower layer LSP. >>> >>> Case "b." is intended to include LSP but is not specifically limited >>> to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, >>> Ethernet Link Aggregation, and all sorts of things that don't involve >>> MPLS at all. For example, a path in Ethernet Link Aggregation Group >>> (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though >>> this would be unknown to the LAG, or in the simplest case each path in >>> the set of LAG members could be supported by a plain Ethernet cable. >>> >> >> okay, how about: >> OLD >> b. may be specific paths across a network to a destination >> node, or >> NEW >> b. specific paths across a network to a destination >> node (e.g., via an LSP), or > > OK. But I like to spell out "for example" and put it after the > definition. That would give us: > > 4. The paths may be: > > a. parallel links between two nodes, or > > b. may be specific paths across a network to a destination > node, or > > c. may be links or paths to an intermediate node used to > reach a common destination. > > The paths need not have equal capacity. The paths may or may not > have equal cost in a routing protocol. > + Paths across a network which serve as a component link in a AMG > + may be provided by other LSP acting as server LSP for the > + client AMG. Component links of a given AMG need not all use the > + same type of server layer technology. For example, one may be a > + physical Ethernet, another a Packet Over Sonet (POS) link, > + another a pseudowire, and another an LSP with individual hops > + using a mix of lower layer technologies. > > Is that an acceptable clarification? Given the the definition of AMG I no longer see a need for the change or proposed text (and would prefer not having to discuss the proposed text.) ... >>>> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: >>>> In these cases it is unclear if the requirements apply to >>>> (a) a client's ability to indicate a desired service/LSP constraint or >>>> (b) a selected component link's attribute that will be used by a client >>>> LSP, >>>> (c) both, or >>>> (d) something completely different >>>> The requirements should be clear to which entity the requirement applies. >>> >>> This "indication" can be through signaling or the management plane and >>> both must be supported in later framework and protocol definitions and >>> we can argue then whether both must be supported or if one or the >>> other is a "should" in RFC 2119 speak. >>> >>> There was concern that the word "signal" would exclude providing the >>> same informantion through the management plane and therefore the word >>> "indicate" is used. >>> >>> Rather than spell this out many times we hoped this would be clear. I >>> could add clarifying text up front if you think this is necessary. For >>> example, I could add the following before FR#1. >>> >>> FR#0 In requirements that follow in this document the word >>> "indicate" is used where information may be provided by either >>> the combination of link state IGP advertisement and MPLS LSP >>> signaling or via management plane protocols. In later documents >>> providing framework and protocol definitions both signaling and >>> management plane mechanisms MUST be defined. >>> >> >> So is this the IGP/signaling that runs between a client an an AM "LER", >> between an AM "LSR" and its server network, or between AM LSRs? If I >> understand AM properly, there may be *up to* there separate instances. >> Am I missing something? > > Please don't abbreviate Advanced Multipath as AM. Link Aggregation is > not LA. Perhaps you should a requirement on this ;-) > > The word "indicate" is independent of the method of getting the > information there. But yes in the example given the IGP advertisement > and MPLS LSP signaling that might be one such mechanism does refer to > the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > > If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > is only one IGP flooding information for both client and server layer, > hence the seemingly endless (and mostly pointless) discussion of > sub-layer vs layer from certain ITU people in the MPLS WG mailing list > who viewed MPLS as broken for not enforcing a strict layering in this > regard. But we need not go into that level of detail in this example > of how independent of mechanism the "indicate" is and down that years > old MPLS WG terminology rat hole again. > My comment is that you need to be clear to which layer a requirement applies. Is it the server layer, the client layer or the Advanced Multipath layer? >>> It would be trivial to make this FR#1 and renumber the rest. >>> >> >> I don't think the FR helped clarify the above question. > > The choice of the word "indicate" in FR10-13, FR14, FR15 does not > imply usage by a specific layer. That is a direct answer to your > question. > > In all of these specific cases, the the client layer is passing a > requirement to the server layer so in the IGP + RSVP-TE world that > would be a function of RSVP-TE. In the absense of control plane, it > would have to be done through management plane interaction where the > client indicates requirements of an LSP and the server layer is free > to figure out how to meet those requirements. > > Do you want me to add the clarification on the use of the word > "indicate" or not? I think you need to be clear that the requirement applies to all three layers. > >>> Should I add it and renumber? >>> >>>> 6. The last paragraph in section 3.3. strikes me as both odd and out of >>>> place. There are so many possible decisions that must be considered by >>>> network operators relative to disruption and optimization. Why mention >>>> just "power reduction"? Is there something special about the >>>> interactions of multipath and power reduction? What value / information >>>> does this paragraph add? >>> >>> The last paragraph in section 3.3 is: >>> >>> Allowing multipath to contain component links with different >>> characteristics can improve the overall load balance and can be >>> accomplished while still accommodating the more strict requirements >>> of a subset of client LSP. >>> >>> I'm not sure if this is the "odd and out of place" paragraph you refer >>> to. It summarizes the purpose of the requirements in this section. I >>> think you mean section 3.5 and not 3.3. >>> >> >> Correct. >> >>> The remainder of your paragraph above discusses power reducetion and >>> this is only mentioned in section 3.5 so I think you mean this >>> paragraph. >>> >> Right again. >> >>> As with any load balancing change, a change initiated for the purpose >>> of power reduction may be minimally disruptive. Typically the >>> disruption is limited to a change in delay characteristics and the >>> potential for a very brief period with traffic reordering. The >>> network operator when configuring a network for power reduction >>> should weigh the benefit of power reduction against the disadvantage >>> of a minimal disruption. >>> >>> The paragraphs following a set of requirements provide discussion >>> related to that set of requirements. I don't see this as out of >>> place. The prior two paragraphs discuss delay discontinuity. This >>> paragraph is a reminder that "As with any load balancing change, a >>> change initiated for the purpose of power reduction may be minimally >>> disruptive." I don't see this as out of place. >>> >>> For example, to compensate for a less than perfect load balance a >>> subset of LSPs may need to be moved and that subset can be chosen from >>> those which will be least affected (and there are plenty of >>> requirements that compell the fussy LSP to tell the network abour >>> their specifial needs). To power down a component link, *all* LSP on >>> that component link need to be moved, even the very fussy ones. >>> Therefore I think mentioning that disruption should be considered is >>> not out of place in the discussion following these requirements. We >>> like to keep the discussion brief so this level of detail was not >>> included. >>> >> >> I guess we see the importance of this topic differently. So will this >> be the first RFC that uses the term "power reduction"? > > Perhaps. A co-author originally wanted it added. The set of authors > kicked this around and reworded the original. The wording is brief > and vague and the use of MAY in the actual requirement means we will > not disallow this. So far no one in the WG has objected to this > wording and its been there a long time. > > Would you like me to remove the requirement and discussion of its > implications after the WG concensus so far was to keep it? > I think the text opens the door to the objection/question as to why just this "application" and not others are called out. Now that I've asked the question, we can move on. The AD can always revisit if he so chooses. ... >>>> Nits: >>>> >>>> - References should be provided in all cases when referring to >>>> "existing ... techniques" >>> >>> References are not allowed in the abstract. In section 3.3 is the sentence: >>> >>> Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a >>> description of existing techniques and a set of references. >>> >>> Much of that document is dedicated to describing existing techniques >>> and it contains quite a few references. >>> >>> I can move this sentence. Where in the document would you like to see >>> it moved to? >>> >> (Lines numbers from URL below.) >> Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. >> >>>> Using line numbers from >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt >>> >>> Using line number is a text editor counts the page headers. What tool >>> are you using? I didn't see anything on tools.ietf.org. >>> >> huh. enter the above URL in a browser and you should see the line numbers. >> >>> So I'll guess. Looks like add 10 lines per page. >>> >> >>>> Line 112 >>>> s/SHOULD/should >>> >>> s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ >>> >>> Also remove stray comma. >>> >> I don't think use of 2119 language being applied to the reader is >> appropriate, but whatever... > > You want me to downcase "SHOULD be interpreted". I missed a M-l in > the s/// edit (emacs downcase next word) and got only the stray comma. > Right. >>>> Line 118 >>>> s/MAY/may >>> >>> s/deployment MAY choose to/deployment may choose to/ >>> >>> OK. Could go either way but s/MAY chose to/MAY/ would work too. >>> >> No. The issue is that this document doesn't place conformance >> requirements on a service provider so RFC2119 language isn't appropriate >> here. > > No IETF document truly places conformance requirements on either the > service provider or implementor, but we put RFC2119 language in > telling them what to do all the time. No one in IETF signed a legal > document forcing them to adhere to every RFC2119 keyword in each > document. > > The requirements here are 1) implementor SHOULD provide a per feature > knob to turn individual features off, 2) provider MAY use those knobs, > including knobs that another implementor made available. I'd prefer the first to be a MUST, but you've documented wg consensus. I don't think #2 makes any sense, but we can move on. > > This is just trying to avoid unnecessarily inflexible specifications > or unnecessarily inflexible implementations where some feature doesn't > work when an unrelated feature is disabled. This is in here because > this inflexibility happens. > > The framework can outline any feature dependencies. > >>>> Line 149, match intro: >>>> s/Advanced Multipath meets/Advanced Multipath is a formalization of >>>> multipath techniques that meet >>> >>> OK. >>> >>>> Lines 251-254, beginning with "The" through the end of the paragraph. >>>> This should be an FR. >>> >>> Looks like you mean this: >>> >>> The transient period between some service disrupting >>> event and the convergence of the routing and/or signaling protocols >>> MUST occur within a time frame specified by Performance Objective >>> values. >>> >> Right. >>> OK. I'll add this as FR#6++. >>> >> >>>> That's it, >>>> Lou >>> >>> There are a few suggestions for changes to the text based on your >>> comments and a few questions for you. Based on your response to this >>> email I will edit the document. >>> >>> Thanks for the thorough review. >>> >> >> Thanks for the responses and the resend! >> >> Lou > > Sorry to mess up my own DNS and require a resend and a delay. > NP! Lou > Curtis > >>> Curtis >>> >>> - --rBI3apOu079413.1387337811/maildrop2.v6ds.occnc.com-- >>> >>> >>> ------- End of Forwarded Message > From curtis@ipv6.occnc.com Wed Jan 8 20:34:10 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB001ADF9F; Wed, 8 Jan 2014 20:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptAZQZpdJpWr; Wed, 8 Jan 2014 20:34:06 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id AA47E1ACCF5; Wed, 8 Jan 2014 20:34:05 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s094XtlK060524; Wed, 8 Jan 2014 23:33:55 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401090433.s094XtlK060524@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Wed, 08 Jan 2014 13:47:52 -0500." <52CD9D58.4010109@labn.net> Date: Wed, 08 Jan 2014 23:33:55 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" , curtis@ipv6.occnc.com Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2014 04:34:10 -0000 Converging. But maybe one more round trip needed. In message <52CD9D58.4010109@labn.net> Lou Berger writes: > > Hi Curtis, > > See below. > > On 01/07/2014 09:56 PM, Curtis Villamizar wrote: > > In message <52CB3839.6020704@labn.net> > > Lou Berger writes: > >> > >> Hi Curtis, > >> Thanks for the response. See below > > > > You pointed out a a few things you thought should be changed but left > > it open for me to propose how to change things, so we'll need at least > > one more iteration after this. > > > Right, you're the author.... > > >> On 1/6/2014 12:00 PM, Curtis Villamizar wrote: > >>> Lou et al, > >>> > >>> Resending. I'm not sure if the original (sent Tue, 17 Dec 2013) went > >>> through to all recipients. There may have been a problem (due to a > >>> self inflicted DNS issue). > >>> > >>> I did not get a response so I suspect Lou didn't get this email. > >>> > >>> Curtis > > > > FYI - most recent issue I found was an error in IN TXT v=spf1 line. > > It might be a bad time to be experimenting with IPv6 transition > > technologies and their effects of email. :-( Go back to plain old > > dual stack and burn another IPv4 global? Might be the right move. > > > > Hopefully mail will get through to everyone now without a resend. If > > I have to resend I'll put the IPv6 mail server back into the DS > > subnet before resending. > > > > Curtis > > > no problem at all on this one, so I think you're up and working! > > > > > >>> In message <52A8B5AB.4040708@labn.net> > >>> Lou Berger writes: > >>>> > ... > > >> I believe my confusion was not understanding the differences between > >> "Advanced Multipath" (with words capitalized) and "advanced multipath" > >> (with words lower cased). While I understand this is your intent, I see > >> it as just leading to confusion. Ultimately, it's the author's / WG's > >> call, i.e., not mine, to make. > > > > OK so here is a suggestion to improve this. > > > > OLD > > > > Advanced Multipath > > Advanced Multipath meets the requirements defined in this > > document. A key capability of advanced multipath is the support > > of non-homogeneous component links. > > > > OLD NEW > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > > > NEWER > > > > Advanced Multipath > > Advanced Multipath is a formalization of multipath techniques > > that meets the requirements defined in this document. A key > > capability of Advanced Multipath is the support of > > non-homogeneous component links. > > > > Advanced Multipath Group (AMG) > > > > An Advanced Multipath Group (AMG) is group of component links > > where Advanced Multipath techniques are applied. > > > > Ahh. I think this is much better/clearer! OK. This is easy enough since it is just a terminology change. > > This along the lines of "Link Aggregation" and LAG. The first is > > 802.1ax (or whatever, see the references). The latter is a group of > > component links. > > > > Not to be confused with Absorbed Glass Mat lead-acid batteries... > > (which is AGM not AMG). But if you see me write AGM, you'll know why > > (habit, typo). > > > > I think if we use these definitions and make if this terminology > > change is made everywhere in the document we will acheive the improved > > clarity that you were looking for. > > > > Is this OK? > > Yes! Only 42 occurances in the XML file to look at. Certainly doable. > >>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>> > >>>> The document uses server and client layer networks and LSPs and, > >>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>> client/server when referring to network layers and just using the > >>>> lower/upper terminology. The one exception to this is in the definition > >>>> Client LSP which should simply be defined in the context of a multipath, > >>>> i.e.: > >>>> OLD > >>>> A client LSP is an LSP which has been set up over a server layer. > >>>> NEW > >>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>> > >>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>> over an advanced multipath. > >>> > >> > >> Would you accept s/server layer/lower layer/g? > > > > The definition of server layer is not the same as the definition of > > lower layer. See below. > > > >>>> I think this also means that usage of the term "Client" is limited to > >>>> "Client LSP". > >>> > >>> I searched for all occurances of the word client. All occurances are > >>> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>> used only in the following paragraph. > >>> > >>> The ingress and egress of a multipath may be midpoint LSRs with > >>> respect to a given client LSP. A midpoint LSR does not participate > >>> in the signaling of any clients of the client LSP. Therefore, in > >>> general, multipath endpoints cannot determine requirements of clients > >>> of a client LSP through participation in the signaling of the clients > >>> of the client LSP. > >>> > >>> THe point is that "A midpoint LSR does not participate in the > >>> signaling of any clients of the client LSP" and that non-participation > >>> in client (or higher layer) signaling applies to any "client of a > >>> client LSP", not just other LSP running over it. > >>> > >>> I then searched for all occurances of the words upper and lower and > >>> higher. There are no occurances of "upper". > >>> > >>> There were a few occurances of "lower latency" and "higher latency". > >>> Other than that, all occurances of lower and higher except one are in > >>> the follwoing text: > >>> > >>> 3.2. Component Links Provided by Lower Layer Networks > >>> > >>> A component link may be supported by a lower layer network. For > >>> example, the lower layer may be a circuit switched network or another > >>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>> the latency (and/or other performance parameters) seen by the client > >>> layer. Currently, there is no protocol for the lower layer network > >>> to inform the higher layer network of a change in a performance > >>> parameter. Communication of the latency performance parameter is a > >>> very important requirement. Communication of other performance > >>> parameters (e.g., delay variation) is desirable. > >>> > >>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>> layer server network to communicate latency to the higher layer > >>> client network. > >>> > >>> The exception is this sentence: > >>> > >>> FR#22 The solution SHOULD support the use case where an advanced > >>> multipath itself is a component link for a higher order advanced > >>> multipath. For example, an advanced multipath comprised of MPLS- > >>> TP bi-directional tunnels viewed as logical links could then be > >>> used as a component link in yet another advanced multipath that > >>> connects MPLS routers. > >>> > >>> The terms lower layer and higher layer go all the way back to the ISO > >>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>> back but that is before even my time. > >>> > >>> I don't think this is unclear but I could add the following in > >>> definitions: > >>> > >>> Higher Layers > >>> A client layer is the one immediately above a server layer. The > >>> client layer and all layers above that layer are higher layers. > >>> > >>> Lower Layers > >>> A server layer is the later immediately below a client laer. > >>> The server layer and all layers below are lower layers. > >>> > >>> Do I really need to put this in the definitions section? If yoy think > >>> it is necessary, I will add it. > >>> > >> Perhaps we've talked (okay written) past each other. I was suggesting > >> using/keeping the "higher and lower layer" terminology, not dropping it. > >> And to use it (consistently) in place of "client and server Layer". > > > > I guess you missed the distinction in the definition above: > > > > For layer X layer Y is: > > > > client layer === Y = X+1 > > server layer === Y = X-1 > > higher layer === Y > X > > lower layer === Y < X > > > > So the definition client layer is not the same as the definition of > > higher layer. The definition of server layer is not the same as the > > definition of lower layer. > > > > In some discussions we really do mean "the server layer" and not any > > layer at any arbitrary depth below this one. > > I read your usage of client/server layer to be synonymous with > higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > of FR#8 (I think you really mean client layer not lower layer.) FR#8 and FR#9 are about the server layer telling the client layer about the delays that can be expected. There is a little redundancy here so s/ower layer server network/server network/ and s/higher layer client network/client network/. No plans to skip layers. > Given the current document usage, I still think it makes sense to > eliminate the two instances of "client layer": How about the following: > OLD > Client LSP > A client LSP is an LSP which has been set up over a server layer. > In the context of this discussion, a client LSP is a LSP which > has been set up over a multipath as opposed to an LSP > representing the multipath itself or any LSP supporting a > component links of that multipath. > NEW > Client LSP > A client LSP is a LSP which > has been set up over Advanced Multipath as opposed to an LSP > representing the Advanced Multipath itself or any LSP that is > part of an Advanced Multipath Group. Nope. In general, a client LSP can be set up over a plain old Ethernet on a given hop, therefore the second definition is too narrow with this change. > and > OLD > The above set of requirements apply to component links with different > characteristics regardless as to whether those component links are > provided by parallel physical links between nodes or provided by sets > of paths across a network provided by server layer LSP. > NEW > The above set of requirements apply to component links with different > characteristics regardless as to whether those component links are > provided by parallel physical links between nodes or provided by > LSPs that are part of an Advanced Multipath Group. What about PW? Those are paths too by the definition of paths, so again, this change makes the definition too narrow. > >>>> 3. Technical: The document should make it clear that LSPs can provide > >>>> paths from an Advanced Multipath. I suggest adding something like the > >>>> the following at the end of page 3 > >>>> d. a lower layer LSP. > >>> > >>> Case "b." is intended to include LSP but is not specifically limited > >>> to LSP. Multipath (not Advanced Multipath) includes IGP ECMP, > >>> Ethernet Link Aggregation, and all sorts of things that don't involve > >>> MPLS at all. For example, a path in Ethernet Link Aggregation Group > >>> (LAG) could be supported by a pseudowires or ODU2e or GFP-F, though > >>> this would be unknown to the LAG, or in the simplest case each path in > >>> the set of LAG members could be supported by a plain Ethernet cable. > >>> > >> > >> okay, how about: > >> OLD > >> b. may be specific paths across a network to a destination > >> node, or > >> NEW > >> b. specific paths across a network to a destination > >> node (e.g., via an LSP), or > > > > OK. But I like to spell out "for example" and put it after the > > definition. That would give us: > > > > 4. The paths may be: > > > > a. parallel links between two nodes, or > > > > b. may be specific paths across a network to a destination > > node, or > > > > c. may be links or paths to an intermediate node used to > > reach a common destination. > > > > The paths need not have equal capacity. The paths may or may not > > have equal cost in a routing protocol. > > + Paths across a network which serve as a component link in a AMG > > + may be provided by other LSP acting as server LSP for the > > + client AMG. Component links of a given AMG need not all use the > > + same type of server layer technology. For example, one may be a > > + physical Ethernet, another a Packet Over Sonet (POS) link, > > + another a pseudowire, and another an LSP with individual hops > > + using a mix of lower layer technologies. > > > > Is that an acceptable clarification? > > Given the the definition of AMG I no longer see a need for the change or > proposed text (and would prefer not having to discuss the proposed text.) > ... OK. We won't make this addition. > >>>> 5. Technical: use of "indicate" in FR10-13, FR14, FR15: > >>>> In these cases it is unclear if the requirements apply to > >>>> (a) a client's ability to indicate a desired service/LSP constraint or > >>>> (b) a selected component link's attribute that will be used by a client > >>>> LSP, > >>>> (c) both, or > >>>> (d) something completely different > >>>> The requirements should be clear to which entity the requirement applies. > >>> > >>> This "indication" can be through signaling or the management plane and > >>> both must be supported in later framework and protocol definitions and > >>> we can argue then whether both must be supported or if one or the > >>> other is a "should" in RFC 2119 speak. > >>> > >>> There was concern that the word "signal" would exclude providing the > >>> same informantion through the management plane and therefore the word > >>> "indicate" is used. > >>> > >>> Rather than spell this out many times we hoped this would be clear. I > >>> could add clarifying text up front if you think this is necessary. For > >>> example, I could add the following before FR#1. > >>> > >>> FR#0 In requirements that follow in this document the word > >>> "indicate" is used where information may be provided by either > >>> the combination of link state IGP advertisement and MPLS LSP > >>> signaling or via management plane protocols. In later documents > >>> providing framework and protocol definitions both signaling and > >>> management plane mechanisms MUST be defined. > >>> > >> > >> So is this the IGP/signaling that runs between a client an an AM "LER", > >> between an AM "LSR" and its server network, or between AM LSRs? If I > >> understand AM properly, there may be *up to* there separate instances. > >> Am I missing something? > > > > Please don't abbreviate Advanced Multipath as AM. Link Aggregation is > > not LA. > > Perhaps you should a requirement on this ;-) Obvious acronym collision here, just like LA. > > The word "indicate" is independent of the method of getting the > > information there. But yes in the example given the IGP advertisement > > and MPLS LSP signaling that might be one such mechanism does refer to > > the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > > > > If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > > is only one IGP flooding information for both client and server layer, > > hence the seemingly endless (and mostly pointless) discussion of > > sub-layer vs layer from certain ITU people in the MPLS WG mailing list > > who viewed MPLS as broken for not enforcing a strict layering in this > > regard. But we need not go into that level of detail in this example > > of how independent of mechanism the "indicate" is and down that years > > old MPLS WG terminology rat hole again. > > > My comment is that you need to be clear to which layer a requirement > applies. Is it the server layer, the client layer or the Advanced > Multipath layer? In each of the requirements you cited it is very clear that the client later is communicating a requirement to the server layer, but if you'd like I can reword to make that even more clear by rewording of the form "SHALL provide a means for the client layer to indicate the requirements of a client LSP [regarding X]", where X is minimize latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific component link (FR#13), bidirection co-routed (FR#14), no reordering (FR#15), bounded frequency of rebalance (FR#20). > >>> It would be trivial to make this FR#1 and renumber the rest. > >>> > >> > >> I don't think the FR helped clarify the above question. > > > > The choice of the word "indicate" in FR10-13, FR14, FR15 does not > > imply usage by a specific layer. That is a direct answer to your > > question. > > > > In all of these specific cases, the the client layer is passing a > > requirement to the server layer so in the IGP + RSVP-TE world that > > would be a function of RSVP-TE. In the absense of control plane, it > > would have to be done through management plane interaction where the > > client indicates requirements of an LSP and the server layer is free > > to figure out how to meet those requirements. > > > > Do you want me to add the clarification on the use of the word > > "indicate" or not? > > I think you need to be clear that the requirement applies to all three > layers. There are no distinct three layers. You are imagining a model that is not used in this document so please don't impose model on our document. In your sentence above I have no idea what "the requirement" refers to. In summary: We were discussing why the word "indicate" was used to avoid requiring specific mechanisms for information passing and I asked if I should add the following. FR#0 In requirements that follow in this document the word "indicate" is used where information may be provided by either the combination of link state IGP advertisement and MPLS LSP signaling or via management plane protocols. In later documents providing framework and protocol definitions both signaling and management plane mechanisms MUST be defined. Information is two way. The requirements you cited were all worded in the form "The solution SHALL provide a means to indicate that a client LSP will ...". So far I have offerred to reword this to the form "The solution SHALL provide a means for the client layer to indicate a requirement that a client LSP will ..." (ie: get minimum latency, get bound latency, etc). Is adding FR#0 OK? Do you want this sort of rewording to make it more explicit that the client layer is communication a requirement for a specific client LSP? > >>> Should I add it and renumber? > >>> > >>>> 6. The last paragraph in section 3.3. strikes me as both odd and out of > >>>> place. There are so many possible decisions that must be considered by > >>>> network operators relative to disruption and optimization. Why mention > >>>> just "power reduction"? Is there something special about the > >>>> interactions of multipath and power reduction? What value / information > >>>> does this paragraph add? > >>> > >>> The last paragraph in section 3.3 is: > >>> > >>> Allowing multipath to contain component links with different > >>> characteristics can improve the overall load balance and can be > >>> accomplished while still accommodating the more strict requirements > >>> of a subset of client LSP. > >>> > >>> I'm not sure if this is the "odd and out of place" paragraph you refer > >>> to. It summarizes the purpose of the requirements in this section. I > >>> think you mean section 3.5 and not 3.3. > >>> > >> > >> Correct. > >> > >>> The remainder of your paragraph above discusses power reducetion and > >>> this is only mentioned in section 3.5 so I think you mean this > >>> paragraph. > >>> > >> Right again. > >> > >>> As with any load balancing change, a change initiated for the purpose > >>> of power reduction may be minimally disruptive. Typically the > >>> disruption is limited to a change in delay characteristics and the > >>> potential for a very brief period with traffic reordering. The > >>> network operator when configuring a network for power reduction > >>> should weigh the benefit of power reduction against the disadvantage > >>> of a minimal disruption. > >>> > >>> The paragraphs following a set of requirements provide discussion > >>> related to that set of requirements. I don't see this as out of > >>> place. The prior two paragraphs discuss delay discontinuity. This > >>> paragraph is a reminder that "As with any load balancing change, a > >>> change initiated for the purpose of power reduction may be minimally > >>> disruptive." I don't see this as out of place. > >>> > >>> For example, to compensate for a less than perfect load balance a > >>> subset of LSPs may need to be moved and that subset can be chosen from > >>> those which will be least affected (and there are plenty of > >>> requirements that compell the fussy LSP to tell the network abour > >>> their specifial needs). To power down a component link, *all* LSP on > >>> that component link need to be moved, even the very fussy ones. > >>> Therefore I think mentioning that disruption should be considered is > >>> not out of place in the discussion following these requirements. We > >>> like to keep the discussion brief so this level of detail was not > >>> included. > >>> > >> > >> I guess we see the importance of this topic differently. So will this > >> be the first RFC that uses the term "power reduction"? > > > > Perhaps. A co-author originally wanted it added. The set of authors > > kicked this around and reworded the original. The wording is brief > > and vague and the use of MAY in the actual requirement means we will > > not disallow this. So far no one in the WG has objected to this > > wording and its been there a long time. > > > > Would you like me to remove the requirement and discussion of its > > implications after the WG concensus so far was to keep it? > > > > I think the text opens the door to the objection/question as to why just > this "application" and not others are called out. Now that I've asked > the question, we can move on. The AD can always revisit if he so chooses. > > ... OK > >>>> Nits: > >>>> > >>>> - References should be provided in all cases when referring to > >>>> "existing ... techniques" > >>> > >>> References are not allowed in the abstract. In section 3.3 is the sentence: > >>> > >>> Refer to the Appendices in [I-D.ietf-rtgwg-cl-use-cases] for a > >>> description of existing techniques and a set of references. > >>> > >>> Much of that document is dedicated to describing existing techniques > >>> and it contains quite a few references. > >>> > >>> I can move this sentence. Where in the document would you like to see > >>> it moved to? > >>> > >> (Lines numbers from URL below.) > >> Lines 200/201 and 278 have this issue. Lines 297 and 342 do not. > >> > >>>> Using line numbers from > >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-rtgwg-cl-requirement-13.txt > >>> > >>> Using line number is a text editor counts the page headers. What tool > >>> are you using? I didn't see anything on tools.ietf.org. > >>> > >> huh. enter the above URL in a browser and you should see the line numbers. > >> > >>> So I'll guess. Looks like add 10 lines per page. > >>> > >> > >>>> Line 112 > >>>> s/SHOULD/should > >>> > >>> s/keywords, SHOULD be interpreted/keywords SHOULD be interpreted/ > >>> > >>> Also remove stray comma. > >>> > >> I don't think use of 2119 language being applied to the reader is > >> appropriate, but whatever... > > > > You want me to downcase "SHOULD be interpreted". I missed a M-l in > > the s/// edit (emacs downcase next word) and got only the stray comma. > > > > Right. > > >>>> Line 118 > >>>> s/MAY/may > >>> > >>> s/deployment MAY choose to/deployment may choose to/ > >>> > >>> OK. Could go either way but s/MAY chose to/MAY/ would work too. > >>> > >> No. The issue is that this document doesn't place conformance > >> requirements on a service provider so RFC2119 language isn't appropriate > >> here. > > > > No IETF document truly places conformance requirements on either the > > service provider or implementor, but we put RFC2119 language in > > telling them what to do all the time. No one in IETF signed a legal > > document forcing them to adhere to every RFC2119 keyword in each > > document. > > > > The requirements here are 1) implementor SHOULD provide a per feature > > knob to turn individual features off, 2) provider MAY use those knobs, > > including knobs that another implementor made available. > > I'd prefer the first to be a MUST, but you've documented wg consensus. > I don't think #2 makes any sense, but we can move on. > > > > > This is just trying to avoid unnecessarily inflexible specifications > > or unnecessarily inflexible implementations where some feature doesn't > > work when an unrelated feature is disabled. This is in here because > > this inflexibility happens. > > > > The framework can outline any feature dependencies. > > > >>>> Line 149, match intro: > >>>> s/Advanced Multipath meets/Advanced Multipath is a formalization of > >>>> multipath techniques that meet > >>> > >>> OK. > >>> > >>>> Lines 251-254, beginning with "The" through the end of the paragraph. > >>>> This should be an FR. > >>> > >>> Looks like you mean this: > >>> > >>> The transient period between some service disrupting > >>> event and the convergence of the routing and/or signaling protocols > >>> MUST occur within a time frame specified by Performance Objective > >>> values. > >>> > >> Right. > >>> OK. I'll add this as FR#6++. > >>> > >> > >>>> That's it, > >>>> Lou > >>> > >>> There are a few suggestions for changes to the text based on your > >>> comments and a few questions for you. Based on your response to this > >>> email I will edit the document. > >>> > >>> Thanks for the thorough review. > >>> > >> > >> Thanks for the responses and the resend! > >> > >> Lou > > > > Sorry to mess up my own DNS and require a resend and a delay. > > > NP! > > Lou Curtis From lberger@labn.net Fri Jan 10 09:35:50 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15B11AE126; Fri, 10 Jan 2014 09:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.188 X-Spam-Level: ** X-Spam-Status: No, score=2.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_BIZ=0.288, HELO_MISMATCH_BIZ=0.443, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.793, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M9_A_J5SHpk; Fri, 10 Jan 2014 09:35:47 -0800 (PST) Received: from newdragon.webhostserver.biz (unknown [69.25.137.16]) by ietfa.amsl.com (Postfix) with ESMTP id A1EA71AE119; Fri, 10 Jan 2014 09:35:47 -0800 (PST) Received: from localhost ([::1]:41520 helo=[127.0.0.1]) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from ) id 1W1fzb-0008Sh-Gq; Fri, 10 Jan 2014 20:35:35 +0300 Message-ID: <52D02F67.9070604@labn.net> Date: Fri, 10 Jan 2014 12:35:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401090433.s094XtlK060524@maildrop2.v6ds.occnc.com> In-Reply-To: <201401090433.s094XtlK060524@maildrop2.v6ds.occnc.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2014 17:35:50 -0000 Curtis, I think we have one disconnect (and corresponding related text) that we need to resolve before we can be close the discussion. See below for details.. On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > Converging. But maybe one more round trip needed. > > In message <52CD9D58.4010109@labn.net> > Lou Berger writes: >> ... >>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>> >>>>>> The document uses server and client layer networks and LSPs and, >>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>> client/server when referring to network layers and just using the >>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>> i.e.: >>>>>> OLD >>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>> NEW >>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>> >>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>> over an advanced multipath. >>>>> >>>> >>>> Would you accept s/server layer/lower layer/g? >>> >>> The definition of server layer is not the same as the definition of >>> lower layer. See below. >>> >>>>>> I think this also means that usage of the term "Client" is limited to >>>>>> "Client LSP". >>>>> >>>>> I searched for all occurances of the word client. All occurances are >>>/>> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>> used only in the following paragraph. >>>>> >>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>> general, multipath endpoints cannot determine requirements of clients >>>>> of a client LSP through participation in the signaling of the clients >>>>> of the client LSP. >>>>> >>>>> THe point is that "A midpoint LSR does not participate in the >>>>> signaling of any clients of the client LSP" and that non-participation >>>>> in client (or higher layer) signaling applies to any "client of a >>>>> client LSP", not just other LSP running over it. >>>>> >>>>> I then searched for all occurances of the words upper and lower and >>>>> higher. There are no occurances of "upper". >>>>> >>>>> There were a few occurances of "lower latency" and "higher latency". >>>>> Other than that, all occurances of lower and higher except one are in >>>>> the follwoing text: >>>>> >>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>> >>>>> A component link may be supported by a lower layer network. For >>>>> example, the lower layer may be a circuit switched network or another >>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>> the latency (and/or other performance parameters) seen by the client >>>>> layer. Currently, there is no protocol for the lower layer network >>>>> to inform the higher layer network of a change in a performance >>>>> parameter. Communication of the latency performance parameter is a >>>>> very important requirement. Communication of other performance >>>>> parameters (e.g., delay variation) is desirable. >>>>> >>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>> layer server network to communicate latency to the higher layer >>>>> client network. >>>>> >>>>> The exception is this sentence: >>>>> >>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>> multipath itself is a component link for a higher order advanced >>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>> TP bi-directional tunnels viewed as logical links could then be >>>>> used as a component link in yet another advanced multipath that >>>>> connects MPLS routers. >>>>> >>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>> back but that is before even my time. >>>>> >>>>> I don't think this is unclear but I could add the following in >>>>> definitions: >>>>> >>>>> Higher Layers >>>>> A client layer is the one immediately above a server layer. The >>>>> client layer and all layers above that layer are higher layers. >>>>> >>>>> Lower Layers >>>>> A server layer is the later immediately below a client laer. >>>>> The server layer and all layers below are lower layers. >>>>> >>>>> Do I really need to put this in the definitions section? If yoy think >>>>> it is necessary, I will add it. >>>>> >>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>> And to use it (consistently) in place of "client and server Layer". >>> >>> I guess you missed the distinction in the definition above: >>> >>> For layer X layer Y is: >>> >>> client layer === Y = X+1 >>> server layer === Y = X-1 >>> higher layer === Y > X >>> lower layer === Y < X >>> >>> So the definition client layer is not the same as the definition of >>> higher layer. The definition of server layer is not the same as the >>> definition of lower layer. >>> >>> In some discussions we really do mean "the server layer" and not any >>> layer at any arbitrary depth below this one. >> >> I read your usage of client/server layer to be synonymous with >> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >> of FR#8 (I think you really mean client layer not lower layer.) > > FR#8 and FR#9 are about the server layer telling the client layer > about the delays that can be expected. There is a little redundancy > here so s/ower layer server network/server network/ and > s/higher layer client network/client network/. No plans to skip > layers. > I think we need to hit the points below before this one... >> Given the current document usage, I still think it makes sense to >> eliminate the two instances of "client layer": How about the following: >> OLD >> Client LSP >> A client LSP is an LSP which has been set up over a server layer. >> In the context of this discussion, a client LSP is a LSP which >> has been set up over a multipath as opposed to an LSP >> representing the multipath itself or any LSP supporting a >> component links of that multipath. >> NEW >> Client LSP >> A client LSP is a LSP which >> has been set up over Advanced Multipath as opposed to an LSP >> representing the Advanced Multipath itself or any LSP that is >> part of an Advanced Multipath Group. > > Nope. In general, a client LSP can be set up over a plain old > Ethernet on a given hop, therefore the second definition is too > narrow with this change. > humm, you didn't have that in your OLD text. In fact, the old text reads to me that an Advanced Multipath (solution?) logically sits between a client LSP and an underlying server layer in all cases. So the model I see defined by the text has the following layers Client LSP (layer) ---------- Advanced Multipath (layer/solution/construct) ---------- Server Layer (composed of AMGs which are LSPs and/or links) Is this aligned with your intent? If not, can you explain the relationship you see for Advanced Multipath Client LSPs and Advanced Multipath AMGs? >> and >> OLD >> The above set of requirements apply to component links with different >> characteristics regardless as to whether those component links are >> provided by parallel physical links between nodes or provided by sets >> of paths across a network provided by server layer LSP. >> NEW >> The above set of requirements apply to component links with different >> characteristics regardless as to whether those component links are >> provided by parallel physical links between nodes or provided by >> LSPs that are part of an Advanced Multipath Group. > > What about PW? Those are paths too by the definition of paths, so > again, this change makes the definition too narrow. > PWs weren't mentioned in your OLD text, so I didn't add them. I also have no objections to adding them. The only change I made was s/sets of paths across a network provided by server layer LSP./ LSPs that are part of an Advanced Multipath Group. ... > >>> The word "indicate" is independent of the method of getting the >>> information there. But yes in the example given the IGP advertisement >>> and MPLS LSP signaling that might be one such mechanism does refer to >>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>> >>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>> is only one IGP flooding information for both client and server layer, >>> hence the seemingly endless (and mostly pointless) discussion of >>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>> who viewed MPLS as broken for not enforcing a strict layering in this >>> regard. But we need not go into that level of detail in this example >>> of how independent of mechanism the "indicate" is and down that years >>> old MPLS WG terminology rat hole again. >>> >> My comment is that you need to be clear to which layer a requirement >> applies. Is it the server layer, the client layer or the Advanced >> Multipath layer? > > In each of the requirements you cited it is very clear that the client > later is communicating a requirement to the server layer, but if you'd > like I can reword to make that even more clear by rewording of the > form "SHALL provide a means for the client layer to indicate the > requirements of a client LSP [regarding X]", where X is minimize > latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > component link (FR#13), bidirection co-routed (FR#14), no reordering > (FR#15), bounded frequency of rebalance (FR#20). Okay, I think this will/may help. My comment goes back to the model I was asking about above. And to which part of the puzzle the requirement applies. > >>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>> >>>> >>>> I don't think the FR helped clarify the above question. >>> >>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>> imply usage by a specific layer. That is a direct answer to your >>> question. >>> >>> In all of these specific cases, the the client layer is passing a >>> requirement to the server layer so in the IGP + RSVP-TE world that >>> would be a function of RSVP-TE. In the absense of control plane, it >>> would have to be done through management plane interaction where the >>> client indicates requirements of an LSP and the server layer is free >>> to figure out how to meet those requirements. >>> >>> Do you want me to add the clarification on the use of the word >>> "indicate" or not? >> >> I think you need to be clear that the requirement applies to all three >> layers. > > There are no distinct three layers. You are imagining a model that is > not used in this document so please don't impose model on our document. > Well your old definition of Client LSP said that it was a client of "multipath" and else where you say that "multipath" operates over a server layer. As mentioned above, this sounds like three layers to me. If this is not your intent, I think you need to make it clear (through revised text) what model you do intend. > In your sentence above I have no idea what "the requirement" refers to. > > In summary: > > We were discussing why the word "indicate" was used to avoid requiring > specific mechanisms for information passing and I asked if I should > add the following. > > FR#0 In requirements that follow in this document the word > "indicate" is used where information may be provided by either > the combination of link state IGP advertisement and MPLS LSP > signaling or via management plane protocols. In later documents > providing framework and protocol definitions both signaling and > management plane mechanisms MUST be defined. > > Information is two way. The requirements you cited were all worded in > the form "The solution SHALL provide a means to indicate that a client > LSP will ...". So far I have offerred to reword this to the form "The > solution SHALL provide a means for the client layer to indicate a > requirement that a client LSP will ..." (ie: get minimum latency, get > bound latency, etc). > > Is adding FR#0 OK? > > Do you want this sort of rewording to make it more explicit that the > client layer is communication a requirement for a specific client LSP? > I think we need to come back to this once we resolve the "model" topic. ... Thanks, Lou From curtis@ipv6.occnc.com Wed Jan 15 16:00:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC031AE453; Wed, 15 Jan 2014 16:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKHLMCUT7dD9; Wed, 15 Jan 2014 16:00:21 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id EF7EF1AE454; Wed, 15 Jan 2014 16:00:20 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0G006Pk025219; Wed, 15 Jan 2014 19:00:07 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401160000.s0G006Pk025219@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Fri, 10 Jan 2014 12:35:35 -0500." <52D02F67.9070604@labn.net> Date: Wed, 15 Jan 2014 19:00:06 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" , curtis@ipv6.occnc.com Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2014 00:00:26 -0000 In message <52D02F67.9070604@labn.net> Lou Berger writes: > Curtis, > > I think we have one disconnect (and corresponding related text) that we > need to resolve before we can be close the discussion. See below for > details.. > > On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > > Converging. But maybe one more round trip needed. > > > > In message <52CD9D58.4010109@labn.net> > > Lou Berger writes: > >> > ... > > >>>>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>>>> > >>>>>> The document uses server and client layer networks and LSPs and, > >>>>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>>>> client/server when referring to network layers and just using the > >>>>>> lower/upper terminology. The one exception to this is in the definition > >>>>>> Client LSP which should simply be defined in the context of a multipath, > >>>>>> i.e.: > >>>>>> OLD > >>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>> NEW > >>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>>>> > >>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>>>> over an advanced multipath. > >>>>> > >>>> > >>>> Would you accept s/server layer/lower layer/g? > >>> > >>> The definition of server layer is not the same as the definition of > >>> lower layer. See below. > >>> > >>>>>> I think this also means that usage of the term "Client" is limited to > >>>>>> "Client LSP". > >>>>> > >>>>> I searched for all occurances of the word client. All occurances are > >>>/>> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>>>> used only in the following paragraph. > >>>>> > >>>>> The ingress and egress of a multipath may be midpoint LSRs with > >>>>> respect to a given client LSP. A midpoint LSR does not participate > >>>>> in the signaling of any clients of the client LSP. Therefore, in > >>>>> general, multipath endpoints cannot determine requirements of clients > >>>>> of a client LSP through participation in the signaling of the clients > >>>>> of the client LSP. > >>>>> > >>>>> THe point is that "A midpoint LSR does not participate in the > >>>>> signaling of any clients of the client LSP" and that non-participation > >>>>> in client (or higher layer) signaling applies to any "client of a > >>>>> client LSP", not just other LSP running over it. > >>>>> > >>>>> I then searched for all occurances of the words upper and lower and > >>>>> higher. There are no occurances of "upper". > >>>>> > >>>>> There were a few occurances of "lower latency" and "higher latency". > >>>>> Other than that, all occurances of lower and higher except one are in > >>>>> the follwoing text: > >>>>> > >>>>> 3.2. Component Links Provided by Lower Layer Networks > >>>>> > >>>>> A component link may be supported by a lower layer network. For > >>>>> example, the lower layer may be a circuit switched network or another > >>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>>>> the latency (and/or other performance parameters) seen by the client > >>>>> layer. Currently, there is no protocol for the lower layer network > >>>>> to inform the higher layer network of a change in a performance > >>>>> parameter. Communication of the latency performance parameter is a > >>>>> very important requirement. Communication of other performance > >>>>> parameters (e.g., delay variation) is desirable. > >>>>> > >>>>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>>>> layer server network to communicate latency to the higher layer > >>>>> client network. > >>>>> > >>>>> The exception is this sentence: > >>>>> > >>>>> FR#22 The solution SHOULD support the use case where an advanced > >>>>> multipath itself is a component link for a higher order advanced > >>>>> multipath. For example, an advanced multipath comprised of MPLS- > >>>>> TP bi-directional tunnels viewed as logical links could then be > >>>>> used as a component link in yet another advanced multipath that > >>>>> connects MPLS routers. > >>>>> > >>>>> The terms lower layer and higher layer go all the way back to the ISO > >>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>>>> back but that is before even my time. > >>>>> > >>>>> I don't think this is unclear but I could add the following in > >>>>> definitions: > >>>>> > >>>>> Higher Layers > >>>>> A client layer is the one immediately above a server layer. The > >>>>> client layer and all layers above that layer are higher layers. > >>>>> > >>>>> Lower Layers > >>>>> A server layer is the later immediately below a client laer. > >>>>> The server layer and all layers below are lower layers. > >>>>> > >>>>> Do I really need to put this in the definitions section? If yoy think > >>>>> it is necessary, I will add it. > >>>>> > >>>> Perhaps we've talked (okay written) past each other. I was suggesting > >>>> using/keeping the "higher and lower layer" terminology, not dropping it. > >>>> And to use it (consistently) in place of "client and server Layer". > >>> > >>> I guess you missed the distinction in the definition above: > >>> > >>> For layer X layer Y is: > >>> > >>> client layer === Y = X+1 > >>> server layer === Y = X-1 > >>> higher layer === Y > X > >>> lower layer === Y < X > >>> > >>> So the definition client layer is not the same as the definition of > >>> higher layer. The definition of server layer is not the same as the > >>> definition of lower layer. > >>> > >>> In some discussions we really do mean "the server layer" and not any > >>> layer at any arbitrary depth below this one. > >> > >> I read your usage of client/server layer to be synonymous with > >> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > >> of FR#8 (I think you really mean client layer not lower layer.) > > > > FR#8 and FR#9 are about the server layer telling the client layer > > about the delays that can be expected. There is a little redundancy > > here so s/ower layer server network/server network/ and > > s/higher layer client network/client network/. No plans to skip > > layers. > > > > I think we need to hit the points below before this one... OK. > >> Given the current document usage, I still think it makes sense to > >> eliminate the two instances of "client layer": How about the following: > >> OLD > >> Client LSP > >> A client LSP is an LSP which has been set up over a server layer. > >> In the context of this discussion, a client LSP is a LSP which > >> has been set up over a multipath as opposed to an LSP > >> representing the multipath itself or any LSP supporting a > >> component links of that multipath. > >> NEW > >> Client LSP > >> A client LSP is a LSP which > >> has been set up over Advanced Multipath as opposed to an LSP > >> representing the Advanced Multipath itself or any LSP that is > >> part of an Advanced Multipath Group. > > > > Nope. In general, a client LSP can be set up over a plain old > > Ethernet on a given hop, therefore the second definition is too > > narrow with this change. > > > > humm, you didn't have that in your OLD text. In fact, the old text > reads to me that an Advanced Multipath (solution?) logically sits > between a client LSP and an underlying server layer in all cases. The "OLD" was a quote from you and it was the original text in -13. I said "Nope. ..." to your suggested change to it in this way. Earlier (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I had suggested the following change: I don't think this is unclear but I could add the following in definitions: Higher Layers A client layer is the one immediately above a server layer. The client layer and all layers above that layer are higher layers. Lower Layers A server layer is the later immediately below a client laer. The server layer and all layers below are lower layers. Do I really need to put this in the definitions section? If yoy think it is necessary, I will add it. You will find this in the quoted text above. The definition of client LSP does not imply that Advanced Multipath is a layer. This also used lower case "multipath" which we can replace with AMG. There is no LAG layer in a network in with MPLS runs over Ethernet and some of the Ethernets use Link Aggregation. > So the model I see defined by the text has the following layers > > Client LSP (layer) > ---------- > Advanced Multipath (layer/solution/construct) > ---------- > Server Layer (composed of AMGs which are LSPs and/or links) > > Is this aligned with your intent? If not, can you explain the > relationship you see for Advanced Multipath Client LSPs and Advanced > Multipath AMGs? You imaginged this model and are trying to constrain the text to fit into it.. Consider these examples of client layer and server layer. plain old rfc-4206 LSP-1 (PSC-0) = client of LSP-2 LSP-2 (PSC-1) = server of LSP-1 LSP over Ethernet over PW over MPLS LSP-1 = client of Ethernet Ethernet = server of LSP-1, client of PW PW = server of Ethernet, client of LSP-2 LSP-2 = server of PW There is then the question of whether Advanced Multipath is a layer or a set of techniques that can be applied at a given layer. Example potential config language: mple { tunnel x1 { type multipath { component tunnel x2; component tunnel x3; [...] component intf i1; component intf i2; [...] } [...] } [...] } No distinct layer above. An alternate: mple { tunnel x1 { [...] } [...] } interface amg1; type multipath { component tunnel x2; component tunnel x3; [...] component intf i1; component intf i2; [...] } [...] } [...] } In the former example, the tunnel x1 is forced to use a specific set of component links and apply multipath techniques to it. In the latter example, if tunnel x1 happen to find that interface amg1 was the lowest cost or otherwise preferred way to get to its destination it makes use of amg1 and if so inherits the use of the multipath techniques. There is no distinct multipath encapsulation at the date layer so some might argue that even in the second case there is no distinct layer, just a configuration convenience. Claiming that Advanced Multipath is of itself a layer may get us into a bigger can of worms. For example in today's ECMP, the next hop consists of multiple interfaces. ECMP is not considered a layer between IP and those interfaces. Link bundle is also not considered a layer. In the document we have not claimed that Advanced Multipath is a type of layer and we have not claimed that Advanced Multipath is not a type of layer. Either way we would get someone arguing that the opposite was true. [Some individuals it seems would pick the opposite of whatever we picked just because they like to argue about layering.] Need I remind you of the painfully long and mostly pointless arguments in MPLS during the early MPLS-TP work about whether an MPLS LSP carried within another hierarchical MPLS LSP was a layer or a sub-layer. We don't want to repeat that and the best way to do so is to not make any statement about whether Advanced Multipath is a layer or a sub-layer or a layering NOOP. Which of the above is the "right" way to do things may be at most a framework issue but may not come up until management plane entities are defined. It is certainly not a topic for a requirements document because it is deep into the "how it gets done". > >> and > >> OLD > >> The above set of requirements apply to component links with different > >> characteristics regardless as to whether those component links are > >> provided by parallel physical links between nodes or provided by sets > >> of paths across a network provided by server layer LSP. > >> NEW > >> The above set of requirements apply to component links with different > >> characteristics regardless as to whether those component links are > >> provided by parallel physical links between nodes or provided by > >> LSPs that are part of an Advanced Multipath Group. > > > > What about PW? Those are paths too by the definition of paths, so > > again, this change makes the definition too narrow. > > > > PWs weren't mentioned in your OLD text, so I didn't add them. I also > have no objections to adding them. Actually the text you wrote is incorrect. "The above requirement applies to component links" can include physical links and server layer LSP but adding that are part of an Advanced Multipath Group is incorrect. I'm not sure but I think this instance of "server layer" was added to that LSP wording because you were confused on last review about client LSP vs LSP over which Advanced Multipath was applied so I went around changing everything to "client LSP" or "server layer LSP" to make it more clear to you. You now seem to be stuck on the wording that is essentially saying "any type of component link" including "server layer LSP". > The only change I made was > s/sets of paths across a network provided by server layer LSP./ > LSPs that are part of an Advanced Multipath Group. And that change was wrong. A more correct change would be s/provided by server layer LSP/including paths provided by server layer LSP/ That would include any sort of path across the network. PW could be considered an emulated physcial link or another usable type of path across the network. The "above set of requirements" in this case have to do with passing down requirements for min latency, bounded latency, and bounded jitter. The original paragraph is: The above set of requirements apply to component links with different characteristics regardless as to whether those component links are provided by parallel physical links between nodes or provided by sets of paths across a network provided by server layer LSP. The intent is "The above set of requirements apply to component links" followed by "regardless of what type of component links they are" where we had disccssed two types being an interface or emulated interface (or virtual interface in some major vendor terms) or an LSP (which is also a virtual interface in some major vendor terms). I don't understand how you can get so hung up on the wording of what is intended to convey "regardless of what type of component links they are". This has always been clear to the WG. > >>> The word "indicate" is independent of the method of getting the > >>> information there. But yes in the example given the IGP advertisement > >>> and MPLS LSP signaling that might be one such mechanism does refer to > >>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > >>> > >>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > >>> is only one IGP flooding information for both client and server layer, > >>> hence the seemingly endless (and mostly pointless) discussion of > >>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list > >>> who viewed MPLS as broken for not enforcing a strict layering in this > >>> regard. But we need not go into that level of detail in this example > >>> of how independent of mechanism the "indicate" is and down that years > >>> old MPLS WG terminology rat hole again. > >>> > >> My comment is that you need to be clear to which layer a requirement > >> applies. Is it the server layer, the client layer or the Advanced > >> Multipath layer? > > > > In each of the requirements you cited it is very clear that the client > > later is communicating a requirement to the server layer, but if you'd > > like I can reword to make that even more clear by rewording of the > > form "SHALL provide a means for the client layer to indicate the > > requirements of a client LSP [regarding X]", where X is minimize > > latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > > component link (FR#13), bidirection co-routed (FR#14), no reordering > > (FR#15), bounded frequency of rebalance (FR#20). > > Okay, I think this will/may help. My comment goes back to the model I > was asking about above. And to which part of the puzzle the requirement > applies. In some of the above requirements client layer communicated to the server layer, whatever the server layer is. Means of communication presumed to be RSVP-TE but we can't say that until the framework and same capability needs to be available to management plane. In some of the above requirements server layer communicates to the client layer. Means of communication is presumed to be IGP extensions, again with same capability available to management plane. There is no distinct Advanced Multipath layer in control plane or data plane. And if there was a distinct control plane layer it would be defined in a framework, not a requirements document. > >>>>> It would be trivial to make this FR#1 and renumber the rest. > >>>>> > >>>> > >>>> I don't think the FR helped clarify the above question. > >>> > >>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not > >>> imply usage by a specific layer. That is a direct answer to your > >>> question. > >>> > >>> In all of these specific cases, the the client layer is passing a > >>> requirement to the server layer so in the IGP + RSVP-TE world that > >>> would be a function of RSVP-TE. In the absense of control plane, it > >>> would have to be done through management plane interaction where the > >>> client indicates requirements of an LSP and the server layer is free > >>> to figure out how to meet those requirements. > >>> > >>> Do you want me to add the clarification on the use of the word > >>> "indicate" or not? > >> > >> I think you need to be clear that the requirement applies to all three > >> layers. > > > > There are no distinct three layers. You are imagining a model that is > > not used in this document so please don't impose model on our document. > > > > Well your old definition of Client LSP said that it was a client of > "multipath" and else where you say that "multipath" operates over a > server layer. As mentioned above, this sounds like three layers to me. > If this is not your intent, I think you need to make it clear (through > revised text) what model you do intend. This is the current text in -13: Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. The text is trying to clarify what a "client LSP" is in the first sentence and then trying to give two cases of what a client LSP is not. This clarification was specifically added *for you* in the last iteration. There was no intention to imply that Advanced Multipath is or is not in of itself a type of layer. If you are getting that notion from this text, then we need to change it. OLD: Client LSP A client LSP is an LSP which has been set up over a server layer. In the context of this discussion, a client LSP is a LSP which has been set up over a multipath as opposed to an LSP representing the multipath itself or any LSP supporting a component links of that multipath. NEW: Client LSP A client LSP is an LSP which has been set up over a set of one or more lower layers. In the context of this discussion, one type of client LSP is a LSP which has been set up over an AMG. We could also add a clarification to the definitions section that states: This document makes no statement on whether Advanced Multipath is itself a layer or whether an instance of AMG is itself a layer. This is to avoid engaging in long and pointless discussions about what consistitutes a proper layer. I would *really* like to add the above statement. > > In your sentence above I have no idea what "the requirement" refers to. > > > > In summary: > > > > We were discussing why the word "indicate" was used to avoid requiring > > specific mechanisms for information passing and I asked if I should > > add the following. > > > > FR#0 In requirements that follow in this document the word > > "indicate" is used where information may be provided by either > > the combination of link state IGP advertisement and MPLS LSP > > signaling or via management plane protocols. In later documents > > providing framework and protocol definitions both signaling and > > management plane mechanisms MUST be defined. > > > > Information is two way. The requirements you cited were all worded in > > the form "The solution SHALL provide a means to indicate that a client > > LSP will ...". So far I have offerred to reword this to the form "The > > solution SHALL provide a means for the client layer to indicate a > > requirement that a client LSP will ..." (ie: get minimum latency, get > > bound latency, etc). > > > > Is adding FR#0 OK? > > > > Do you want this sort of rewording to make it more explicit that the > > client layer is communication a requirement for a specific client LSP? > > > > I think we need to come back to this once we resolve the "model" topic. > > ... > > Thanks, > Lou I hope it is resolved. Curtis From lberger@labn.net Thu Jan 16 18:03:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC531ADBD0 for ; Thu, 16 Jan 2014 18:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuwATe790YnF for ; Thu, 16 Jan 2014 18:03:43 -0800 (PST) Received: from alt-proxy11.mail.unifiedlayer.com (alt-proxy11.mail.unifiedlayer.com [74.220.211.241]) by ietfa.amsl.com (Postfix) with SMTP id B439A1ADBCE for ; Thu, 16 Jan 2014 18:03:43 -0800 (PST) Received: (qmail 20364 invoked by uid 0); 17 Jan 2014 02:03:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy16.mail.unifiedlayer.com with SMTP; 17 Jan 2014 02:03:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=IS8TV3pNZ+PrDXWBpB5ruPOhg3zHfwRZj8lpajdbQmc=; b=Zh5kxegxlR7NcjHNppCOU/Ehuxs0Vhyt9K+uPpT3HH6D+Cnuq/7N2cd9Zx6ZTpuUkR02EPTt6H1tTZFv8vzrq7TViHSjH51/JgjIkdHv8YXhKw14Vyxs6ZACZDfBMv9M; Received: from box313.bluehost.com ([69.89.31.113]:35186 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W3ymP-0002FI-Qm; Thu, 16 Jan 2014 19:03:30 -0700 Message-ID: <52D88F77.5020009@labn.net> Date: Thu, 16 Jan 2014 21:03:35 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401160000.s0G006Pk025219@maildrop2.v6ds.occnc.com> In-Reply-To: <201401160000.s0G006Pk025219@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 02:03:47 -0000 Curtis, I'm not sure if we're going around in circles or not, but in either case case I think we're getting caught up in the weeds/details. >From a high level perspective, my comments have been motivated by trying to ensure the requirements are unambiguous -- as documented. I think the text changes that have been agreed to so far (notably the use of the capitalized term and introduction of AMG) will help a lot. I think there is still one more area that is unclear, but it's also possible that we're arguing about text that you are planning to change. Do you have a version that captures all the changes to date that you can distribute (or submit, as you choose)? Perhaps looking at this version we'll find that the ambiguity is resolved or is sufficiently narrowed to not be significant. Either way, the discussion can then continue from the most current text. Thanks, Lou On 1/15/2014 7:00 PM, Curtis Villamizar wrote: > In message <52D02F67.9070604@labn.net> > Lou Berger writes: > >> Curtis, >> >> I think we have one disconnect (and corresponding related text) that we >> need to resolve before we can be close the discussion. See below for >> details.. >> >> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>> Converging. But maybe one more round trip needed. >>> >>> In message <52CD9D58.4010109@labn.net> >>> Lou Berger writes: >>>> >> ... >> >>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>>>> >>>>>>>> The document uses server and client layer networks and LSPs and, >>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>>>> client/server when referring to network layers and just using the >>>>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>>>> i.e.: >>>>>>>> OLD >>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>> NEW >>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>>>> >>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>>>> over an advanced multipath. >>>>>>> >>>>>> >>>>>> Would you accept s/server layer/lower layer/g? >>>>> >>>>> The definition of server layer is not the same as the definition of >>>>> lower layer. See below. >>>>> >>>>>>>> I think this also means that usage of the term "Client" is limited to >>>>>>>> "Client LSP". >>>>>>> >>>>>>> I searched for all occurances of the word client. All occurances are >>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>>>> used only in the following paragraph. >>>>>>> >>>>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>>>> general, multipath endpoints cannot determine requirements of clients >>>>>>> of a client LSP through participation in the signaling of the clients >>>>>>> of the client LSP. >>>>>>> >>>>>>> THe point is that "A midpoint LSR does not participate in the >>>>>>> signaling of any clients of the client LSP" and that non-participation >>>>>>> in client (or higher layer) signaling applies to any "client of a >>>>>>> client LSP", not just other LSP running over it. >>>>>>> >>>>>>> I then searched for all occurances of the words upper and lower and >>>>>>> higher. There are no occurances of "upper". >>>>>>> >>>>>>> There were a few occurances of "lower latency" and "higher latency". >>>>>>> Other than that, all occurances of lower and higher except one are in >>>>>>> the follwoing text: >>>>>>> >>>>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>>>> >>>>>>> A component link may be supported by a lower layer network. For >>>>>>> example, the lower layer may be a circuit switched network or another >>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>>>> the latency (and/or other performance parameters) seen by the client >>>>>>> layer. Currently, there is no protocol for the lower layer network >>>>>>> to inform the higher layer network of a change in a performance >>>>>>> parameter. Communication of the latency performance parameter is a >>>>>>> very important requirement. Communication of other performance >>>>>>> parameters (e.g., delay variation) is desirable. >>>>>>> >>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>>>> layer server network to communicate latency to the higher layer >>>>>>> client network. >>>>>>> >>>>>>> The exception is this sentence: >>>>>>> >>>>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>>>> multipath itself is a component link for a higher order advanced >>>>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>>>> TP bi-directional tunnels viewed as logical links could then be >>>>>>> used as a component link in yet another advanced multipath that >>>>>>> connects MPLS routers. >>>>>>> >>>>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>>>> back but that is before even my time. >>>>>>> >>>>>>> I don't think this is unclear but I could add the following in >>>>>>> definitions: >>>>>>> >>>>>>> Higher Layers >>>>>>> A client layer is the one immediately above a server layer. The >>>>>>> client layer and all layers above that layer are higher layers. >>>>>>> >>>>>>> Lower Layers >>>>>>> A server layer is the later immediately below a client laer. >>>>>>> The server layer and all layers below are lower layers. >>>>>>> >>>>>>> Do I really need to put this in the definitions section? If yoy think >>>>>>> it is necessary, I will add it. >>>>>>> >>>>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>>>> And to use it (consistently) in place of "client and server Layer". >>>>> >>>>> I guess you missed the distinction in the definition above: >>>>> >>>>> For layer X layer Y is: >>>>> >>>>> client layer === Y = X+1 >>>>> server layer === Y = X-1 >>>>> higher layer === Y > X >>>>> lower layer === Y < X >>>>> >>>>> So the definition client layer is not the same as the definition of >>>>> higher layer. The definition of server layer is not the same as the >>>>> definition of lower layer. >>>>> >>>>> In some discussions we really do mean "the server layer" and not any >>>>> layer at any arbitrary depth below this one. >>>> >>>> I read your usage of client/server layer to be synonymous with >>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >>>> of FR#8 (I think you really mean client layer not lower layer.) >>> >>> FR#8 and FR#9 are about the server layer telling the client layer >>> about the delays that can be expected. There is a little redundancy >>> here so s/ower layer server network/server network/ and >>> s/higher layer client network/client network/. No plans to skip >>> layers. >>> >> >> I think we need to hit the points below before this one... > > OK. > >>>> Given the current document usage, I still think it makes sense to >>>> eliminate the two instances of "client layer": How about the following: >>>> OLD >>>> Client LSP >>>> A client LSP is an LSP which has been set up over a server layer. >>>> In the context of this discussion, a client LSP is a LSP which >>>> has been set up over a multipath as opposed to an LSP >>>> representing the multipath itself or any LSP supporting a >>>> component links of that multipath. >>>> NEW >>>> Client LSP >>>> A client LSP is a LSP which >>>> has been set up over Advanced Multipath as opposed to an LSP >>>> representing the Advanced Multipath itself or any LSP that is >>>> part of an Advanced Multipath Group. >>> >>> Nope. In general, a client LSP can be set up over a plain old >>> Ethernet on a given hop, therefore the second definition is too >>> narrow with this change. >>> >> >> humm, you didn't have that in your OLD text. In fact, the old text >> reads to me that an Advanced Multipath (solution?) logically sits >> between a client LSP and an underlying server layer in all cases. > > The "OLD" was a quote from you and it was the original text in -13. I > said "Nope. ..." to your suggested change to it in this way. > > Earlier > (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I > had suggested the following change: > > I don't think this is unclear but I could add the following in > definitions: > > Higher Layers > A client layer is the one immediately above a server layer. The > client layer and all layers above that layer are higher layers. > > Lower Layers > A server layer is the later immediately below a client laer. > The server layer and all layers below are lower layers. > > Do I really need to put this in the definitions section? If yoy think > it is necessary, I will add it. > > You will find this in the quoted text above. > > The definition of client LSP does not imply that Advanced Multipath is > a layer. This also used lower case "multipath" which we can replace > with AMG. There is no LAG layer in a network in with MPLS runs over > Ethernet and some of the Ethernets use Link Aggregation. > >> So the model I see defined by the text has the following layers >> >> Client LSP (layer) >> ---------- >> Advanced Multipath (layer/solution/construct) >> ---------- >> Server Layer (composed of AMGs which are LSPs and/or links) >> >> Is this aligned with your intent? If not, can you explain the >> relationship you see for Advanced Multipath Client LSPs and Advanced >> Multipath AMGs? > > You imaginged this model and are trying to constrain the text to fit > into it.. > > Consider these examples of client layer and server layer. > > plain old rfc-4206 > > LSP-1 (PSC-0) = client of LSP-2 > LSP-2 (PSC-1) = server of LSP-1 > > LSP over Ethernet over PW over MPLS > > LSP-1 = client of Ethernet > Ethernet = server of LSP-1, client of PW > PW = server of Ethernet, client of LSP-2 > LSP-2 = server of PW > > There is then the question of whether Advanced Multipath is a layer or > a set of techniques that can be applied at a given layer. Example > potential config language: > > mple { > tunnel x1 { > type multipath { > component tunnel x2; > component tunnel x3; > [...] > component intf i1; > component intf i2; > [...] > } > [...] > } > [...] > } > > No distinct layer above. > > An alternate: > > mple { > tunnel x1 { > [...] > } > [...] > } > > interface amg1; > type multipath { > component tunnel x2; > component tunnel x3; > [...] > component intf i1; > component intf i2; > [...] > } > [...] > } > [...] > } > > In the former example, the tunnel x1 is forced to use a specific set > of component links and apply multipath techniques to it. > > In the latter example, if tunnel x1 happen to find that interface amg1 > was the lowest cost or otherwise preferred way to get to its > destination it makes use of amg1 and if so inherits the use of the > multipath techniques. > > There is no distinct multipath encapsulation at the date layer so some > might argue that even in the second case there is no distinct layer, > just a configuration convenience. > > Claiming that Advanced Multipath is of itself a layer may get us into > a bigger can of worms. > > For example in today's ECMP, the next hop consists of multiple > interfaces. ECMP is not considered a layer between IP and those > interfaces. Link bundle is also not considered a layer. > > In the document we have not claimed that Advanced Multipath is a type > of layer and we have not claimed that Advanced Multipath is not a type > of layer. Either way we would get someone arguing that the opposite > was true. [Some individuals it seems would pick the opposite of > whatever we picked just because they like to argue about layering.] > > Need I remind you of the painfully long and mostly pointless arguments > in MPLS during the early MPLS-TP work about whether an MPLS LSP > carried within another hierarchical MPLS LSP was a layer or a > sub-layer. We don't want to repeat that and the best way to do so is > to not make any statement about whether Advanced Multipath is a layer > or a sub-layer or a layering NOOP. > > Which of the above is the "right" way to do things may be at most a > framework issue but may not come up until management plane entities > are defined. It is certainly not a topic for a requirements document > because it is deep into the "how it gets done". > >>>> and >>>> OLD >>>> The above set of requirements apply to component links with different >>>> characteristics regardless as to whether those component links are >>>> provided by parallel physical links between nodes or provided by sets >>>> of paths across a network provided by server layer LSP. >>>> NEW >>>> The above set of requirements apply to component links with different >>>> characteristics regardless as to whether those component links are >>>> provided by parallel physical links between nodes or provided by >>>> LSPs that are part of an Advanced Multipath Group. >>> >>> What about PW? Those are paths too by the definition of paths, so >>> again, this change makes the definition too narrow. >>> >> >> PWs weren't mentioned in your OLD text, so I didn't add them. I also >> have no objections to adding them. > > Actually the text you wrote is incorrect. "The above requirement > applies to component links" can include physical links and server > layer LSP but adding that are part of an Advanced Multipath Group is > incorrect. > > I'm not sure but I think this instance of "server layer" was added to > that LSP wording because you were confused on last review about client > LSP vs LSP over which Advanced Multipath was applied so I went around > changing everything to "client LSP" or "server layer LSP" to make it > more clear to you. You now seem to be stuck on the wording that is > essentially saying "any type of component link" including "server > layer LSP". > >> The only change I made was >> s/sets of paths across a network provided by server layer LSP./ >> LSPs that are part of an Advanced Multipath Group. > > And that change was wrong. A more correct change would be > > s/provided by server layer LSP/including paths provided by server > layer LSP/ > > That would include any sort of path across the network. PW could be > considered an emulated physcial link or another usable type of path > across the network. > > The "above set of requirements" in this case have to do with passing > down requirements for min latency, bounded latency, and bounded > jitter. The original paragraph is: > > The above set of requirements apply to component links with > different characteristics regardless as to whether those component > links are provided by parallel physical links between nodes or > provided by sets of paths across a network provided by server layer > LSP. > > The intent is "The above set of requirements apply to component links" > followed by "regardless of what type of component links they are" > where we had disccssed two types being an interface or emulated > interface (or virtual interface in some major vendor terms) or an LSP > (which is also a virtual interface in some major vendor terms). > > I don't understand how you can get so hung up on the wording of what > is intended to convey "regardless of what type of component links they > are". This has always been clear to the WG. > >>>>> The word "indicate" is independent of the method of getting the >>>>> information there. But yes in the example given the IGP advertisement >>>>> and MPLS LSP signaling that might be one such mechanism does refer to >>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>>>> >>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>>>> is only one IGP flooding information for both client and server layer, >>>>> hence the seemingly endless (and mostly pointless) discussion of >>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>>>> who viewed MPLS as broken for not enforcing a strict layering in this >>>>> regard. But we need not go into that level of detail in this example >>>>> of how independent of mechanism the "indicate" is and down that years >>>>> old MPLS WG terminology rat hole again. >>>>> >>>> My comment is that you need to be clear to which layer a requirement >>>> applies. Is it the server layer, the client layer or the Advanced >>>> Multipath layer? >>> >>> In each of the requirements you cited it is very clear that the client >>> later is communicating a requirement to the server layer, but if you'd >>> like I can reword to make that even more clear by rewording of the >>> form "SHALL provide a means for the client layer to indicate the >>> requirements of a client LSP [regarding X]", where X is minimize >>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>> (FR#15), bounded frequency of rebalance (FR#20). >> >> Okay, I think this will/may help. My comment goes back to the model I >> was asking about above. And to which part of the puzzle the requirement >> applies. > > In some of the above requirements client layer communicated to the > server layer, whatever the server layer is. Means of communication > presumed to be RSVP-TE but we can't say that until the framework and > same capability needs to be available to management plane. > > In some of the above requirements server layer communicates to the > client layer. Means of communication is presumed to be IGP > extensions, again with same capability available to management plane. > > There is no distinct Advanced Multipath layer in control plane or data > plane. And if there was a distinct control plane layer it would be > defined in a framework, not a requirements document. > >>>>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>>>> >>>>>> >>>>>> I don't think the FR helped clarify the above question. >>>>> >>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>>>> imply usage by a specific layer. That is a direct answer to your >>>>> question. >>>>> >>>>> In all of these specific cases, the the client layer is passing a >>>>> requirement to the server layer so in the IGP + RSVP-TE world that >>>>> would be a function of RSVP-TE. In the absense of control plane, it >>>>> would have to be done through management plane interaction where the >>>>> client indicates requirements of an LSP and the server layer is free >>>>> to figure out how to meet those requirements. >>>>> >>>>> Do you want me to add the clarification on the use of the word >>>>> "indicate" or not? >>>> >>>> I think you need to be clear that the requirement applies to all three >>>> layers. >>> >>> There are no distinct three layers. You are imagining a model that is >>> not used in this document so please don't impose model on our document. >>> >> >> Well your old definition of Client LSP said that it was a client of >> "multipath" and else where you say that "multipath" operates over a >> server layer. As mentioned above, this sounds like three layers to me. >> If this is not your intent, I think you need to make it clear (through >> revised text) what model you do intend. > > This is the current text in -13: > > Client LSP > A client LSP is an LSP which has been set up over a server layer. > In the context of this discussion, a client LSP is a LSP which > has been set up over a multipath as opposed to an LSP > representing the multipath itself or any LSP supporting a > component links of that multipath. > > The text is trying to clarify what a "client LSP" is in the first > sentence and then trying to give two cases of what a client LSP is > not. This clarification was specifically added *for you* in the last > iteration. > > There was no intention to imply that Advanced Multipath is or is not > in of itself a type of layer. If you are getting that notion from > this text, then we need to change it. > > OLD: > > Client LSP > A client LSP is an LSP which has been set up over a server layer. > In the context of this discussion, a client LSP is a LSP which > has been set up over a multipath as opposed to an LSP > representing the multipath itself or any LSP supporting a > component links of that multipath. > > NEW: > > Client LSP > > A client LSP is an LSP which has been set up over a set of one > or more lower layers. In the context of this discussion, one > type of client LSP is a LSP which has been set up over an AMG. > > We could also add a clarification to the definitions section that > states: > > This document makes no statement on whether Advanced Multipath is > itself a layer or whether an instance of AMG is itself a layer. > This is to avoid engaging in long and pointless discussions about > what consistitutes a proper layer. > > I would *really* like to add the above statement. > >>> In your sentence above I have no idea what "the requirement" refers to. >>> >>> In summary: >>> >>> We were discussing why the word "indicate" was used to avoid requiring >>> specific mechanisms for information passing and I asked if I should >>> add the following. >>> >>> FR#0 In requirements that follow in this document the word >>> "indicate" is used where information may be provided by either >>> the combination of link state IGP advertisement and MPLS LSP >>> signaling or via management plane protocols. In later documents >>> providing framework and protocol definitions both signaling and >>> management plane mechanisms MUST be defined. >>> >>> Information is two way. The requirements you cited were all worded in >>> the form "The solution SHALL provide a means to indicate that a client >>> LSP will ...". So far I have offerred to reword this to the form "The >>> solution SHALL provide a means for the client layer to indicate a >>> requirement that a client LSP will ..." (ie: get minimum latency, get >>> bound latency, etc). >>> >>> Is adding FR#0 OK? >>> >>> Do you want this sort of rewording to make it more explicit that the >>> client layer is communication a requirement for a specific client LSP? >>> >> >> I think we need to come back to this once we resolve the "model" topic. >> >> ... >> >> Thanks, >> Lou > > I hope it is resolved. > > Curtis > > > > From curtis@ipv6.occnc.com Fri Jan 17 09:41:25 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B8F1A1F4C; Fri, 17 Jan 2014 09:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtJ0x9UC7z_2; Fri, 17 Jan 2014 09:41:21 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8B71A16F0; Fri, 17 Jan 2014 09:41:21 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0HHf6sb063221; Fri, 17 Jan 2014 12:41:06 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401171741.s0HHf6sb063221@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Thu, 16 Jan 2014 21:03:35 -0500." <52D88F77.5020009@labn.net> Date: Fri, 17 Jan 2014 12:41:06 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" , curtis@ipv6.occnc.com Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 17:41:25 -0000 In message <52D88F77.5020009@labn.net> Lou Berger writes: > Curtis, > I'm not sure if we're going around in circles or not, but in either > case case I think we're getting caught up in the weeds/details. > > >From a high level perspective, my comments have been motivated by trying > to ensure the requirements are unambiguous -- as documented. I think > the text changes that have been agreed to so far (notably the use of the > capitalized term and introduction of AMG) will help a lot. I think there > is still one more area that is unclear, but it's also possible that > we're arguing about text that you are planning to change. > > Do you have a version that captures all the changes to date that you can > distribute (or submit, as you choose)? Perhaps looking at this version > we'll find that the ambiguity is resolved or is sufficiently narrowed to > not be significant. Either way, the discussion can then continue from > the most current text. > > Thanks, > Lou Lou, I was going to suggest the same (if I understand your suggestion) - that is that a new draft be submitted and you (and others) can review and see if clarity has been sufficiently improved or if there are still issues with clarity. If that is OK with you and compatible with this process I will make two draft submissions back to back. One with just the OpsDir review comments addressed and a second with your comments so far addressed. IMHO it would be easier to discuss the clarity (or lack of) of the wording once changes have been made particularly since there are a few s/old/new/g terminology suggestions in the email thread. Curtis > On 1/15/2014 7:00 PM, Curtis Villamizar wrote: > > In message <52D02F67.9070604@labn.net> > > Lou Berger writes: > > > >> Curtis, > >> > >> I think we have one disconnect (and corresponding related text) that we > >> need to resolve before we can be close the discussion. See below for > >> details.. > >> > >> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > >>> Converging. But maybe one more round trip needed. > >>> > >>> In message <52CD9D58.4010109@labn.net> > >>> Lou Berger writes: > >>>> > >> ... > >> > >>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>>>>>> > >>>>>>>> The document uses server and client layer networks and LSPs and, > >>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>>>>>> client/server when referring to network layers and just using the > >>>>>>>> lower/upper terminology. The one exception to this is in the definition > >>>>>>>> Client LSP which should simply be defined in the context of a multipath, > >>>>>>>> i.e.: > >>>>>>>> OLD > >>>>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>>>> NEW > >>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>>>>>> > >>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>>>>>> over an advanced multipath. > >>>>>>> > >>>>>> > >>>>>> Would you accept s/server layer/lower layer/g? > >>>>> > >>>>> The definition of server layer is not the same as the definition of > >>>>> lower layer. See below. > >>>>> > >>>>>>>> I think this also means that usage of the term "Client" is limited to > >>>>>>>> "Client LSP". > >>>>>>> > >>>>>>> I searched for all occurances of the word client. All occurances are > >>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>>>>>> used only in the following paragraph. > >>>>>>> > >>>>>>> The ingress and egress of a multipath may be midpoint LSRs with > >>>>>>> respect to a given client LSP. A midpoint LSR does not participate > >>>>>>> in the signaling of any clients of the client LSP. Therefore, in > >>>>>>> general, multipath endpoints cannot determine requirements of clients > >>>>>>> of a client LSP through participation in the signaling of the clients > >>>>>>> of the client LSP. > >>>>>>> > >>>>>>> THe point is that "A midpoint LSR does not participate in the > >>>>>>> signaling of any clients of the client LSP" and that non-participation > >>>>>>> in client (or higher layer) signaling applies to any "client of a > >>>>>>> client LSP", not just other LSP running over it. > >>>>>>> > >>>>>>> I then searched for all occurances of the words upper and lower and > >>>>>>> higher. There are no occurances of "upper". > >>>>>>> > >>>>>>> There were a few occurances of "lower latency" and "higher latency". > >>>>>>> Other than that, all occurances of lower and higher except one are in > >>>>>>> the follwoing text: > >>>>>>> > >>>>>>> 3.2. Component Links Provided by Lower Layer Networks > >>>>>>> > >>>>>>> A component link may be supported by a lower layer network. For > >>>>>>> example, the lower layer may be a circuit switched network or another > >>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>>>>>> the latency (and/or other performance parameters) seen by the client > >>>>>>> layer. Currently, there is no protocol for the lower layer network > >>>>>>> to inform the higher layer network of a change in a performance > >>>>>>> parameter. Communication of the latency performance parameter is a > >>>>>>> very important requirement. Communication of other performance > >>>>>>> parameters (e.g., delay variation) is desirable. > >>>>>>> > >>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>>>>>> layer server network to communicate latency to the higher layer > >>>>>>> client network. > >>>>>>> > >>>>>>> The exception is this sentence: > >>>>>>> > >>>>>>> FR#22 The solution SHOULD support the use case where an advanced > >>>>>>> multipath itself is a component link for a higher order advanced > >>>>>>> multipath. For example, an advanced multipath comprised of MPLS- > >>>>>>> TP bi-directional tunnels viewed as logical links could then be > >>>>>>> used as a component link in yet another advanced multipath that > >>>>>>> connects MPLS routers. > >>>>>>> > >>>>>>> The terms lower layer and higher layer go all the way back to the ISO > >>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>>>>>> back but that is before even my time. > >>>>>>> > >>>>>>> I don't think this is unclear but I could add the following in > >>>>>>> definitions: > >>>>>>> > >>>>>>> Higher Layers > >>>>>>> A client layer is the one immediately above a server layer. The > >>>>>>> client layer and all layers above that layer are higher layers. > >>>>>>> > >>>>>>> Lower Layers > >>>>>>> A server layer is the later immediately below a client laer. > >>>>>>> The server layer and all layers below are lower layers. > >>>>>>> > >>>>>>> Do I really need to put this in the definitions section? If yoy think > >>>>>>> it is necessary, I will add it. > >>>>>>> > >>>>>> Perhaps we've talked (okay written) past each other. I was suggesting > >>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. > >>>>>> And to use it (consistently) in place of "client and server Layer". > >>>>> > >>>>> I guess you missed the distinction in the definition above: > >>>>> > >>>>> For layer X layer Y is: > >>>>> > >>>>> client layer === Y = X+1 > >>>>> server layer === Y = X-1 > >>>>> higher layer === Y > X > >>>>> lower layer === Y < X > >>>>> > >>>>> So the definition client layer is not the same as the definition of > >>>>> higher layer. The definition of server layer is not the same as the > >>>>> definition of lower layer. > >>>>> > >>>>> In some discussions we really do mean "the server layer" and not any > >>>>> layer at any arbitrary depth below this one. > >>>> > >>>> I read your usage of client/server layer to be synonymous with > >>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > >>>> of FR#8 (I think you really mean client layer not lower layer.) > >>> > >>> FR#8 and FR#9 are about the server layer telling the client layer > >>> about the delays that can be expected. There is a little redundancy > >>> here so s/ower layer server network/server network/ and > >>> s/higher layer client network/client network/. No plans to skip > >>> layers. > >>> > >> > >> I think we need to hit the points below before this one... > > > > OK. > > > >>>> Given the current document usage, I still think it makes sense to > >>>> eliminate the two instances of "client layer": How about the following: > >>>> OLD > >>>> Client LSP > >>>> A client LSP is an LSP which has been set up over a server layer. > >>>> In the context of this discussion, a client LSP is a LSP which > >>>> has been set up over a multipath as opposed to an LSP > >>>> representing the multipath itself or any LSP supporting a > >>>> component links of that multipath. > >>>> NEW > >>>> Client LSP > >>>> A client LSP is a LSP which > >>>> has been set up over Advanced Multipath as opposed to an LSP > >>>> representing the Advanced Multipath itself or any LSP that is > >>>> part of an Advanced Multipath Group. > >>> > >>> Nope. In general, a client LSP can be set up over a plain old > >>> Ethernet on a given hop, therefore the second definition is too > >>> narrow with this change. > >>> > >> > >> humm, you didn't have that in your OLD text. In fact, the old text > >> reads to me that an Advanced Multipath (solution?) logically sits > >> between a client LSP and an underlying server layer in all cases. > > > > The "OLD" was a quote from you and it was the original text in -13. I > > said "Nope. ..." to your suggested change to it in this way. > > > > Earlier > > (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I > > had suggested the following change: > > > > I don't think this is unclear but I could add the following in > > definitions: > > > > Higher Layers > > A client layer is the one immediately above a server layer. The > > client layer and all layers above that layer are higher layers. > > > > Lower Layers > > A server layer is the later immediately below a client laer. > > The server layer and all layers below are lower layers. > > > > Do I really need to put this in the definitions section? If yoy think > > it is necessary, I will add it. > > > > You will find this in the quoted text above. > > > > The definition of client LSP does not imply that Advanced Multipath is > > a layer. This also used lower case "multipath" which we can replace > > with AMG. There is no LAG layer in a network in with MPLS runs over > > Ethernet and some of the Ethernets use Link Aggregation. > > > >> So the model I see defined by the text has the following layers > >> > >> Client LSP (layer) > >> ---------- > >> Advanced Multipath (layer/solution/construct) > >> ---------- > >> Server Layer (composed of AMGs which are LSPs and/or links) > >> > >> Is this aligned with your intent? If not, can you explain the > >> relationship you see for Advanced Multipath Client LSPs and Advanced > >> Multipath AMGs? > > > > You imaginged this model and are trying to constrain the text to fit > > into it.. > > > > Consider these examples of client layer and server layer. > > > > plain old rfc-4206 > > > > LSP-1 (PSC-0) = client of LSP-2 > > LSP-2 (PSC-1) = server of LSP-1 > > > > LSP over Ethernet over PW over MPLS > > > > LSP-1 = client of Ethernet > > Ethernet = server of LSP-1, client of PW > > PW = server of Ethernet, client of LSP-2 > > LSP-2 = server of PW > > > > There is then the question of whether Advanced Multipath is a layer or > > a set of techniques that can be applied at a given layer. Example > > potential config language: > > > > mple { > > tunnel x1 { > > type multipath { > > component tunnel x2; > > component tunnel x3; > > [...] > > component intf i1; > > component intf i2; > > [...] > > } > > [...] > > } > > [...] > > } > > > > No distinct layer above. > > > > An alternate: > > > > mple { > > tunnel x1 { > > [...] > > } > > [...] > > } > > > > interface amg1; > > type multipath { > > component tunnel x2; > > component tunnel x3; > > [...] > > component intf i1; > > component intf i2; > > [...] > > } > > [...] > > } > > [...] > > } > > > > In the former example, the tunnel x1 is forced to use a specific set > > of component links and apply multipath techniques to it. > > > > In the latter example, if tunnel x1 happen to find that interface amg1 > > was the lowest cost or otherwise preferred way to get to its > > destination it makes use of amg1 and if so inherits the use of the > > multipath techniques. > > > > There is no distinct multipath encapsulation at the date layer so some > > might argue that even in the second case there is no distinct layer, > > just a configuration convenience. > > > > Claiming that Advanced Multipath is of itself a layer may get us into > > a bigger can of worms. > > > > For example in today's ECMP, the next hop consists of multiple > > interfaces. ECMP is not considered a layer between IP and those > > interfaces. Link bundle is also not considered a layer. > > > > In the document we have not claimed that Advanced Multipath is a type > > of layer and we have not claimed that Advanced Multipath is not a type > > of layer. Either way we would get someone arguing that the opposite > > was true. [Some individuals it seems would pick the opposite of > > whatever we picked just because they like to argue about layering.] > > > > Need I remind you of the painfully long and mostly pointless arguments > > in MPLS during the early MPLS-TP work about whether an MPLS LSP > > carried within another hierarchical MPLS LSP was a layer or a > > sub-layer. We don't want to repeat that and the best way to do so is > > to not make any statement about whether Advanced Multipath is a layer > > or a sub-layer or a layering NOOP. > > > > Which of the above is the "right" way to do things may be at most a > > framework issue but may not come up until management plane entities > > are defined. It is certainly not a topic for a requirements document > > because it is deep into the "how it gets done". > > > >>>> and > >>>> OLD > >>>> The above set of requirements apply to component links with different > >>>> characteristics regardless as to whether those component links are > >>>> provided by parallel physical links between nodes or provided by sets > >>>> of paths across a network provided by server layer LSP. > >>>> NEW > >>>> The above set of requirements apply to component links with different > >>>> characteristics regardless as to whether those component links are > >>>> provided by parallel physical links between nodes or provided by > >>>> LSPs that are part of an Advanced Multipath Group. > >>> > >>> What about PW? Those are paths too by the definition of paths, so > >>> again, this change makes the definition too narrow. > >>> > >> > >> PWs weren't mentioned in your OLD text, so I didn't add them. I also > >> have no objections to adding them. > > > > Actually the text you wrote is incorrect. "The above requirement > > applies to component links" can include physical links and server > > layer LSP but adding that are part of an Advanced Multipath Group is > > incorrect. > > > > I'm not sure but I think this instance of "server layer" was added to > > that LSP wording because you were confused on last review about client > > LSP vs LSP over which Advanced Multipath was applied so I went around > > changing everything to "client LSP" or "server layer LSP" to make it > > more clear to you. You now seem to be stuck on the wording that is > > essentially saying "any type of component link" including "server > > layer LSP". > > > >> The only change I made was > >> s/sets of paths across a network provided by server layer LSP./ > >> LSPs that are part of an Advanced Multipath Group. > > > > And that change was wrong. A more correct change would be > > > > s/provided by server layer LSP/including paths provided by server > > layer LSP/ > > > > That would include any sort of path across the network. PW could be > > considered an emulated physcial link or another usable type of path > > across the network. > > > > The "above set of requirements" in this case have to do with passing > > down requirements for min latency, bounded latency, and bounded > > jitter. The original paragraph is: > > > > The above set of requirements apply to component links with > > different characteristics regardless as to whether those component > > links are provided by parallel physical links between nodes or > > provided by sets of paths across a network provided by server layer > > LSP. > > > > The intent is "The above set of requirements apply to component links" > > followed by "regardless of what type of component links they are" > > where we had disccssed two types being an interface or emulated > > interface (or virtual interface in some major vendor terms) or an LSP > > (which is also a virtual interface in some major vendor terms). > > > > I don't understand how you can get so hung up on the wording of what > > is intended to convey "regardless of what type of component links they > > are". This has always been clear to the WG. > > > >>>>> The word "indicate" is independent of the method of getting the > >>>>> information there. But yes in the example given the IGP advertisement > >>>>> and MPLS LSP signaling that might be one such mechanism does refer to > >>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > >>>>> > >>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > >>>>> is only one IGP flooding information for both client and server layer, > >>>>> hence the seemingly endless (and mostly pointless) discussion of > >>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list > >>>>> who viewed MPLS as broken for not enforcing a strict layering in this > >>>>> regard. But we need not go into that level of detail in this example > >>>>> of how independent of mechanism the "indicate" is and down that years > >>>>> old MPLS WG terminology rat hole again. > >>>>> > >>>> My comment is that you need to be clear to which layer a requirement > >>>> applies. Is it the server layer, the client layer or the Advanced > >>>> Multipath layer? > >>> > >>> In each of the requirements you cited it is very clear that the client > >>> later is communicating a requirement to the server layer, but if you'd > >>> like I can reword to make that even more clear by rewording of the > >>> form "SHALL provide a means for the client layer to indicate the > >>> requirements of a client LSP [regarding X]", where X is minimize > >>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > >>> component link (FR#13), bidirection co-routed (FR#14), no reordering > >>> (FR#15), bounded frequency of rebalance (FR#20). > >> > >> Okay, I think this will/may help. My comment goes back to the model I > >> was asking about above. And to which part of the puzzle the requirement > >> applies. > > > > In some of the above requirements client layer communicated to the > > server layer, whatever the server layer is. Means of communication > > presumed to be RSVP-TE but we can't say that until the framework and > > same capability needs to be available to management plane. > > > > In some of the above requirements server layer communicates to the > > client layer. Means of communication is presumed to be IGP > > extensions, again with same capability available to management plane. > > > > There is no distinct Advanced Multipath layer in control plane or data > > plane. And if there was a distinct control plane layer it would be > > defined in a framework, not a requirements document. > > > >>>>>>> It would be trivial to make this FR#1 and renumber the rest. > >>>>>>> > >>>>>> > >>>>>> I don't think the FR helped clarify the above question. > >>>>> > >>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not > >>>>> imply usage by a specific layer. That is a direct answer to your > >>>>> question. > >>>>> > >>>>> In all of these specific cases, the the client layer is passing a > >>>>> requirement to the server layer so in the IGP + RSVP-TE world that > >>>>> would be a function of RSVP-TE. In the absense of control plane, it > >>>>> would have to be done through management plane interaction where the > >>>>> client indicates requirements of an LSP and the server layer is free > >>>>> to figure out how to meet those requirements. > >>>>> > >>>>> Do you want me to add the clarification on the use of the word > >>>>> "indicate" or not? > >>>> > >>>> I think you need to be clear that the requirement applies to all three > >>>> layers. > >>> > >>> There are no distinct three layers. You are imagining a model that is > >>> not used in this document so please don't impose model on our document. > >>> > >> > >> Well your old definition of Client LSP said that it was a client of > >> "multipath" and else where you say that "multipath" operates over a > >> server layer. As mentioned above, this sounds like three layers to me. > >> If this is not your intent, I think you need to make it clear (through > >> revised text) what model you do intend. > > > > This is the current text in -13: > > > > Client LSP > > A client LSP is an LSP which has been set up over a server layer. > > In the context of this discussion, a client LSP is a LSP which > > has been set up over a multipath as opposed to an LSP > > representing the multipath itself or any LSP supporting a > > component links of that multipath. > > > > The text is trying to clarify what a "client LSP" is in the first > > sentence and then trying to give two cases of what a client LSP is > > not. This clarification was specifically added *for you* in the last > > iteration. > > > > There was no intention to imply that Advanced Multipath is or is not > > in of itself a type of layer. If you are getting that notion from > > this text, then we need to change it. > > > > OLD: > > > > Client LSP > > A client LSP is an LSP which has been set up over a server layer. > > In the context of this discussion, a client LSP is a LSP which > > has been set up over a multipath as opposed to an LSP > > representing the multipath itself or any LSP supporting a > > component links of that multipath. > > > > NEW: > > > > Client LSP > > > > A client LSP is an LSP which has been set up over a set of one > > or more lower layers. In the context of this discussion, one > > type of client LSP is a LSP which has been set up over an AMG. > > > > We could also add a clarification to the definitions section that > > states: > > > > This document makes no statement on whether Advanced Multipath is > > itself a layer or whether an instance of AMG is itself a layer. > > This is to avoid engaging in long and pointless discussions about > > what consistitutes a proper layer. > > > > I would *really* like to add the above statement. > > > >>> In your sentence above I have no idea what "the requirement" refers to. > >>> > >>> In summary: > >>> > >>> We were discussing why the word "indicate" was used to avoid requiring > >>> specific mechanisms for information passing and I asked if I should > >>> add the following. > >>> > >>> FR#0 In requirements that follow in this document the word > >>> "indicate" is used where information may be provided by either > >>> the combination of link state IGP advertisement and MPLS LSP > >>> signaling or via management plane protocols. In later documents > >>> providing framework and protocol definitions both signaling and > >>> management plane mechanisms MUST be defined. > >>> > >>> Information is two way. The requirements you cited were all worded in > >>> the form "The solution SHALL provide a means to indicate that a client > >>> LSP will ...". So far I have offerred to reword this to the form "The > >>> solution SHALL provide a means for the client layer to indicate a > >>> requirement that a client LSP will ..." (ie: get minimum latency, get > >>> bound latency, etc). > >>> > >>> Is adding FR#0 OK? > >>> > >>> Do you want this sort of rewording to make it more explicit that the > >>> client layer is communication a requirement for a specific client LSP? > >>> > >> > >> I think we need to come back to this once we resolve the "model" topic. > >> > >> ... > >> > >> Thanks, > >> Lou > > > > I hope it is resolved. > > > > Curtis From lberger@labn.net Fri Jan 17 10:01:52 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E52D1A16F0 for ; Fri, 17 Jan 2014 10:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLfngp9Wc7bE for ; Fri, 17 Jan 2014 10:01:49 -0800 (PST) Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 5E1A61ADF5E for ; Fri, 17 Jan 2014 10:01:49 -0800 (PST) Received: (qmail 22138 invoked by uid 0); 18 Jan 2014 01:01:34 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 18 Jan 2014 01:01:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=bhaNjsj70kZ0NGIA25t8OOVu+0dOk72/AYTaC9/EvUg=; b=egvK/QZeHDtBZI4TYDnPkcSDm7uzlJhETUhedtfQPCnCdZioSm0j9IBJ/xlvw8AaFsAS6OqW/xIxszyn95vF108k87CBXp5FOVZsLp1WTwixpR4sDe4o8RcmQU2Qqxuu; Received: from box313.bluehost.com ([69.89.31.113]:52546 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W4Djc-0005YA-Fv; Fri, 17 Jan 2014 11:01:36 -0700 Message-ID: <52D96FFD.1020408@labn.net> Date: Fri, 17 Jan 2014 13:01:33 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401171741.s0HHf6sb063221@maildrop2.v6ds.occnc.com> In-Reply-To: <201401171741.s0HHf6sb063221@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2014 18:01:52 -0000 sounds like a plan! Lou On 01/17/2014 12:41 PM, Curtis Villamizar wrote: > In message <52D88F77.5020009@labn.net> > Lou Berger writes: > >> Curtis, >> I'm not sure if we're going around in circles or not, but in either >> case case I think we're getting caught up in the weeds/details. >> >> >From a high level perspective, my comments have been motivated by trying >> to ensure the requirements are unambiguous -- as documented. I think >> the text changes that have been agreed to so far (notably the use of the >> capitalized term and introduction of AMG) will help a lot. I think there >> is still one more area that is unclear, but it's also possible that >> we're arguing about text that you are planning to change. >> >> Do you have a version that captures all the changes to date that you can >> distribute (or submit, as you choose)? Perhaps looking at this version >> we'll find that the ambiguity is resolved or is sufficiently narrowed to >> not be significant. Either way, the discussion can then continue from >> the most current text. >> >> Thanks, >> Lou > > > Lou, > > I was going to suggest the same (if I understand your suggestion) - > that is that a new draft be submitted and you (and others) can review > and see if clarity has been sufficiently improved or if there are > still issues with clarity. > > If that is OK with you and compatible with this process I will make > two draft submissions back to back. One with just the OpsDir review > comments addressed and a second with your comments so far addressed. > IMHO it would be easier to discuss the clarity (or lack of) of the > wording once changes have been made particularly since there are a few > s/old/new/g terminology suggestions in the email thread. > > Curtis > > >> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: >>> In message <52D02F67.9070604@labn.net> >>> Lou Berger writes: >>> >>>> Curtis, >>>> >>>> I think we have one disconnect (and corresponding related text) that we >>>> need to resolve before we can be close the discussion. See below for >>>> details.. >>>> >>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>>>> Converging. But maybe one more round trip needed. >>>>> >>>>> In message <52CD9D58.4010109@labn.net> >>>>> Lou Berger writes: >>>>>> >>>> ... >>>> >>>>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>>>>>> >>>>>>>>>> The document uses server and client layer networks and LSPs and, >>>>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>>>>>> client/server when referring to network layers and just using the >>>>>>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>>>>>> i.e.: >>>>>>>>>> OLD >>>>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>>>> NEW >>>>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>>>>>> >>>>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>>>>>> over an advanced multipath. >>>>>>>>> >>>>>>>> >>>>>>>> Would you accept s/server layer/lower layer/g? >>>>>>> >>>>>>> The definition of server layer is not the same as the definition of >>>>>>> lower layer. See below. >>>>>>> >>>>>>>>>> I think this also means that usage of the term "Client" is limited to >>>>>>>>>> "Client LSP". >>>>>>>>> >>>>>>>>> I searched for all occurances of the word client. All occurances are >>>>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>>>>>> used only in the following paragraph. >>>>>>>>> >>>>>>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>>>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>>>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>>>>>> general, multipath endpoints cannot determine requirements of clients >>>>>>>>> of a client LSP through participation in the signaling of the clients >>>>>>>>> of the client LSP. >>>>>>>>> >>>>>>>>> THe point is that "A midpoint LSR does not participate in the >>>>>>>>> signaling of any clients of the client LSP" and that non-participation >>>>>>>>> in client (or higher layer) signaling applies to any "client of a >>>>>>>>> client LSP", not just other LSP running over it. >>>>>>>>> >>>>>>>>> I then searched for all occurances of the words upper and lower and >>>>>>>>> higher. There are no occurances of "upper". >>>>>>>>> >>>>>>>>> There were a few occurances of "lower latency" and "higher latency". >>>>>>>>> Other than that, all occurances of lower and higher except one are in >>>>>>>>> the follwoing text: >>>>>>>>> >>>>>>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>>>>>> >>>>>>>>> A component link may be supported by a lower layer network. For >>>>>>>>> example, the lower layer may be a circuit switched network or another >>>>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>>>>>> the latency (and/or other performance parameters) seen by the client >>>>>>>>> layer. Currently, there is no protocol for the lower layer network >>>>>>>>> to inform the higher layer network of a change in a performance >>>>>>>>> parameter. Communication of the latency performance parameter is a >>>>>>>>> very important requirement. Communication of other performance >>>>>>>>> parameters (e.g., delay variation) is desirable. >>>>>>>>> >>>>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>>>>>> layer server network to communicate latency to the higher layer >>>>>>>>> client network. >>>>>>>>> >>>>>>>>> The exception is this sentence: >>>>>>>>> >>>>>>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>>>>>> multipath itself is a component link for a higher order advanced >>>>>>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>>>>>> TP bi-directional tunnels viewed as logical links could then be >>>>>>>>> used as a component link in yet another advanced multipath that >>>>>>>>> connects MPLS routers. >>>>>>>>> >>>>>>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>>>>>> back but that is before even my time. >>>>>>>>> >>>>>>>>> I don't think this is unclear but I could add the following in >>>>>>>>> definitions: >>>>>>>>> >>>>>>>>> Higher Layers >>>>>>>>> A client layer is the one immediately above a server layer. The >>>>>>>>> client layer and all layers above that layer are higher layers. >>>>>>>>> >>>>>>>>> Lower Layers >>>>>>>>> A server layer is the later immediately below a client laer. >>>>>>>>> The server layer and all layers below are lower layers. >>>>>>>>> >>>>>>>>> Do I really need to put this in the definitions section? If yoy think >>>>>>>>> it is necessary, I will add it. >>>>>>>>> >>>>>>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>>>>>> And to use it (consistently) in place of "client and server Layer". >>>>>>> >>>>>>> I guess you missed the distinction in the definition above: >>>>>>> >>>>>>> For layer X layer Y is: >>>>>>> >>>>>>> client layer === Y = X+1 >>>>>>> server layer === Y = X-1 >>>>>>> higher layer === Y > X >>>>>>> lower layer === Y < X >>>>>>> >>>>>>> So the definition client layer is not the same as the definition of >>>>>>> higher layer. The definition of server layer is not the same as the >>>>>>> definition of lower layer. >>>>>>> >>>>>>> In some discussions we really do mean "the server layer" and not any >>>>>>> layer at any arbitrary depth below this one. >>>>>> >>>>>> I read your usage of client/server layer to be synonymous with >>>>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >>>>>> of FR#8 (I think you really mean client layer not lower layer.) >>>>> >>>>> FR#8 and FR#9 are about the server layer telling the client layer >>>>> about the delays that can be expected. There is a little redundancy >>>>> here so s/ower layer server network/server network/ and >>>>> s/higher layer client network/client network/. No plans to skip >>>>> layers. >>>>> >>>> >>>> I think we need to hit the points below before this one... >>> >>> OK. >>> >>>>>> Given the current document usage, I still think it makes sense to >>>>>> eliminate the two instances of "client layer": How about the following: >>>>>> OLD >>>>>> Client LSP >>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>> In the context of this discussion, a client LSP is a LSP which >>>>>> has been set up over a multipath as opposed to an LSP >>>>>> representing the multipath itself or any LSP supporting a >>>>>> component links of that multipath. >>>>>> NEW >>>>>> Client LSP >>>>>> A client LSP is a LSP which >>>>>> has been set up over Advanced Multipath as opposed to an LSP >>>>>> representing the Advanced Multipath itself or any LSP that is >>>>>> part of an Advanced Multipath Group. >>>>> >>>>> Nope. In general, a client LSP can be set up over a plain old >>>>> Ethernet on a given hop, therefore the second definition is too >>>>> narrow with this change. >>>>> >>>> >>>> humm, you didn't have that in your OLD text. In fact, the old text >>>> reads to me that an Advanced Multipath (solution?) logically sits >>>> between a client LSP and an underlying server layer in all cases. >>> >>> The "OLD" was a quote from you and it was the original text in -13. I >>> said "Nope. ..." to your suggested change to it in this way. >>> >>> Earlier >>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I >>> had suggested the following change: >>> >>> I don't think this is unclear but I could add the following in >>> definitions: >>> >>> Higher Layers >>> A client layer is the one immediately above a server layer. The >>> client layer and all layers above that layer are higher layers. >>> >>> Lower Layers >>> A server layer is the later immediately below a client laer. >>> The server layer and all layers below are lower layers. >>> >>> Do I really need to put this in the definitions section? If yoy think >>> it is necessary, I will add it. >>> >>> You will find this in the quoted text above. >>> >>> The definition of client LSP does not imply that Advanced Multipath is >>> a layer. This also used lower case "multipath" which we can replace >>> with AMG. There is no LAG layer in a network in with MPLS runs over >>> Ethernet and some of the Ethernets use Link Aggregation. >>> >>>> So the model I see defined by the text has the following layers >>>> >>>> Client LSP (layer) >>>> ---------- >>>> Advanced Multipath (layer/solution/construct) >>>> ---------- >>>> Server Layer (composed of AMGs which are LSPs and/or links) >>>> >>>> Is this aligned with your intent? If not, can you explain the >>>> relationship you see for Advanced Multipath Client LSPs and Advanced >>>> Multipath AMGs? >>> >>> You imaginged this model and are trying to constrain the text to fit >>> into it.. >>> >>> Consider these examples of client layer and server layer. >>> >>> plain old rfc-4206 >>> >>> LSP-1 (PSC-0) = client of LSP-2 >>> LSP-2 (PSC-1) = server of LSP-1 >>> >>> LSP over Ethernet over PW over MPLS >>> >>> LSP-1 = client of Ethernet >>> Ethernet = server of LSP-1, client of PW >>> PW = server of Ethernet, client of LSP-2 >>> LSP-2 = server of PW >>> >>> There is then the question of whether Advanced Multipath is a layer or >>> a set of techniques that can be applied at a given layer. Example >>> potential config language: >>> >>> mple { >>> tunnel x1 { >>> type multipath { >>> component tunnel x2; >>> component tunnel x3; >>> [...] >>> component intf i1; >>> component intf i2; >>> [...] >>> } >>> [...] >>> } >>> [...] >>> } >>> >>> No distinct layer above. >>> >>> An alternate: >>> >>> mple { >>> tunnel x1 { >>> [...] >>> } >>> [...] >>> } >>> >>> interface amg1; >>> type multipath { >>> component tunnel x2; >>> component tunnel x3; >>> [...] >>> component intf i1; >>> component intf i2; >>> [...] >>> } >>> [...] >>> } >>> [...] >>> } >>> >>> In the former example, the tunnel x1 is forced to use a specific set >>> of component links and apply multipath techniques to it. >>> >>> In the latter example, if tunnel x1 happen to find that interface amg1 >>> was the lowest cost or otherwise preferred way to get to its >>> destination it makes use of amg1 and if so inherits the use of the >>> multipath techniques. >>> >>> There is no distinct multipath encapsulation at the date layer so some >>> might argue that even in the second case there is no distinct layer, >>> just a configuration convenience. >>> >>> Claiming that Advanced Multipath is of itself a layer may get us into >>> a bigger can of worms. >>> >>> For example in today's ECMP, the next hop consists of multiple >>> interfaces. ECMP is not considered a layer between IP and those >>> interfaces. Link bundle is also not considered a layer. >>> >>> In the document we have not claimed that Advanced Multipath is a type >>> of layer and we have not claimed that Advanced Multipath is not a type >>> of layer. Either way we would get someone arguing that the opposite >>> was true. [Some individuals it seems would pick the opposite of >>> whatever we picked just because they like to argue about layering.] >>> >>> Need I remind you of the painfully long and mostly pointless arguments >>> in MPLS during the early MPLS-TP work about whether an MPLS LSP >>> carried within another hierarchical MPLS LSP was a layer or a >>> sub-layer. We don't want to repeat that and the best way to do so is >>> to not make any statement about whether Advanced Multipath is a layer >>> or a sub-layer or a layering NOOP. >>> >>> Which of the above is the "right" way to do things may be at most a >>> framework issue but may not come up until management plane entities >>> are defined. It is certainly not a topic for a requirements document >>> because it is deep into the "how it gets done". >>> >>>>>> and >>>>>> OLD >>>>>> The above set of requirements apply to component links with different >>>>>> characteristics regardless as to whether those component links are >>>>>> provided by parallel physical links between nodes or provided by sets >>>>>> of paths across a network provided by server layer LSP. >>>>>> NEW >>>>>> The above set of requirements apply to component links with different >>>>>> characteristics regardless as to whether those component links are >>>>>> provided by parallel physical links between nodes or provided by >>>>>> LSPs that are part of an Advanced Multipath Group. >>>>> >>>>> What about PW? Those are paths too by the definition of paths, so >>>>> again, this change makes the definition too narrow. >>>>> >>>> >>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also >>>> have no objections to adding them. >>> >>> Actually the text you wrote is incorrect. "The above requirement >>> applies to component links" can include physical links and server >>> layer LSP but adding that are part of an Advanced Multipath Group is >>> incorrect. >>> >>> I'm not sure but I think this instance of "server layer" was added to >>> that LSP wording because you were confused on last review about client >>> LSP vs LSP over which Advanced Multipath was applied so I went around >>> changing everything to "client LSP" or "server layer LSP" to make it >>> more clear to you. You now seem to be stuck on the wording that is >>> essentially saying "any type of component link" including "server >>> layer LSP". >>> >>>> The only change I made was >>>> s/sets of paths across a network provided by server layer LSP./ >>>> LSPs that are part of an Advanced Multipath Group. >>> >>> And that change was wrong. A more correct change would be >>> >>> s/provided by server layer LSP/including paths provided by server >>> layer LSP/ >>> >>> That would include any sort of path across the network. PW could be >>> considered an emulated physcial link or another usable type of path >>> across the network. >>> >>> The "above set of requirements" in this case have to do with passing >>> down requirements for min latency, bounded latency, and bounded >>> jitter. The original paragraph is: >>> >>> The above set of requirements apply to component links with >>> different characteristics regardless as to whether those component >>> links are provided by parallel physical links between nodes or >>> provided by sets of paths across a network provided by server layer >>> LSP. >>> >>> The intent is "The above set of requirements apply to component links" >>> followed by "regardless of what type of component links they are" >>> where we had disccssed two types being an interface or emulated >>> interface (or virtual interface in some major vendor terms) or an LSP >>> (which is also a virtual interface in some major vendor terms). >>> >>> I don't understand how you can get so hung up on the wording of what >>> is intended to convey "regardless of what type of component links they >>> are". This has always been clear to the WG. >>> >>>>>>> The word "indicate" is independent of the method of getting the >>>>>>> information there. But yes in the example given the IGP advertisement >>>>>>> and MPLS LSP signaling that might be one such mechanism does refer to >>>>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>>>>>> >>>>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>>>>>> is only one IGP flooding information for both client and server layer, >>>>>>> hence the seemingly endless (and mostly pointless) discussion of >>>>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>>>>>> who viewed MPLS as broken for not enforcing a strict layering in this >>>>>>> regard. But we need not go into that level of detail in this example >>>>>>> of how independent of mechanism the "indicate" is and down that years >>>>>>> old MPLS WG terminology rat hole again. >>>>>>> >>>>>> My comment is that you need to be clear to which layer a requirement >>>>>> applies. Is it the server layer, the client layer or the Advanced >>>>>> Multipath layer? >>>>> >>>>> In each of the requirements you cited it is very clear that the client >>>>> later is communicating a requirement to the server layer, but if you'd >>>>> like I can reword to make that even more clear by rewording of the >>>>> form "SHALL provide a means for the client layer to indicate the >>>>> requirements of a client LSP [regarding X]", where X is minimize >>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>>>> (FR#15), bounded frequency of rebalance (FR#20). >>>> >>>> Okay, I think this will/may help. My comment goes back to the model I >>>> was asking about above. And to which part of the puzzle the requirement >>>> applies. >>> >>> In some of the above requirements client layer communicated to the >>> server layer, whatever the server layer is. Means of communication >>> presumed to be RSVP-TE but we can't say that until the framework and >>> same capability needs to be available to management plane. >>> >>> In some of the above requirements server layer communicates to the >>> client layer. Means of communication is presumed to be IGP >>> extensions, again with same capability available to management plane. >>> >>> There is no distinct Advanced Multipath layer in control plane or data >>> plane. And if there was a distinct control plane layer it would be >>> defined in a framework, not a requirements document. >>> >>>>>>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>>>>>> >>>>>>>> >>>>>>>> I don't think the FR helped clarify the above question. >>>>>>> >>>>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>>>>>> imply usage by a specific layer. That is a direct answer to your >>>>>>> question. >>>>>>> >>>>>>> In all of these specific cases, the the client layer is passing a >>>>>>> requirement to the server layer so in the IGP + RSVP-TE world that >>>>>>> would be a function of RSVP-TE. In the absense of control plane, it >>>>>>> would have to be done through management plane interaction where the >>>>>>> client indicates requirements of an LSP and the server layer is free >>>>>>> to figure out how to meet those requirements. >>>>>>> >>>>>>> Do you want me to add the clarification on the use of the word >>>>>>> "indicate" or not? >>>>>> >>>>>> I think you need to be clear that the requirement applies to all three >>>>>> layers. >>>>> >>>>> There are no distinct three layers. You are imagining a model that is >>>>> not used in this document so please don't impose model on our document. >>>>> >>>> >>>> Well your old definition of Client LSP said that it was a client of >>>> "multipath" and else where you say that "multipath" operates over a >>>> server layer. As mentioned above, this sounds like three layers to me. >>>> If this is not your intent, I think you need to make it clear (through >>>> revised text) what model you do intend. >>> >>> This is the current text in -13: >>> >>> Client LSP >>> A client LSP is an LSP which has been set up over a server layer. >>> In the context of this discussion, a client LSP is a LSP which >>> has been set up over a multipath as opposed to an LSP >>> representing the multipath itself or any LSP supporting a >>> component links of that multipath. >>> >>> The text is trying to clarify what a "client LSP" is in the first >>> sentence and then trying to give two cases of what a client LSP is >>> not. This clarification was specifically added *for you* in the last >>> iteration. >>> >>> There was no intention to imply that Advanced Multipath is or is not >>> in of itself a type of layer. If you are getting that notion from >>> this text, then we need to change it. >>> >>> OLD: >>> >>> Client LSP >>> A client LSP is an LSP which has been set up over a server layer. >>> In the context of this discussion, a client LSP is a LSP which >>> has been set up over a multipath as opposed to an LSP >>> representing the multipath itself or any LSP supporting a >>> component links of that multipath. >>> >>> NEW: >>> >>> Client LSP >>> >>> A client LSP is an LSP which has been set up over a set of one >>> or more lower layers. In the context of this discussion, one >>> type of client LSP is a LSP which has been set up over an AMG. >>> >>> We could also add a clarification to the definitions section that >>> states: >>> >>> This document makes no statement on whether Advanced Multipath is >>> itself a layer or whether an instance of AMG is itself a layer. >>> This is to avoid engaging in long and pointless discussions about >>> what consistitutes a proper layer. >>> >>> I would *really* like to add the above statement. >>> >>>>> In your sentence above I have no idea what "the requirement" refers to. >>>>> >>>>> In summary: >>>>> >>>>> We were discussing why the word "indicate" was used to avoid requiring >>>>> specific mechanisms for information passing and I asked if I should >>>>> add the following. >>>>> >>>>> FR#0 In requirements that follow in this document the word >>>>> "indicate" is used where information may be provided by either >>>>> the combination of link state IGP advertisement and MPLS LSP >>>>> signaling or via management plane protocols. In later documents >>>>> providing framework and protocol definitions both signaling and >>>>> management plane mechanisms MUST be defined. >>>>> >>>>> Information is two way. The requirements you cited were all worded in >>>>> the form "The solution SHALL provide a means to indicate that a client >>>>> LSP will ...". So far I have offerred to reword this to the form "The >>>>> solution SHALL provide a means for the client layer to indicate a >>>>> requirement that a client LSP will ..." (ie: get minimum latency, get >>>>> bound latency, etc). >>>>> >>>>> Is adding FR#0 OK? >>>>> >>>>> Do you want this sort of rewording to make it more explicit that the >>>>> client layer is communication a requirement for a specific client LSP? >>>>> >>>> >>>> I think we need to come back to this once we resolve the "model" topic. >>>> >>>> ... >>>> >>>> Thanks, >>>> Lou >>> >>> I hope it is resolved. >>> >>> Curtis > From rcallon@juniper.net Mon Jan 20 12:54:19 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7994A1A0258; Mon, 20 Jan 2014 12:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCxBzuLI6C4i; Mon, 20 Jan 2014 12:54:17 -0800 (PST) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id BEBB31A0254; Mon, 20 Jan 2014 12:54:16 -0800 (PST) Received: from mail104-db9-R.bigfish.com (10.174.16.230) by DB9EHSOBE031.bigfish.com (10.174.14.94) with Microsoft SMTP Server id 14.1.225.22; Mon, 20 Jan 2014 20:54:16 +0000 Received: from mail104-db9 (localhost [127.0.0.1]) by mail104-db9-R.bigfish.com (Postfix) with ESMTP id 5DB8E802A1; Mon, 20 Jan 2014 20:54:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz103dKc857hdbf2izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1033IL17326ah8275dh18c673h1de097h186068h1d68dehz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h9a9j1155h) Received-SPF: pass (mail104-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=rcallon@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(41574002)(189002)(199002)(31966008)(15202345003)(87936001)(90146001)(47446002)(4396001)(81686001)(69226001)(76576001)(74876001)(19273905006)(74366001)(93516002)(83072002)(74502001)(81342001)(85852003)(74706001)(80022001)(74662001)(56816005)(86362001)(15975445006)(76482001)(74316001)(87266001)(65816001)(47976001)(85306002)(76786001)(2656002)(66066001)(77982001)(54316002)(83322001)(51856001)(80976001)(53806001)(63696002)(79102001)(47736001)(54356001)(50986001)(49866001)(46102001)(19580395003)(76796001)(92566001)(76176001)(59766001)(56776001)(81542001)(93136001)(33646001)(575784001)(81816001)(24736002)(563064011); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB636; H:CO2PR05MB636.namprd05.prod.outlook.com; CLIP:66.129.241.14; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail104-db9 (localhost.localdomain [127.0.0.1]) by mail104-db9 (MessageSwitch) id 1390251253441523_31652; Mon, 20 Jan 2014 20:54:13 +0000 (UTC) Received: from DB9EHSMHS003.bigfish.com (unknown [10.174.16.239]) by mail104-db9.bigfish.com (Postfix) with ESMTP id 5C867380047; Mon, 20 Jan 2014 20:54:13 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS003.bigfish.com (10.174.14.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 20 Jan 2014 20:54:13 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.395.1; Mon, 20 Jan 2014 20:54:11 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) by CO2PR05MB636.namprd05.prod.outlook.com (10.141.199.24) with Microsoft SMTP Server (TLS) id 15.0.851.15; Mon, 20 Jan 2014 20:54:09 +0000 Received: from CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) by CO2PR05MB636.namprd05.prod.outlook.com ([10.141.199.24]) with mapi id 15.00.0851.011; Mon, 20 Jan 2014 20:54:09 +0000 From: Ross Callon To: "rtg-ads@tools.ietf.org" Thread-Topic: RtgDir review: draft-ietf-isis-rfc6326bis-01.txt Thread-Index: Ac8WIcK8h2AG2X6JRH6T7bYg8PNnEw== Date: Mon, 20 Jan 2014 20:54:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.14] x-forefront-prvs: 00979FCB3A Content-Type: multipart/alternative; boundary="_000_da56aac4f129444d926775a97a9aa51fCO2PR05MB636namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "rtg-dir@ietf.org" , "draft-ietf-isis-rfc6326bis@tools.ietf.org" , "trill@ietf.org" Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-rfc6326bis-01.txt X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2014 20:54:19 -0000 --_000_da56aac4f129444d926775a97a9aa51fCO2PR05MB636namprd05pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgaGF2ZSBiZWVuIHNlbGVjdGVkIGFzIHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl IHJldmlld2VyIGZvciB0aGlzIGRyYWZ0LiBUaGUgUm91dGluZyBEaXJlY3RvcmF0ZSBzZWVrcyB0 byByZXZpZXcgYWxsIHJvdXRpbmcgb3Igcm91dGluZy1yZWxhdGVkIGRyYWZ0cyBhcyB0aGV5IHBh c3MgdGhyb3VnaCBJRVRGIGxhc3QgY2FsbCBhbmQgSUVTRyByZXZpZXcsIGFuZCBzb21ldGltZXMg b24gc3BlY2lhbCByZXF1ZXN0LiBUaGUgcHVycG9zZSBvZiB0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0aW5nLmh0bWwNCg0KQWx0aG91Z2ggdGhlc2UgY29tbWVu dHMgYXJlIHByaW1hcmlseSBmb3IgdGhlIHVzZSBvZiB0aGUgUm91dGluZyBBRHMsIGl0IHdvdWxk IGJlIGhlbHBmdWwgaWYgeW91IGNvdWxkIGNvbnNpZGVyIHRoZW0gYWxvbmcgd2l0aCBhbnkgb3Ro ZXIgSUVURiBMYXN0IENhbGwgY29tbWVudHMgdGhhdCB5b3UgcmVjZWl2ZSwgYW5kIHN0cml2ZSB0 byByZXNvbHZlIHRoZW0gdGhyb3VnaCBkaXNjdXNzaW9uIG9yIGJ5IHVwZGF0aW5nIHRoZSBkcmFm dC4NCg0KRG9jdW1lbnQ6IGRyYWZ0LWlldGYtaXNpcy1yZmM2MzI2YmlzLTAxLnR4dA0KUmV2aWV3 ZXI6IFJvc3MgQ2FsbG9uDQpSZXZpZXcgRGF0ZTogSmFudWFyeSAyMCwgMjAxNA0KSUVURiBMQyBF bmQgRGF0ZTogSmFudWFyeSAyMiwgMjAxNA0KSW50ZW5kZWQgU3RhdHVzOiBQcm9wb3NlZCBTdGFu ZGFyZA0KDQpTdW1tYXJ5OiAgIE5vIGlzc3VlcyBmb3VuZC4gVGhpcyBkb2N1bWVudCBpcyByZWFk eSBmb3IgcHVibGljYXRpb24uDQoNCkNvbW1lbnRzOiAgVGhlIGRvY3VtZW50IGlzIHZlcnkgd2Vs bCB3cml0dGVuIGFuZCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uIFRoYW5rcyENCg0KTWFqb3Ig SXNzdWVzOiAgTm8gbWFqb3IgaXNzdWVzIGZvdW5kLg0KDQpNaW5vciBJc3N1ZXM6ICBObyBtaW5v ciBpc3N1ZXMgZm91bmQuDQoNCk5pdHM6DQoNClByb2JhYmx5IHRoZSByZWZlcmVuY2UgdG8gUkZD IDUzNDIgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5IGEgcmVmZXJlbmNlIHRvIDcwNDIgKHdoaWNoIG9i c29sZXRlcyA1MzQyKS4NCg0K --_000_da56aac4f129444d926775a97a9aa51fCO2PR05MB636namprd05pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+SGVsbG8sIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUg cmV2aWV3ZXIgZm9yIHRoaXMgZHJhZnQuIFRoZSBSb3V0aW5nIERpcmVjdG9yYXRlIHNlZWtzIHRv IHJldmlldyBhbGwgcm91dGluZyBvciByb3V0aW5nLXJlbGF0ZWQgZHJhZnRzIGFzIHRoZXkgcGFz cyB0aHJvdWdoIElFVEYgbGFzdCBjYWxsIGFuZCBJRVNHIHJldmlldywgYW5kIHNvbWV0aW1lcyBv biBzcGVjaWFsIHJlcXVlc3QuIFRoZSBwdXJwb3NlIG9mDQp0aGUgcmV2aWV3IGlzIHRvIHByb3Zp ZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBBRHMuIEZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRlLCBwbGVhc2Ugc2VlDQo8YSBocmVmPSJodHRwOi8v d3d3LmlldGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1sIj5odHRwOi8vd3d3Lmll dGYub3JnL2llc2cvZGlyZWN0b3JhdGUvcm91dGluZy5odG1sPC9hPiA8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PkFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBj b3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdCBDYWxsIGNv bW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVtIHRocm91 Z2ggZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PkRvY3VtZW50OiBkcmFmdC1pZXRmLWlzaXMtcmZjNjMyNmJpcy0wMS50 eHQgPC9kaXY+DQo8ZGl2PlJldmlld2VyOiBSb3NzIENhbGxvbjwvZGl2Pg0KPGRpdj5SZXZpZXcg RGF0ZTogSmFudWFyeSAyMCwgMjAxNCA8L2Rpdj4NCjxkaXY+SUVURiBMQyBFbmQgRGF0ZTogSmFu dWFyeSAyMiwgMjAxNDwvZGl2Pg0KPGRpdj5JbnRlbmRlZCBTdGF0dXM6IFByb3Bvc2VkIFN0YW5k YXJkPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TdW1tYXJ5OiZuYnNwOyZuYnNwOyBO byBpc3N1ZXMgZm91bmQuIFRoaXMgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Q29tbWVudHM6Jm5ic3A7IFRoZSBkb2N1bWVu dCBpcyB2ZXJ5IHdlbGwgd3JpdHRlbiBhbmQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLiBUaGFu a3MhPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5NYWpvciBJc3N1ZXM6Jm5ic3A7IE5v IG1ham9yIGlzc3VlcyBmb3VuZC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk1pbm9y IElzc3VlczombmJzcDsgTm8gbWlub3IgaXNzdWVzIGZvdW5kLjwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+Tml0czombmJzcDsmbmJzcDsgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj5Qcm9iYWJseSB0aGUgcmVmZXJlbmNlIHRvIFJGQyA1MzQyIHNob3VsZCBiZSByZXBsYWNl ZCBieSBhIHJlZmVyZW5jZSB0byA3MDQyICh3aGljaCBvYnNvbGV0ZXMgNTM0MikuIDwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_da56aac4f129444d926775a97a9aa51fCO2PR05MB636namprd05pro_-- From akatlas@gmail.com Wed Jan 22 15:29:30 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03D71A00C8; Wed, 22 Jan 2014 15:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFC9yr8s7AZ1; Wed, 22 Jan 2014 15:29:27 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id D6DFC1A0256; Wed, 22 Jan 2014 15:29:26 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id j1so3162319iga.2 for ; Wed, 22 Jan 2014 15:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mwFHlnKWrYuxKhSdhHUbM14rXhZ7hKPmXWECbTfcD7o=; b=te1xCuRh826rCnDJ9rvFEqN6kSrOHWFMxEzxuIZPWffRD5eicgnC7uen++oXlVKRIg V0hs4NcvLX6ykokG/uYXFETr3xLel6h8Ua2fe/5k96PbxCB+c6vwGXeNphB1Lp15FC6Y ox5vYQLJIxNkODBNCR+sRsSRQNH3ksA+BNWYoItN0NlcUghxtlBJL+umvVwf/XKyJ2Rw 0p902uBpdCAcOQXMtXLU7J42x/QQ30OSr838H0nCgQB+IHmS/pQuaesW0kYjfQ7jP1bD VuAt5letWMT9F8QHDpJokXyqx5hVtYeVn9BeNCV/kyh4/JM3sZO+xvXLD6teTSmpoNQc 9LTA== MIME-Version: 1.0 X-Received: by 10.43.56.4 with SMTP id wa4mr3522148icb.18.1390433366151; Wed, 22 Jan 2014 15:29:26 -0800 (PST) Received: by 10.64.72.132 with HTTP; Wed, 22 Jan 2014 15:29:26 -0800 (PST) Date: Wed, 22 Jan 2014 18:29:26 -0500 Message-ID: From: Alia Atlas To: "rtg-ads@tools.ietf.org" Content-Type: multipart/alternative; boundary=bcaec517aa5adf9bce04f0977e48 Cc: "rtg-dir@ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org Subject: [RTG-DIR] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2014 23:29:30 -0000 --bcaec517aa5adf9bce04f0977e48 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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. 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-netmod-ip-cfg-12.txt Reviewer: Alia Atlas Review Date: 22 January 2014 IETF LC End Date: 23 January 2014 Intended Status: Proposed Standard *Summary:* I have a few minor concerns about this document (clarifying a few aspects) that I think should be resolved before publication. *Comments:* This document is very clearly written, but I did find a few details that could use a bit more clarity. I was able to figure out what was intended by wandering through the referenced RFCs. *Major Issues:* No major issues found. *Minor Issues:* 1. ipv4/forwarding and ipv6/forwarding: First, I wasn't sure what this meant or how it was different from ipv4/enable or ipv6/enable. I went back to look at RFC 4293 to learn that ipv4/forwarding means =93acting a= s a router and forwarding traffic not destined to the device=94. Could you clarify the text to add those key details into the description for ipv4/forwarding and ipv6/forwarding? Second, I was surprised that the default is false; I think about this from the router perspective, of course, but a bit of explanation as to why that decision was made would = be useful. 2. ipv4/enabled and ipv6/enabled: Similarly, what is enabled by ipv4/enabled isn=92t clear (unless I look at RFC 4293). Could you clar= ify that it means connected to an IPv4 stack for sending out IPv4 packets an= d for receiving to-me packets and do the same clarification for ipv6/enabl= ed? 3. ipv4/mtu and ipv6/mtu: This is discussing sending and receiving packets =96 a mention of the MRU would be useful and even quoting RFC24= 60 in Sec 5 which says =93From each link to which a node is directly attached, the node must be able to accept packets as large as that link's MTU. = =93 so it=92s clear. 4. For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is there a reason that lastUpdated isn=92t included? This doesn=92t seem t= o provide quite enough information to see whenr mappings were last updated= ? Is the assumption that there will be a ARP specific and ND specific YANG model for getting the details? *Nits:* I've put these as nits because I think that they are probably textual errors rather than intentional... 1. ipv6/forwarding: why is the reference RFC 4861 =96 neighbor discovery??? That seems like it applies to the neighbor info, unless I= =92ve misunderstood what ipv6/forwarding is doing=85 2. In the second table in Sec 3, ipv4/neighbor/interface and ipv6/neighbor/interface are listed, but I don=92t see them in state tree= in Sec 2. I think that=92s because they aren=92t necessary?? Regards, Alia --bcaec517aa5adf9bce04f0977e48 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello,

I have been se= lected as the Routing Directorate reviewer for this draft. The Routing Dire= ctorate seeks to review all routing or routing-related drafts as they pass = through IETF last call and IESG review. The purpose of the review is to pro= vide 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 R= outing ADs, it would be helpful if you could consider them along with any o= ther IETF Last Call comments that you receive, and strive to resolve them t= hrough discussion or by updating the draft.

Document: draft-ietf-netmod-ip-cfg-12.txt=A0
Reviewer: = Alia Atlas
Review Date: 22 January 2014=A0
IETF LC End Date: 23 Janua= ry 2014
Intended Status: Proposed Standard

Summary:=A0
I have a few minor concerns about this document (clarifying a f= ew aspects) that I think should be resolved before publication.

Comments:=A0
This document is very cle= arly written, but I did find a few details that could use a bit more clarit= y. =A0I was able to figure out what was intended by wandering through the r= eferenced RFCs.

Major Issues:=A0
No major issues found= .

Minor Issues:=A0

  1. ipv4/forwarding and ipv6/fo= rwarding: =A0First, I wasn't sure what this meant or how it was differe= nt from ipv4/enable or ipv6/enable. =A0=A0I went back to= look at RFC 4293 to learn that ipv4/forwarding means =93acting as a router= and forwarding traffic not destined to the device=94.=A0 Could you clarify= the text to add those key details into the description for ipv4/forwarding= and ipv6/forwarding? =A0Second, I was surprised that the default is false;= I think about this from the router perspective, of course, but a bit of ex= planation as to why that decision was made would be useful. =A0
  2. ipv4/enabled and ipv6/enabled: =A0Similarly, what is enable= d by ipv4/enabled isn=92t clear (unless I look at RFC 4293).=A0=A0 Could you clarify that it means connected to an IPv4 stack for sending out IPv4 packets and for receiving to-me packets and do the same clarification = for ipv6/enabled?
  3. ipv4/mtu and ipv6/mtu:=A0 This is discussing sending and re= ceiving packets =96 a mention of the MRU would be useful and even quoting= =A0 RFC2460 in Sec 5 which says =93From each li= nk to which a node is directly attached, the node must be=A0 able to accept= packets as large as that link's MTU. =93 so it=92s clear.=A0
  4. =A0= For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is there a reason that lastUpdated isn=92t included?=A0 Th= is doesn=92t seem to provide quite enough information to see whenr mappings were last updated?=A0 Is the assumption t= hat there will be a ARP specific and ND specific YANG model for getting the details?

    5. Nits:=A0=

    I've put these as nits because I think that they a= re probably textual errors rather than intentional...

    1. =A0ipv6/forwarding:=A0=A0 why is the reference R= FC 4861 =96 neighbor discovery???=A0 That seems like it applies to the neig= hbor info, unless I=92ve misunderstood what ipv6/forwarding is doing=85
    2. I= n the second table in Sec 3, ipv4/neighbor/interface and ipv6/neighbor/interface are listed, but I don=92t see them in state tre= e in Sec 2.=A0 I think that=92s because they aren=92t necessary??
    Regards,
    Alia
--bcaec517aa5adf9bce04f0977e48-- From mbj@tail-f.com Sat Jan 25 06:18:53 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2F761A02D3; Sat, 25 Jan 2014 06:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90PtJhoquivI; Sat, 25 Jan 2014 06:18:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1421A02C2; Sat, 25 Jan 2014 06:18:50 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id BD3A9240C1AF; Sat, 25 Jan 2014 15:18:47 +0100 (CET) Date: Sat, 25 Jan 2014 15:18:47 +0100 (CET) Message-Id: <20140125.151847.09968453.mbj@tail-f.com> To: akatlas@gmail.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: rtg-dir@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 14:18:53 -0000 SGksDQoNCkFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPiB3cm90ZToNCj4gSGVsbG8sDQo+ IA0KPiBJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgUm91dGluZyBEaXJlY3RvcmF0ZSByZXZp ZXdlciBmb3IgdGhpcyBkcmFmdC4NCj4gVGhlIFJvdXRpbmcgRGlyZWN0b3JhdGUgc2Vla3MgdG8g cmV2aWV3IGFsbCByb3V0aW5nIG9yIHJvdXRpbmctcmVsYXRlZA0KPiBkcmFmdHMgYXMgdGhleSBw YXNzIHRocm91Z2ggSUVURiBsYXN0IGNhbGwgYW5kIElFU0cgcmV2aWV3LiBUaGUgcHVycG9zZSBv Zg0KPiB0aGUgcmV2aWV3IGlzIHRvIHByb3ZpZGUgYXNzaXN0YW5jZSB0byB0aGUgUm91dGluZyBB RHMuIEZvciBtb3JlDQo+IGluZm9ybWF0aW9uIGFib3V0IHRoZSBSb3V0aW5nIERpcmVjdG9yYXRl LCBwbGVhc2Ugc2VlDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWVzZy9kaXJlY3RvcmF0ZS9yb3V0 aW5nLmh0bWwNCj4gDQo+IEFsdGhvdWdoIHRoZXNlIGNvbW1lbnRzIGFyZSBwcmltYXJpbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIFJvdXRpbmcgQURzLCBpdA0KPiB3b3VsZCBiZSBoZWxwZnVsIGlmIHlv dSBjb3VsZCBjb25zaWRlciB0aGVtIGFsb25nIHdpdGggYW55IG90aGVyIElFVEYgTGFzdA0KPiBD YWxsIGNvbW1lbnRzIHRoYXQgeW91IHJlY2VpdmUsIGFuZCBzdHJpdmUgdG8gcmVzb2x2ZSB0aGVt IHRocm91Z2gNCj4gZGlzY3Vzc2lvbiBvciBieSB1cGRhdGluZyB0aGUgZHJhZnQuDQo+IA0KPiBE b2N1bWVudDogZHJhZnQtaWV0Zi1uZXRtb2QtaXAtY2ZnLTEyLnR4dA0KPiBSZXZpZXdlcjogQWxp YSBBdGxhcw0KPiBSZXZpZXcgRGF0ZTogMjIgSmFudWFyeSAyMDE0DQo+IElFVEYgTEMgRW5kIERh dGU6IDIzIEphbnVhcnkgMjAxNA0KPiBJbnRlbmRlZCBTdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJk DQo+IA0KPiAqU3VtbWFyeToqDQo+IEkgaGF2ZSBhIGZldyBtaW5vciBjb25jZXJucyBhYm91dCB0 aGlzIGRvY3VtZW50IChjbGFyaWZ5aW5nIGEgZmV3IGFzcGVjdHMpDQo+IHRoYXQgSSB0aGluayBz aG91bGQgYmUgcmVzb2x2ZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KPiANCj4gKkNvbW1lbnRzOioN Cj4gVGhpcyBkb2N1bWVudCBpcyB2ZXJ5IGNsZWFybHkgd3JpdHRlbiwgYnV0IEkgZGlkIGZpbmQg YSBmZXcgZGV0YWlscyB0aGF0DQo+IGNvdWxkIHVzZSBhIGJpdCBtb3JlIGNsYXJpdHkuICBJIHdh cyBhYmxlIHRvIGZpZ3VyZSBvdXQgd2hhdCB3YXMgaW50ZW5kZWQNCj4gYnkgd2FuZGVyaW5nIHRo cm91Z2ggdGhlIHJlZmVyZW5jZWQgUkZDcy4NCj4gDQo+ICpNYWpvciBJc3N1ZXM6Kg0KPiBObyBt YWpvciBpc3N1ZXMgZm91bmQuDQo+IA0KPiAqTWlub3IgSXNzdWVzOioNCj4gDQo+IA0KPiAgICAx LiBpcHY0L2ZvcndhcmRpbmcgYW5kIGlwdjYvZm9yd2FyZGluZzogIEZpcnN0LCBJIHdhc24ndCBz dXJlIHdoYXQgdGhpcw0KPiAgICBtZWFudCBvciBob3cgaXQgd2FzIGRpZmZlcmVudCBmcm9tIGlw djQvZW5hYmxlIG9yIGlwdjYvZW5hYmxlLiAgIEkgd2VudA0KPiAgICBiYWNrIHRvIGxvb2sgYXQg UkZDIDQyOTMgdG8gbGVhcm4gdGhhdCBpcHY0L2ZvcndhcmRpbmcgbWVhbnMg4oCcYWN0aW5nIGFz IGENCj4gICAgcm91dGVyIGFuZCBmb3J3YXJkaW5nIHRyYWZmaWMgbm90IGRlc3RpbmVkIHRvIHRo ZSBkZXZpY2XigJ0uICBDb3VsZCB5b3UNCj4gICAgY2xhcmlmeSB0aGUgdGV4dCB0byBhZGQgdGhv c2Uga2V5IGRldGFpbHMgaW50byB0aGUgZGVzY3JpcHRpb24gZm9yDQo+ICAgIGlwdjQvZm9yd2Fy ZGluZyBhbmQgaXB2Ni9mb3J3YXJkaW5nPw0KDQpJIHRoaW5rIHRoaXMgcHJvYmFibHkgYmVjb21l cyBtb3JlIGNsZWFyIGlmIHdlIGNsYXJpZnkgdGhlICJlbmFibGVkIg0KbGVhZiBhcyB5b3Ugc3Vn Z2VzdCBiZWxvdyBpbiAoMikuICBXaXRoIHRoZSBzdWdnZXN0ZWQgbmV3IHRleHQgYmVsb3cNCm1h eWJlIHRoaXMgImZvcndhcmRpbmciIGxlYWYgaXMgb2s/ICBPdGhlcndpc2UsIHdlIGNvdWxkIHdy aXRlIGluIHRoZQ0Kc3R5bGUgb2YgNDI5MzoNCg0KT0xEOg0KDQogICAgICAgICAgIkNvbnRyb2xz IGlmIElQdjQgcGFja2V0IGZvcndhcmRpbmcgaXMgZW5hYmxlZCBvciBkaXNhYmxlZA0KICAgICAg ICAgICBvbiB0aGlzIGludGVyZmFjZS4iOw0KDQpORVc6DQoNCiAgICAgICAgICAiQ29udHJvbHMg SVB2NCBwYWNrZXQgZm9yd2FyZGluZyBvZiBkYXRhZ3JhbXMgcmVjZWl2ZWQgYnksDQogICAgICAg ICAgIGJ1dCBub3QgYWRkcmVzc2VkIHRvLCB0aGlzIGludGVyZmFjZS4gIElQdjQgcm91dGVycyBm b3J3YXJkDQogICAgICAgICAgIGRhdGFncmFtcy4gIElQdjQgaG9zdHMgZG8gbm90IChleGNlcHQg dGhvc2Ugc291cmNlLXJvdXRlZA0KICAgICAgICAgICB2aWEgdGhlIGhvc3QpIjsNCg0KPiAgICBT ZWNvbmQsIEkgd2FzIHN1cnByaXNlZCB0aGF0IHRoZQ0KPiAgICBkZWZhdWx0IGlzIGZhbHNlOyBJ IHRoaW5rIGFib3V0IHRoaXMgZnJvbSB0aGUgcm91dGVyIHBlcnNwZWN0aXZlLCBvZg0KPiAgICBj b3Vyc2UsIGJ1dCBhIGJpdCBvZiBleHBsYW5hdGlvbiBhcyB0byB3aHkgdGhhdCBkZWNpc2lvbiB3 YXMgbWFkZSB3b3VsZCBiZQ0KPiAgICB1c2VmdWwuDQoNClRoZSBjb25jZXB0dWFsIHZhcmlhYmxl IElzUm91dGVyLCBkZWZpbmVkIGluIFJGQyA0ODYxLCBoYXMgRkFMU0UgYXMNCml0cyBkZWZhdWx0 IHZhbHVlLiAgKHNlZSBtb3JlIGJlbG93KS4NCg0KPiAgICAyLiBpcHY0L2VuYWJsZWQgYW5kIGlw djYvZW5hYmxlZDogIFNpbWlsYXJseSwgd2hhdCBpcyBlbmFibGVkIGJ5DQo+ICAgIGlwdjQvZW5h YmxlZCBpc27igJl0IGNsZWFyICh1bmxlc3MgSSBsb29rIGF0IFJGQyA0MjkzKS4gICBDb3VsZCB5 b3UgY2xhcmlmeQ0KPiAgICB0aGF0IGl0IG1lYW5zIGNvbm5lY3RlZCB0byBhbiBJUHY0IHN0YWNr IGZvciBzZW5kaW5nIG91dCBJUHY0IHBhY2tldHMgYW5kDQo+ICAgIGZvciByZWNlaXZpbmcgdG8t bWUgcGFja2V0cyBhbmQgZG8gdGhlIHNhbWUgY2xhcmlmaWNhdGlvbiBmb3IgaXB2Ni9lbmFibGVk Pw0KDQpXb3VsZCB0aGlzIHdvcms/DQoNCk9MRDoNCg0KICAgICAgICAgICJDb250cm9scyBpZiBJ UHY2IGlzIGVuYWJsZWQgb3IgZGlzYWJsZWQgb24gdGhpcw0KICAgICAgICAgICBpbnRlcmZhY2Uu IjsNCg0KTkVXOg0KDQogICAgICAgICAgIkNvbnRyb2xzIGlmIElQdjYgaXMgZW5hYmxlZCBvciBk aXNhYmxlZCBvbiB0aGlzDQogICAgICAgICAgIGludGVyZmFjZS4gIFdoZW4gSVB2NiBpcyBlbmFi bGVkLCB0aGlzIGludGVyZmFjZSBpcw0KICAgICAgICAgICBjb25uZWN0ZWQgdG8gYW4gSVB2NiBz dGFjaywgYW5kIHRoZSBpbnRlcmZhY2UgY2FuIHNlbmQNCiAgICAgICAgICAgYW5kIHJlY2VpdmUg SVB2NiBwYWNrZXRzLiI7DQoNCg0KPiAgICAzLiBpcHY0L210dSBhbmQgaXB2Ni9tdHU6ICBUaGlz IGlzIGRpc2N1c3Npbmcgc2VuZGluZyBhbmQgcmVjZWl2aW5nDQo+ICAgIHBhY2tldHMg4oCTIGEg bWVudGlvbiBvZiB0aGUgTVJVIHdvdWxkIGJlIHVzZWZ1bCBhbmQgZXZlbiBxdW90aW5nICBSRkMy NDYwIGluDQo+ICAgIFNlYyA1IHdoaWNoIHNheXMg4oCcRnJvbSBlYWNoIGxpbmsgdG8gd2hpY2gg YSBub2RlIGlzIGRpcmVjdGx5IGF0dGFjaGVkLA0KPiAgICB0aGUgbm9kZSBtdXN0IGJlICBhYmxl IHRvIGFjY2VwdCBwYWNrZXRzIGFzIGxhcmdlIGFzIHRoYXQgbGluaydzIE1UVS4g4oCcDQo+ICAg IHNvIGl04oCZcyBjbGVhci4NCg0KSG1tLCB0aGUgY3VycmVudCB0ZXh0IHNheXM6DQoNCiAgICAg ICAgIlRoZSBzaXplLCBpbiBvY3RldHMsIG9mIHRoZSBsYXJnZXN0IElQdjYgcGFja2V0IHRoYXQg dGhlDQogICAgICAgICBpbnRlcmZhY2Ugd2lsbCBzZW5kIGFuZCByZWNlaXZlLg0KDQpJc24ndCBp dCBjbGVhciB0aGF0IGl0IGFwcGxpZXMgYWxzbyB0byB0aGUgc2l6ZSBvZiByZWNlaXZlZCBwYWNr ZXRzPw0KT3IgbWF5YmUgSSBtaXN1bmRlcnN0b29kIHlvdXIgY29uY2Vybj8NCg0KDQo+ICAgIDQu ICBGb3IgdGhlIEFSUCBjYWNoZSAoaXB2NC9uZWlnaGJvcikgYW5kIE5EIGNhY2hlIChpcHY2L25l aWdoYm9yKSwgaXMNCj4gICAgdGhlcmUgYSByZWFzb24gdGhhdCBsYXN0VXBkYXRlZCBpc27igJl0 IGluY2x1ZGVkPyAgVGhpcyBkb2VzbuKAmXQgc2VlbSB0bw0KPiAgICBwcm92aWRlIHF1aXRlIGVu b3VnaCBpbmZvcm1hdGlvbiB0byBzZWUgd2hlbnIgbWFwcGluZ3Mgd2VyZSBsYXN0IHVwZGF0ZWQ/ DQo+ICAgIElzIHRoZSBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBiZSBhIEFSUCBzcGVjaWZp YyBhbmQgTkQgc3BlY2lmaWMgWUFORw0KPiAgICBtb2RlbCBmb3IgZ2V0dGluZyB0aGUgZGV0YWls cz8NCg0KTm8sIHRoZSBpbnRlbnRpb24gaXMgdGhhdCB0aGlzIG1vZGVsIHNob3VsZCBiZSBzdWZm aWNpZW50Lg0KDQpUaGVyZSBpcyBub3Qgc3VjaCAibGFzdCB1cGRhdGVkIiBvYmplY3QgZGVmaW5l ZCBpbiBSRkMgNDg2MS4gIEFsc28sIGl0DQpzZWVtcyB0aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBh dmFpbGFibGUgaW4gc29tZSBpbXBsZW1lbnRhdGlvbnMgKG5vdA0KaW4gbGludXgpLiAgIERvIG90 aGVyIGltcGxlbWVudGF0aW9uIHR5cGNpYWxseSBzdG9yZSB0aGlzIGluZm8/ICBJZg0Kc28sIGlu IHdoYXQgZm9ybT8NCg0KDQo+ICpOaXRzOioNCj4gDQo+IEkndmUgcHV0IHRoZXNlIGFzIG5pdHMg YmVjYXVzZSBJIHRoaW5rIHRoYXQgdGhleSBhcmUgcHJvYmFibHkgdGV4dHVhbA0KPiBlcnJvcnMg cmF0aGVyIHRoYW4gaW50ZW50aW9uYWwuLi4NCj4gDQo+IA0KPiAgICAxLiAgaXB2Ni9mb3J3YXJk aW5nOiAgIHdoeSBpcyB0aGUgcmVmZXJlbmNlIFJGQyA0ODYxIOKAkyBuZWlnaGJvcg0KPiAgICBk aXNjb3Zlcnk/Pz8gIFRoYXQgc2VlbXMgbGlrZSBpdCBhcHBsaWVzIHRvIHRoZSBuZWlnaGJvciBp bmZvLCB1bmxlc3MgSeKAmXZlDQo+ICAgIG1pc3VuZGVyc3Rvb2Qgd2hhdCBpcHY2L2ZvcndhcmRp bmcgaXMgZG9pbmfigKYNCg0KQWN0dWFsbHksIHRoZSBvYmplY3QgSXNSb3V0ZXIgaW4gNi4yLjEg aW4gUkZDIDQ4NjEgYXBwbGllcyB0byB0aGUNCmludGVyZmFjZSwgbm90IHRvIHRoZSBuZWlnaGJv ci4gIFRoaXMgb2JqZWN0IGlzIGRlZmluZWQgYXM6DQoNCiAgICAgICAgICAgICAgICAgICAgIEEg ZmxhZyBpbmRpY2F0aW5nIHdoZXRoZXIgcm91dGluZyBpcyBlbmFibGVkIG9uDQogICAgICAgICAg ICAgICAgICAgICB0aGlzIGludGVyZmFjZS4gIEVuYWJsaW5nIHJvdXRpbmcgb24gdGhlIGludGVy ZmFjZQ0KICAgICAgICAgICAgICAgICAgICAgd291bGQgaW1wbHkgdGhhdCBhIHJvdXRlciBjYW4g Zm9yd2FyZCBwYWNrZXRzIHRvIG9yDQogICAgICAgICAgICAgICAgICAgICBmcm9tIHRoZSBpbnRl cmZhY2UuDQoNCihUaGUgbmVpZ2hib3IgY2FjaGUgYWxzbyB0YWdzIGVhY2ggbmVpZ2hib3IgYXMg YmVpbmcgYSByb3V0ZXIgb3Igbm90KS4NCg0KDQo+ICAgIDIuIEluIHRoZSBzZWNvbmQgdGFibGUg aW4gU2VjIDMsIGlwdjQvbmVpZ2hib3IvaW50ZXJmYWNlIGFuZA0KPiAgICBpcHY2L25laWdoYm9y L2ludGVyZmFjZSBhcmUgbGlzdGVkLCBidXQgSSBkb27igJl0IHNlZSB0aGVtIGluIHN0YXRlIHRy ZWUgaW4NCj4gICAgU2VjIDIuICBJIHRoaW5rIHRoYXTigJlzIGJlY2F1c2UgdGhleSBhcmVu4oCZ dCBuZWNlc3Nhcnk/Pw0KDQpObyB0aGlzIGlzIGEgYnVnIC0gSSBmb3Jnb3QgdG8gcmVtb3ZlIHRo ZXNlIHdoZW4gd2UgY2hhbmdlZCB0aGUgZGF0YQ0KbW9kZWwgYXQgc29tZSB0aW1lLiAgVGhhbmtz IGZvciBzcG90dGluZyBpdCENCg0KDQovbWFydGluDQo= From curtis@ipv6.occnc.com Sat Jan 25 11:21:03 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD691A003B; Sat, 25 Jan 2014 11:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pUtgReEbgMn; Sat, 25 Jan 2014 11:20:58 -0800 (PST) Received: from maildrop2.v6ds.occnc.com (maildrop2.v6ds.occnc.com [IPv6:2001:470:88e6:3::232]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2E1A002F; Sat, 25 Jan 2014 11:20:58 -0800 (PST) Received: from harbor3.ipv6.occnc.com (harbor3.v6ds.occnc.com [IPv6:2001:470:88e6:3::239]) (authenticated bits=128) by maildrop2.v6ds.occnc.com (8.14.7/8.14.7) with ESMTP id s0PJKtA4047788; Sat, 25 Jan 2014 14:20:56 -0500 (EST) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com> To: Lou Berger From: Curtis Villamizar In-reply-to: Your message of "Fri, 17 Jan 2014 13:01:33 -0500." <52D96FFD.1020408@labn.net> Date: Sat, 25 Jan 2014 14:20:55 -0500 Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, rtgwg@ietf.org, "rtg-ads@tools.ietf.org" , curtis@ipv6.occnc.com Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jan 2014 19:21:03 -0000 Lou, I am in the process of submitting a -14 version followed with only the changes for the OpsDir review followed by a -15 version with the additional changes from your RtgDir review. Please wait for the -15 version if you see the -14 and not the -15. Curtis In message <52D96FFD.1020408@labn.net> Lou Berger writes: > > sounds like a plan! > > Lou > > On 01/17/2014 12:41 PM, Curtis Villamizar wrote: > > In message <52D88F77.5020009@labn.net> > > Lou Berger writes: > > > >> Curtis, > >> I'm not sure if we're going around in circles or not, but in either > >> case case I think we're getting caught up in the weeds/details. > >> > >> >From a high level perspective, my comments have been motivated by trying > >> to ensure the requirements are unambiguous -- as documented. I think > >> the text changes that have been agreed to so far (notably the use of the > >> capitalized term and introduction of AMG) will help a lot. I think there > >> is still one more area that is unclear, but it's also possible that > >> we're arguing about text that you are planning to change. > >> > >> Do you have a version that captures all the changes to date that you can > >> distribute (or submit, as you choose)? Perhaps looking at this version > >> we'll find that the ambiguity is resolved or is sufficiently narrowed to > >> not be significant. Either way, the discussion can then continue from > >> the most current text. > >> > >> Thanks, > >> Lou > > > > > > Lou, > > > > I was going to suggest the same (if I understand your suggestion) - > > that is that a new draft be submitted and you (and others) can review > > and see if clarity has been sufficiently improved or if there are > > still issues with clarity. > > > > If that is OK with you and compatible with this process I will make > > two draft submissions back to back. One with just the OpsDir review > > comments addressed and a second with your comments so far addressed. > > IMHO it would be easier to discuss the clarity (or lack of) of the > > wording once changes have been made particularly since there are a few > > s/old/new/g terminology suggestions in the email thread. > > > > Curtis > > > > > >> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: > >>> In message <52D02F67.9070604@labn.net> > >>> Lou Berger writes: > >>> > >>>> Curtis, > >>>> > >>>> I think we have one disconnect (and corresponding related text) that we > >>>> need to resolve before we can be close the discussion. See below for > >>>> details.. > >>>> > >>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: > >>>>> Converging. But maybe one more round trip needed. > >>>>> > >>>>> In message <52CD9D58.4010109@labn.net> > >>>>> Lou Berger writes: > >>>>>> > >>>> ... > >>>> > >>>>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. > >>>>>>>>>> > >>>>>>>>>> The document uses server and client layer networks and LSPs and, > >>>>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks > >>>>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term > >>>>>>>>>> client/server when referring to network layers and just using the > >>>>>>>>>> lower/upper terminology. The one exception to this is in the definition > >>>>>>>>>> Client LSP which should simply be defined in the context of a multipath, > >>>>>>>>>> i.e.: > >>>>>>>>>> OLD > >>>>>>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>>>>>> NEW > >>>>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. > >>>>>>>>> > >>>>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any > >>>>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or > >>>>>>>>> over an advanced multipath. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Would you accept s/server layer/lower layer/g? > >>>>>>> > >>>>>>> The definition of server layer is not the same as the definition of > >>>>>>> lower layer. See below. > >>>>>>> > >>>>>>>>>> I think this also means that usage of the term "Client" is limited to > >>>>>>>>>> "Client LSP". > >>>>>>>>> > >>>>>>>>> I searched for all occurances of the word client. All occurances are > >>>>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is > >>>>>>>>> used only in the following paragraph. > >>>>>>>>> > >>>>>>>>> The ingress and egress of a multipath may be midpoint LSRs with > >>>>>>>>> respect to a given client LSP. A midpoint LSR does not participate > >>>>>>>>> in the signaling of any clients of the client LSP. Therefore, in > >>>>>>>>> general, multipath endpoints cannot determine requirements of clients > >>>>>>>>> of a client LSP through participation in the signaling of the clients > >>>>>>>>> of the client LSP. > >>>>>>>>> > >>>>>>>>> THe point is that "A midpoint LSR does not participate in the > >>>>>>>>> signaling of any clients of the client LSP" and that non-participation > >>>>>>>>> in client (or higher layer) signaling applies to any "client of a > >>>>>>>>> client LSP", not just other LSP running over it. > >>>>>>>>> > >>>>>>>>> I then searched for all occurances of the words upper and lower and > >>>>>>>>> higher. There are no occurances of "upper". > >>>>>>>>> > >>>>>>>>> There were a few occurances of "lower latency" and "higher latency". > >>>>>>>>> Other than that, all occurances of lower and higher except one are in > >>>>>>>>> the follwoing text: > >>>>>>>>> > >>>>>>>>> 3.2. Component Links Provided by Lower Layer Networks > >>>>>>>>> > >>>>>>>>> A component link may be supported by a lower layer network. For > >>>>>>>>> example, the lower layer may be a circuit switched network or another > >>>>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change > >>>>>>>>> the latency (and/or other performance parameters) seen by the client > >>>>>>>>> layer. Currently, there is no protocol for the lower layer network > >>>>>>>>> to inform the higher layer network of a change in a performance > >>>>>>>>> parameter. Communication of the latency performance parameter is a > >>>>>>>>> very important requirement. Communication of other performance > >>>>>>>>> parameters (e.g., delay variation) is desirable. > >>>>>>>>> > >>>>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower > >>>>>>>>> layer server network to communicate latency to the higher layer > >>>>>>>>> client network. > >>>>>>>>> > >>>>>>>>> The exception is this sentence: > >>>>>>>>> > >>>>>>>>> FR#22 The solution SHOULD support the use case where an advanced > >>>>>>>>> multipath itself is a component link for a higher order advanced > >>>>>>>>> multipath. For example, an advanced multipath comprised of MPLS- > >>>>>>>>> TP bi-directional tunnels viewed as logical links could then be > >>>>>>>>> used as a component link in yet another advanced multipath that > >>>>>>>>> connects MPLS routers. > >>>>>>>>> > >>>>>>>>> The terms lower layer and higher layer go all the way back to the ISO > >>>>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further > >>>>>>>>> back but that is before even my time. > >>>>>>>>> > >>>>>>>>> I don't think this is unclear but I could add the following in > >>>>>>>>> definitions: > >>>>>>>>> > >>>>>>>>> Higher Layers > >>>>>>>>> A client layer is the one immediately above a server layer. The > >>>>>>>>> client layer and all layers above that layer are higher layers. > >>>>>>>>> > >>>>>>>>> Lower Layers > >>>>>>>>> A server layer is the later immediately below a client laer. > >>>>>>>>> The server layer and all layers below are lower layers. > >>>>>>>>> > >>>>>>>>> Do I really need to put this in the definitions section? If yoy think > >>>>>>>>> it is necessary, I will add it. > >>>>>>>>> > >>>>>>>> Perhaps we've talked (okay written) past each other. I was suggesting > >>>>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. > >>>>>>>> And to use it (consistently) in place of "client and server Layer". > >>>>>>> > >>>>>>> I guess you missed the distinction in the definition above: > >>>>>>> > >>>>>>> For layer X layer Y is: > >>>>>>> > >>>>>>> client layer === Y = X+1 > >>>>>>> server layer === Y = X-1 > >>>>>>> higher layer === Y > X > >>>>>>> lower layer === Y < X > >>>>>>> > >>>>>>> So the definition client layer is not the same as the definition of > >>>>>>> higher layer. The definition of server layer is not the same as the > >>>>>>> definition of lower layer. > >>>>>>> > >>>>>>> In some discussions we really do mean "the server layer" and not any > >>>>>>> layer at any arbitrary depth below this one. > >>>>>> > >>>>>> I read your usage of client/server layer to be synonymous with > >>>>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense > >>>>>> of FR#8 (I think you really mean client layer not lower layer.) > >>>>> > >>>>> FR#8 and FR#9 are about the server layer telling the client layer > >>>>> about the delays that can be expected. There is a little redundancy > >>>>> here so s/ower layer server network/server network/ and > >>>>> s/higher layer client network/client network/. No plans to skip > >>>>> layers. > >>>>> > >>>> > >>>> I think we need to hit the points below before this one... > >>> > >>> OK. > >>> > >>>>>> Given the current document usage, I still think it makes sense to > >>>>>> eliminate the two instances of "client layer": How about the following: > >>>>>> OLD > >>>>>> Client LSP > >>>>>> A client LSP is an LSP which has been set up over a server layer. > >>>>>> In the context of this discussion, a client LSP is a LSP which > >>>>>> has been set up over a multipath as opposed to an LSP > >>>>>> representing the multipath itself or any LSP supporting a > >>>>>> component links of that multipath. > >>>>>> NEW > >>>>>> Client LSP > >>>>>> A client LSP is a LSP which > >>>>>> has been set up over Advanced Multipath as opposed to an LSP > >>>>>> representing the Advanced Multipath itself or any LSP that is > >>>>>> part of an Advanced Multipath Group. > >>>>> > >>>>> Nope. In general, a client LSP can be set up over a plain old > >>>>> Ethernet on a given hop, therefore the second definition is too > >>>>> narrow with this change. > >>>>> > >>>> > >>>> humm, you didn't have that in your OLD text. In fact, the old text > >>>> reads to me that an Advanced Multipath (solution?) logically sits > >>>> between a client LSP and an underlying server layer in all cases. > >>> > >>> The "OLD" was a quote from you and it was the original text in -13. I > >>> said "Nope. ..." to your suggested change to it in this way. > >>> > >>> Earlier > >>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I > >>> had suggested the following change: > >>> > >>> I don't think this is unclear but I could add the following in > >>> definitions: > >>> > >>> Higher Layers > >>> A client layer is the one immediately above a server layer. The > >>> client layer and all layers above that layer are higher layers. > >>> > >>> Lower Layers > >>> A server layer is the later immediately below a client laer. > >>> The server layer and all layers below are lower layers. > >>> > >>> Do I really need to put this in the definitions section? If yoy think > >>> it is necessary, I will add it. > >>> > >>> You will find this in the quoted text above. > >>> > >>> The definition of client LSP does not imply that Advanced Multipath is > >>> a layer. This also used lower case "multipath" which we can replace > >>> with AMG. There is no LAG layer in a network in with MPLS runs over > >>> Ethernet and some of the Ethernets use Link Aggregation. > >>> > >>>> So the model I see defined by the text has the following layers > >>>> > >>>> Client LSP (layer) > >>>> ---------- > >>>> Advanced Multipath (layer/solution/construct) > >>>> ---------- > >>>> Server Layer (composed of AMGs which are LSPs and/or links) > >>>> > >>>> Is this aligned with your intent? If not, can you explain the > >>>> relationship you see for Advanced Multipath Client LSPs and Advanced > >>>> Multipath AMGs? > >>> > >>> You imaginged this model and are trying to constrain the text to fit > >>> into it.. > >>> > >>> Consider these examples of client layer and server layer. > >>> > >>> plain old rfc-4206 > >>> > >>> LSP-1 (PSC-0) = client of LSP-2 > >>> LSP-2 (PSC-1) = server of LSP-1 > >>> > >>> LSP over Ethernet over PW over MPLS > >>> > >>> LSP-1 = client of Ethernet > >>> Ethernet = server of LSP-1, client of PW > >>> PW = server of Ethernet, client of LSP-2 > >>> LSP-2 = server of PW > >>> > >>> There is then the question of whether Advanced Multipath is a layer or > >>> a set of techniques that can be applied at a given layer. Example > >>> potential config language: > >>> > >>> mple { > >>> tunnel x1 { > >>> type multipath { > >>> component tunnel x2; > >>> component tunnel x3; > >>> [...] > >>> component intf i1; > >>> component intf i2; > >>> [...] > >>> } > >>> [...] > >>> } > >>> [...] > >>> } > >>> > >>> No distinct layer above. > >>> > >>> An alternate: > >>> > >>> mple { > >>> tunnel x1 { > >>> [...] > >>> } > >>> [...] > >>> } > >>> > >>> interface amg1; > >>> type multipath { > >>> component tunnel x2; > >>> component tunnel x3; > >>> [...] > >>> component intf i1; > >>> component intf i2; > >>> [...] > >>> } > >>> [...] > >>> } > >>> [...] > >>> } > >>> > >>> In the former example, the tunnel x1 is forced to use a specific set > >>> of component links and apply multipath techniques to it. > >>> > >>> In the latter example, if tunnel x1 happen to find that interface amg1 > >>> was the lowest cost or otherwise preferred way to get to its > >>> destination it makes use of amg1 and if so inherits the use of the > >>> multipath techniques. > >>> > >>> There is no distinct multipath encapsulation at the date layer so some > >>> might argue that even in the second case there is no distinct layer, > >>> just a configuration convenience. > >>> > >>> Claiming that Advanced Multipath is of itself a layer may get us into > >>> a bigger can of worms. > >>> > >>> For example in today's ECMP, the next hop consists of multiple > >>> interfaces. ECMP is not considered a layer between IP and those > >>> interfaces. Link bundle is also not considered a layer. > >>> > >>> In the document we have not claimed that Advanced Multipath is a type > >>> of layer and we have not claimed that Advanced Multipath is not a type > >>> of layer. Either way we would get someone arguing that the opposite > >>> was true. [Some individuals it seems would pick the opposite of > >>> whatever we picked just because they like to argue about layering.] > >>> > >>> Need I remind you of the painfully long and mostly pointless arguments > >>> in MPLS during the early MPLS-TP work about whether an MPLS LSP > >>> carried within another hierarchical MPLS LSP was a layer or a > >>> sub-layer. We don't want to repeat that and the best way to do so is > >>> to not make any statement about whether Advanced Multipath is a layer > >>> or a sub-layer or a layering NOOP. > >>> > >>> Which of the above is the "right" way to do things may be at most a > >>> framework issue but may not come up until management plane entities > >>> are defined. It is certainly not a topic for a requirements document > >>> because it is deep into the "how it gets done". > >>> > >>>>>> and > >>>>>> OLD > >>>>>> The above set of requirements apply to component links with different > >>>>>> characteristics regardless as to whether those component links are > >>>>>> provided by parallel physical links between nodes or provided by sets > >>>>>> of paths across a network provided by server layer LSP. > >>>>>> NEW > >>>>>> The above set of requirements apply to component links with different > >>>>>> characteristics regardless as to whether those component links are > >>>>>> provided by parallel physical links between nodes or provided by > >>>>>> LSPs that are part of an Advanced Multipath Group. > >>>>> > >>>>> What about PW? Those are paths too by the definition of paths, so > >>>>> again, this change makes the definition too narrow. > >>>>> > >>>> > >>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also > >>>> have no objections to adding them. > >>> > >>> Actually the text you wrote is incorrect. "The above requirement > >>> applies to component links" can include physical links and server > >>> layer LSP but adding that are part of an Advanced Multipath Group is > >>> incorrect. > >>> > >>> I'm not sure but I think this instance of "server layer" was added to > >>> that LSP wording because you were confused on last review about client > >>> LSP vs LSP over which Advanced Multipath was applied so I went around > >>> changing everything to "client LSP" or "server layer LSP" to make it > >>> more clear to you. You now seem to be stuck on the wording that is > >>> essentially saying "any type of component link" including "server > >>> layer LSP". > >>> > >>>> The only change I made was > >>>> s/sets of paths across a network provided by server layer LSP./ > >>>> LSPs that are part of an Advanced Multipath Group. > >>> > >>> And that change was wrong. A more correct change would be > >>> > >>> s/provided by server layer LSP/including paths provided by server > >>> layer LSP/ > >>> > >>> That would include any sort of path across the network. PW could be > >>> considered an emulated physcial link or another usable type of path > >>> across the network. > >>> > >>> The "above set of requirements" in this case have to do with passing > >>> down requirements for min latency, bounded latency, and bounded > >>> jitter. The original paragraph is: > >>> > >>> The above set of requirements apply to component links with > >>> different characteristics regardless as to whether those component > >>> links are provided by parallel physical links between nodes or > >>> provided by sets of paths across a network provided by server layer > >>> LSP. > >>> > >>> The intent is "The above set of requirements apply to component links" > >>> followed by "regardless of what type of component links they are" > >>> where we had disccssed two types being an interface or emulated > >>> interface (or virtual interface in some major vendor terms) or an LSP > >>> (which is also a virtual interface in some major vendor terms). > >>> > >>> I don't understand how you can get so hung up on the wording of what > >>> is intended to convey "regardless of what type of component links they > >>> are". This has always been clear to the WG. > >>> > >>>>>>> The word "indicate" is independent of the method of getting the > >>>>>>> information there. But yes in the example given the IGP advertisement > >>>>>>> and MPLS LSP signaling that might be one such mechanism does refer to > >>>>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. > >>>>>>> > >>>>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there > >>>>>>> is only one IGP flooding information for both client and server layer, > >>>>>>> hence the seemingly endless (and mostly pointless) discussion of > >>>>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list > >>>>>>> who viewed MPLS as broken for not enforcing a strict layering in this > >>>>>>> regard. But we need not go into that level of detail in this example > >>>>>>> of how independent of mechanism the "indicate" is and down that years > >>>>>>> old MPLS WG terminology rat hole again. > >>>>>>> > >>>>>> My comment is that you need to be clear to which layer a requirement > >>>>>> applies. Is it the server layer, the client layer or the Advanced > >>>>>> Multipath layer? > >>>>> > >>>>> In each of the requirements you cited it is very clear that the client > >>>>> later is communicating a requirement to the server layer, but if you'd > >>>>> like I can reword to make that even more clear by rewording of the > >>>>> form "SHALL provide a means for the client layer to indicate the > >>>>> requirements of a client LSP [regarding X]", where X is minimize > >>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific > >>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering > >>>>> (FR#15), bounded frequency of rebalance (FR#20). > >>>> > >>>> Okay, I think this will/may help. My comment goes back to the model I > >>>> was asking about above. And to which part of the puzzle the requirement > >>>> applies. > >>> > >>> In some of the above requirements client layer communicated to the > >>> server layer, whatever the server layer is. Means of communication > >>> presumed to be RSVP-TE but we can't say that until the framework and > >>> same capability needs to be available to management plane. > >>> > >>> In some of the above requirements server layer communicates to the > >>> client layer. Means of communication is presumed to be IGP > >>> extensions, again with same capability available to management plane. > >>> > >>> There is no distinct Advanced Multipath layer in control plane or data > >>> plane. And if there was a distinct control plane layer it would be > >>> defined in a framework, not a requirements document. > >>> > >>>>>>>>> It would be trivial to make this FR#1 and renumber the rest. > >>>>>>>>> > >>>>>>>> > >>>>>>>> I don't think the FR helped clarify the above question. > >>>>>>> > >>>>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not > >>>>>>> imply usage by a specific layer. That is a direct answer to your > >>>>>>> question. > >>>>>>> > >>>>>>> In all of these specific cases, the the client layer is passing a > >>>>>>> requirement to the server layer so in the IGP + RSVP-TE world that > >>>>>>> would be a function of RSVP-TE. In the absense of control plane, it > >>>>>>> would have to be done through management plane interaction where the > >>>>>>> client indicates requirements of an LSP and the server layer is free > >>>>>>> to figure out how to meet those requirements. > >>>>>>> > >>>>>>> Do you want me to add the clarification on the use of the word > >>>>>>> "indicate" or not? > >>>>>> > >>>>>> I think you need to be clear that the requirement applies to all three > >>>>>> layers. > >>>>> > >>>>> There are no distinct three layers. You are imagining a model that is > >>>>> not used in this document so please don't impose model on our document. > >>>>> > >>>> > >>>> Well your old definition of Client LSP said that it was a client of > >>>> "multipath" and else where you say that "multipath" operates over a > >>>> server layer. As mentioned above, this sounds like three layers to me. > >>>> If this is not your intent, I think you need to make it clear (through > >>>> revised text) what model you do intend. > >>> > >>> This is the current text in -13: > >>> > >>> Client LSP > >>> A client LSP is an LSP which has been set up over a server layer. > >>> In the context of this discussion, a client LSP is a LSP which > >>> has been set up over a multipath as opposed to an LSP > >>> representing the multipath itself or any LSP supporting a > >>> component links of that multipath. > >>> > >>> The text is trying to clarify what a "client LSP" is in the first > >>> sentence and then trying to give two cases of what a client LSP is > >>> not. This clarification was specifically added *for you* in the last > >>> iteration. > >>> > >>> There was no intention to imply that Advanced Multipath is or is not > >>> in of itself a type of layer. If you are getting that notion from > >>> this text, then we need to change it. > >>> > >>> OLD: > >>> > >>> Client LSP > >>> A client LSP is an LSP which has been set up over a server layer. > >>> In the context of this discussion, a client LSP is a LSP which > >>> has been set up over a multipath as opposed to an LSP > >>> representing the multipath itself or any LSP supporting a > >>> component links of that multipath. > >>> > >>> NEW: > >>> > >>> Client LSP > >>> > >>> A client LSP is an LSP which has been set up over a set of one > >>> or more lower layers. In the context of this discussion, one > >>> type of client LSP is a LSP which has been set up over an AMG. > >>> > >>> We could also add a clarification to the definitions section that > >>> states: > >>> > >>> This document makes no statement on whether Advanced Multipath is > >>> itself a layer or whether an instance of AMG is itself a layer. > >>> This is to avoid engaging in long and pointless discussions about > >>> what consistitutes a proper layer. > >>> > >>> I would *really* like to add the above statement. > >>> > >>>>> In your sentence above I have no idea what "the requirement" refers to. > >>>>> > >>>>> In summary: > >>>>> > >>>>> We were discussing why the word "indicate" was used to avoid requiring > >>>>> specific mechanisms for information passing and I asked if I should > >>>>> add the following. > >>>>> > >>>>> FR#0 In requirements that follow in this document the word > >>>>> "indicate" is used where information may be provided by either > >>>>> the combination of link state IGP advertisement and MPLS LSP > >>>>> signaling or via management plane protocols. In later documents > >>>>> providing framework and protocol definitions both signaling and > >>>>> management plane mechanisms MUST be defined. > >>>>> > >>>>> Information is two way. The requirements you cited were all worded in > >>>>> the form "The solution SHALL provide a means to indicate that a client > >>>>> LSP will ...". So far I have offerred to reword this to the form "The > >>>>> solution SHALL provide a means for the client layer to indicate a > >>>>> requirement that a client LSP will ..." (ie: get minimum latency, get > >>>>> bound latency, etc). > >>>>> > >>>>> Is adding FR#0 OK? > >>>>> > >>>>> Do you want this sort of rewording to make it more explicit that the > >>>>> client layer is communication a requirement for a specific client LSP? > >>>>> > >>>> > >>>> I think we need to come back to this once we resolve the "model" topic. > >>>> > >>>> ... > >>>> > >>>> Thanks, > >>>> Lou > >>> > >>> I hope it is resolved. > >>> > >>> Curtis From lberger@labn.net Tue Jan 28 15:06:29 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2716C1A03E7 for ; Tue, 28 Jan 2014 15:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vg6GGHx2hg50 for ; Tue, 28 Jan 2014 15:06:24 -0800 (PST) Received: from oproxy4-pub.mail.unifiedlayer.com (oproxy4-pub.mail.unifiedlayer.com [74.220.216.66]) by ietfa.amsl.com (Postfix) with SMTP id 40DFA1A033C for ; Tue, 28 Jan 2014 15:06:24 -0800 (PST) Received: (qmail 2888 invoked by uid 0); 28 Jan 2014 23:06:21 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy4.mail.unifiedlayer.com with SMTP; 28 Jan 2014 23:06:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=6QmzKPN4Y81s4kamU7ZtJNJ7UVPuOo3busMaAm9Yocw=; b=P4DEs8/g76V8vWOQ6LrqMWYxolhO2iCaWRsqZ8/Qy3mgEMkZ7MViW9LwvSWDq84OEv5GgnEpSen6Rogf+61+b/whwBwOVCrra73P1Wml3WW6zbVedUXFPFH0UmZv3Zjo; Received: from box313.bluehost.com ([69.89.31.113]:59650 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1W8HjZ-0008Rn-AT; Tue, 28 Jan 2014 16:06:21 -0700 Message-ID: <52E837E8.3000001@labn.net> Date: Tue, 28 Jan 2014 18:06:16 -0500 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: curtis@ipv6.occnc.com References: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com> In-Reply-To: <201401251920.s0PJKtA4047788@maildrop2.v6ds.occnc.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: rtg-dir@ietf.org, draft-ietf-rtgwg-cl-requirement.all@tools.ietf.org, "rtg-ads@tools.ietf.org" , rtgwg@ietf.org Subject: Re: [RTG-DIR] (resend) Re: RtgDir review: draft-ietf-rtgwg-cl-requirement-13 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2014 23:06:29 -0000 Curtis, The changes in the current rev address most of my comments and the document is significantly less ambiguous. I'm still not a big fan of how client and layers are used in the document, but I think this is in the weeds and we should move on and not engage, as the draft says, "in long and pointless discussions". Lou On 1/25/2014 2:20 PM, Curtis Villamizar wrote: > Lou, > > I am in the process of submitting a -14 version followed with only the > changes for the OpsDir review followed by a -15 version with the > additional changes from your RtgDir review. Please wait for the -15 > version if you see the -14 and not the -15. > > Curtis > > > In message <52D96FFD.1020408@labn.net> > Lou Berger writes: >> >> sounds like a plan! >> >> Lou >> >> On 01/17/2014 12:41 PM, Curtis Villamizar wrote: >>> In message <52D88F77.5020009@labn.net> >>> Lou Berger writes: >>> >>>> Curtis, >>>> I'm not sure if we're going around in circles or not, but in either >>>> case case I think we're getting caught up in the weeds/details. >>>> >>>> >From a high level perspective, my comments have been motivated by trying >>>> to ensure the requirements are unambiguous -- as documented. I think >>>> the text changes that have been agreed to so far (notably the use of the >>>> capitalized term and introduction of AMG) will help a lot. I think there >>>> is still one more area that is unclear, but it's also possible that >>>> we're arguing about text that you are planning to change. >>>> >>>> Do you have a version that captures all the changes to date that you can >>>> distribute (or submit, as you choose)? Perhaps looking at this version >>>> we'll find that the ambiguity is resolved or is sufficiently narrowed to >>>> not be significant. Either way, the discussion can then continue from >>>> the most current text. >>>> >>>> Thanks, >>>> Lou >>> >>> >>> Lou, >>> >>> I was going to suggest the same (if I understand your suggestion) - >>> that is that a new draft be submitted and you (and others) can review >>> and see if clarity has been sufficiently improved or if there are >>> still issues with clarity. >>> >>> If that is OK with you and compatible with this process I will make >>> two draft submissions back to back. One with just the OpsDir review >>> comments addressed and a second with your comments so far addressed. >>> IMHO it would be easier to discuss the clarity (or lack of) of the >>> wording once changes have been made particularly since there are a few >>> s/old/new/g terminology suggestions in the email thread. >>> >>> Curtis >>> >>> >>>> On 1/15/2014 7:00 PM, Curtis Villamizar wrote: >>>>> In message <52D02F67.9070604@labn.net> >>>>> Lou Berger writes: >>>>> >>>>>> Curtis, >>>>>> >>>>>> I think we have one disconnect (and corresponding related text) that we >>>>>> need to resolve before we can be close the discussion. See below for >>>>>> details.. >>>>>> >>>>>> On 1/8/2014 11:33 PM, Curtis Villamizar wrote: >>>>>>> Converging. But maybe one more round trip needed. >>>>>>> >>>>>>> In message <52CD9D58.4010109@labn.net> >>>>>>> Lou Berger writes: >>>>>>>> >>>>>> ... >>>>>> >>>>>>>>>>>> 2. Editorial: server and client layer vs upper and lower layer. >>>>>>>>>>>> >>>>>>>>>>>> The document uses server and client layer networks and LSPs and, >>>>>>>>>>>> sometimes interchangeably or redundantly, upper and lower layer networks >>>>>>>>>>>> and LSPs. I think this issue can be resolved by avoiding the term >>>>>>>>>>>> client/server when referring to network layers and just using the >>>>>>>>>>>> lower/upper terminology. The one exception to this is in the definition >>>>>>>>>>>> Client LSP which should simply be defined in the context of a multipath, >>>>>>>>>>>> i.e.: >>>>>>>>>>>> OLD >>>>>>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>>>>>> NEW >>>>>>>>>>>> A client LSP is an LSP which has been set up over Advanced Multipath. >>>>>>>>>>> >>>>>>>>>>> A client LSP can be set up over a server layer MPLS-TP LSP or any >>>>>>>>>>> server layer MPLS LSP or over a link layer or over a pseudowire ... or >>>>>>>>>>> over an advanced multipath. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Would you accept s/server layer/lower layer/g? >>>>>>>>> >>>>>>>>> The definition of server layer is not the same as the definition of >>>>>>>>> lower layer. See below. >>>>>>>>> >>>>>>>>>>>> I think this also means that usage of the term "Client" is limited to >>>>>>>>>>>> "Client LSP". >>>>>>>>>>> >>>>>>>>>>> I searched for all occurances of the word client. All occurances are >>>>>>>>> />> "client LSP" excexpt the phrase "client of a client LSP" and that is >>>>>>>>>>> used only in the following paragraph. >>>>>>>>>>> >>>>>>>>>>> The ingress and egress of a multipath may be midpoint LSRs with >>>>>>>>>>> respect to a given client LSP. A midpoint LSR does not participate >>>>>>>>>>> in the signaling of any clients of the client LSP. Therefore, in >>>>>>>>>>> general, multipath endpoints cannot determine requirements of clients >>>>>>>>>>> of a client LSP through participation in the signaling of the clients >>>>>>>>>>> of the client LSP. >>>>>>>>>>> >>>>>>>>>>> THe point is that "A midpoint LSR does not participate in the >>>>>>>>>>> signaling of any clients of the client LSP" and that non-participation >>>>>>>>>>> in client (or higher layer) signaling applies to any "client of a >>>>>>>>>>> client LSP", not just other LSP running over it. >>>>>>>>>>> >>>>>>>>>>> I then searched for all occurances of the words upper and lower and >>>>>>>>>>> higher. There are no occurances of "upper". >>>>>>>>>>> >>>>>>>>>>> There were a few occurances of "lower latency" and "higher latency". >>>>>>>>>>> Other than that, all occurances of lower and higher except one are in >>>>>>>>>>> the follwoing text: >>>>>>>>>>> >>>>>>>>>>> 3.2. Component Links Provided by Lower Layer Networks >>>>>>>>>>> >>>>>>>>>>> A component link may be supported by a lower layer network. For >>>>>>>>>>> example, the lower layer may be a circuit switched network or another >>>>>>>>>>> MPLS network (e.g., MPLS-TP)). The lower layer network may change >>>>>>>>>>> the latency (and/or other performance parameters) seen by the client >>>>>>>>>>> layer. Currently, there is no protocol for the lower layer network >>>>>>>>>>> to inform the higher layer network of a change in a performance >>>>>>>>>>> parameter. Communication of the latency performance parameter is a >>>>>>>>>>> very important requirement. Communication of other performance >>>>>>>>>>> parameters (e.g., delay variation) is desirable. >>>>>>>>>>> >>>>>>>>>>> FR#8 The solution SHALL specify a protocol means to allow a lower >>>>>>>>>>> layer server network to communicate latency to the higher layer >>>>>>>>>>> client network. >>>>>>>>>>> >>>>>>>>>>> The exception is this sentence: >>>>>>>>>>> >>>>>>>>>>> FR#22 The solution SHOULD support the use case where an advanced >>>>>>>>>>> multipath itself is a component link for a higher order advanced >>>>>>>>>>> multipath. For example, an advanced multipath comprised of MPLS- >>>>>>>>>>> TP bi-directional tunnels viewed as logical links could then be >>>>>>>>>>> used as a component link in yet another advanced multipath that >>>>>>>>>>> connects MPLS routers. >>>>>>>>>>> >>>>>>>>>>> The terms lower layer and higher layer go all the way back to the ISO >>>>>>>>>>> seven layer model of ancient times (1970s?, 1980s?) and maybe further >>>>>>>>>>> back but that is before even my time. >>>>>>>>>>> >>>>>>>>>>> I don't think this is unclear but I could add the following in >>>>>>>>>>> definitions: >>>>>>>>>>> >>>>>>>>>>> Higher Layers >>>>>>>>>>> A client layer is the one immediately above a server layer. The >>>>>>>>>>> client layer and all layers above that layer are higher layers. >>>>>>>>>>> >>>>>>>>>>> Lower Layers >>>>>>>>>>> A server layer is the later immediately below a client laer. >>>>>>>>>>> The server layer and all layers below are lower layers. >>>>>>>>>>> >>>>>>>>>>> Do I really need to put this in the definitions section? If yoy think >>>>>>>>>>> it is necessary, I will add it. >>>>>>>>>>> >>>>>>>>>> Perhaps we've talked (okay written) past each other. I was suggesting >>>>>>>>>> using/keeping the "higher and lower layer" terminology, not dropping it. >>>>>>>>>> And to use it (consistently) in place of "client and server Layer". >>>>>>>>> >>>>>>>>> I guess you missed the distinction in the definition above: >>>>>>>>> >>>>>>>>> For layer X layer Y is: >>>>>>>>> >>>>>>>>> client layer === Y = X+1 >>>>>>>>> server layer === Y = X-1 >>>>>>>>> higher layer === Y > X >>>>>>>>> lower layer === Y < X >>>>>>>>> >>>>>>>>> So the definition client layer is not the same as the definition of >>>>>>>>> higher layer. The definition of server layer is not the same as the >>>>>>>>> definition of lower layer. >>>>>>>>> >>>>>>>>> In some discussions we really do mean "the server layer" and not any >>>>>>>>> layer at any arbitrary depth below this one. >>>>>>>> >>>>>>>> I read your usage of client/server layer to be synonymous with >>>>>>>> higher/lower layer, i.e. -+ 1. Otherwise I'm not sure how to make sense >>>>>>>> of FR#8 (I think you really mean client layer not lower layer.) >>>>>>> >>>>>>> FR#8 and FR#9 are about the server layer telling the client layer >>>>>>> about the delays that can be expected. There is a little redundancy >>>>>>> here so s/ower layer server network/server network/ and >>>>>>> s/higher layer client network/client network/. No plans to skip >>>>>>> layers. >>>>>>> >>>>>> >>>>>> I think we need to hit the points below before this one... >>>>> >>>>> OK. >>>>> >>>>>>>> Given the current document usage, I still think it makes sense to >>>>>>>> eliminate the two instances of "client layer": How about the following: >>>>>>>> OLD >>>>>>>> Client LSP >>>>>>>> A client LSP is an LSP which has been set up over a server layer. >>>>>>>> In the context of this discussion, a client LSP is a LSP which >>>>>>>> has been set up over a multipath as opposed to an LSP >>>>>>>> representing the multipath itself or any LSP supporting a >>>>>>>> component links of that multipath. >>>>>>>> NEW >>>>>>>> Client LSP >>>>>>>> A client LSP is a LSP which >>>>>>>> has been set up over Advanced Multipath as opposed to an LSP >>>>>>>> representing the Advanced Multipath itself or any LSP that is >>>>>>>> part of an Advanced Multipath Group. >>>>>>> >>>>>>> Nope. In general, a client LSP can be set up over a plain old >>>>>>> Ethernet on a given hop, therefore the second definition is too >>>>>>> narrow with this change. >>>>>>> >>>>>> >>>>>> humm, you didn't have that in your OLD text. In fact, the old text >>>>>> reads to me that an Advanced Multipath (solution?) logically sits >>>>>> between a client LSP and an underlying server layer in all cases. >>>>> >>>>> The "OLD" was a quote from you and it was the original text in -13. I >>>>> said "Nope. ..." to your suggested change to it in this way. >>>>> >>>>> Earlier >>>>> (http://www.ietf.org/mail-archive/web/rtgwg/current/msg04274.html) I >>>>> had suggested the following change: >>>>> >>>>> I don't think this is unclear but I could add the following in >>>>> definitions: >>>>> >>>>> Higher Layers >>>>> A client layer is the one immediately above a server layer. The >>>>> client layer and all layers above that layer are higher layers. >>>>> >>>>> Lower Layers >>>>> A server layer is the later immediately below a client laer. >>>>> The server layer and all layers below are lower layers. >>>>> >>>>> Do I really need to put this in the definitions section? If yoy think >>>>> it is necessary, I will add it. >>>>> >>>>> You will find this in the quoted text above. >>>>> >>>>> The definition of client LSP does not imply that Advanced Multipath is >>>>> a layer. This also used lower case "multipath" which we can replace >>>>> with AMG. There is no LAG layer in a network in with MPLS runs over >>>>> Ethernet and some of the Ethernets use Link Aggregation. >>>>> >>>>>> So the model I see defined by the text has the following layers >>>>>> >>>>>> Client LSP (layer) >>>>>> ---------- >>>>>> Advanced Multipath (layer/solution/construct) >>>>>> ---------- >>>>>> Server Layer (composed of AMGs which are LSPs and/or links) >>>>>> >>>>>> Is this aligned with your intent? If not, can you explain the >>>>>> relationship you see for Advanced Multipath Client LSPs and Advanced >>>>>> Multipath AMGs? >>>>> >>>>> You imaginged this model and are trying to constrain the text to fit >>>>> into it.. >>>>> >>>>> Consider these examples of client layer and server layer. >>>>> >>>>> plain old rfc-4206 >>>>> >>>>> LSP-1 (PSC-0) = client of LSP-2 >>>>> LSP-2 (PSC-1) = server of LSP-1 >>>>> >>>>> LSP over Ethernet over PW over MPLS >>>>> >>>>> LSP-1 = client of Ethernet >>>>> Ethernet = server of LSP-1, client of PW >>>>> PW = server of Ethernet, client of LSP-2 >>>>> LSP-2 = server of PW >>>>> >>>>> There is then the question of whether Advanced Multipath is a layer or >>>>> a set of techniques that can be applied at a given layer. Example >>>>> potential config language: >>>>> >>>>> mple { >>>>> tunnel x1 { >>>>> type multipath { >>>>> component tunnel x2; >>>>> component tunnel x3; >>>>> [...] >>>>> component intf i1; >>>>> component intf i2; >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> No distinct layer above. >>>>> >>>>> An alternate: >>>>> >>>>> mple { >>>>> tunnel x1 { >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> interface amg1; >>>>> type multipath { >>>>> component tunnel x2; >>>>> component tunnel x3; >>>>> [...] >>>>> component intf i1; >>>>> component intf i2; >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> [...] >>>>> } >>>>> >>>>> In the former example, the tunnel x1 is forced to use a specific set >>>>> of component links and apply multipath techniques to it. >>>>> >>>>> In the latter example, if tunnel x1 happen to find that interface amg1 >>>>> was the lowest cost or otherwise preferred way to get to its >>>>> destination it makes use of amg1 and if so inherits the use of the >>>>> multipath techniques. >>>>> >>>>> There is no distinct multipath encapsulation at the date layer so some >>>>> might argue that even in the second case there is no distinct layer, >>>>> just a configuration convenience. >>>>> >>>>> Claiming that Advanced Multipath is of itself a layer may get us into >>>>> a bigger can of worms. >>>>> >>>>> For example in today's ECMP, the next hop consists of multiple >>>>> interfaces. ECMP is not considered a layer between IP and those >>>>> interfaces. Link bundle is also not considered a layer. >>>>> >>>>> In the document we have not claimed that Advanced Multipath is a type >>>>> of layer and we have not claimed that Advanced Multipath is not a type >>>>> of layer. Either way we would get someone arguing that the opposite >>>>> was true. [Some individuals it seems would pick the opposite of >>>>> whatever we picked just because they like to argue about layering.] >>>>> >>>>> Need I remind you of the painfully long and mostly pointless arguments >>>>> in MPLS during the early MPLS-TP work about whether an MPLS LSP >>>>> carried within another hierarchical MPLS LSP was a layer or a >>>>> sub-layer. We don't want to repeat that and the best way to do so is >>>>> to not make any statement about whether Advanced Multipath is a layer >>>>> or a sub-layer or a layering NOOP. >>>>> >>>>> Which of the above is the "right" way to do things may be at most a >>>>> framework issue but may not come up until management plane entities >>>>> are defined. It is certainly not a topic for a requirements document >>>>> because it is deep into the "how it gets done". >>>>> >>>>>>>> and >>>>>>>> OLD >>>>>>>> The above set of requirements apply to component links with different >>>>>>>> characteristics regardless as to whether those component links are >>>>>>>> provided by parallel physical links between nodes or provided by sets >>>>>>>> of paths across a network provided by server layer LSP. >>>>>>>> NEW >>>>>>>> The above set of requirements apply to component links with different >>>>>>>> characteristics regardless as to whether those component links are >>>>>>>> provided by parallel physical links between nodes or provided by >>>>>>>> LSPs that are part of an Advanced Multipath Group. >>>>>>> >>>>>>> What about PW? Those are paths too by the definition of paths, so >>>>>>> again, this change makes the definition too narrow. >>>>>>> >>>>>> >>>>>> PWs weren't mentioned in your OLD text, so I didn't add them. I also >>>>>> have no objections to adding them. >>>>> >>>>> Actually the text you wrote is incorrect. "The above requirement >>>>> applies to component links" can include physical links and server >>>>> layer LSP but adding that are part of an Advanced Multipath Group is >>>>> incorrect. >>>>> >>>>> I'm not sure but I think this instance of "server layer" was added to >>>>> that LSP wording because you were confused on last review about client >>>>> LSP vs LSP over which Advanced Multipath was applied so I went around >>>>> changing everything to "client LSP" or "server layer LSP" to make it >>>>> more clear to you. You now seem to be stuck on the wording that is >>>>> essentially saying "any type of component link" including "server >>>>> layer LSP". >>>>> >>>>>> The only change I made was >>>>>> s/sets of paths across a network provided by server layer LSP./ >>>>>> LSPs that are part of an Advanced Multipath Group. >>>>> >>>>> And that change was wrong. A more correct change would be >>>>> >>>>> s/provided by server layer LSP/including paths provided by server >>>>> layer LSP/ >>>>> >>>>> That would include any sort of path across the network. PW could be >>>>> considered an emulated physcial link or another usable type of path >>>>> across the network. >>>>> >>>>> The "above set of requirements" in this case have to do with passing >>>>> down requirements for min latency, bounded latency, and bounded >>>>> jitter. The original paragraph is: >>>>> >>>>> The above set of requirements apply to component links with >>>>> different characteristics regardless as to whether those component >>>>> links are provided by parallel physical links between nodes or >>>>> provided by sets of paths across a network provided by server layer >>>>> LSP. >>>>> >>>>> The intent is "The above set of requirements apply to component links" >>>>> followed by "regardless of what type of component links they are" >>>>> where we had disccssed two types being an interface or emulated >>>>> interface (or virtual interface in some major vendor terms) or an LSP >>>>> (which is also a virtual interface in some major vendor terms). >>>>> >>>>> I don't understand how you can get so hung up on the wording of what >>>>> is intended to convey "regardless of what type of component links they >>>>> are". This has always been clear to the WG. >>>>> >>>>>>>>> The word "indicate" is independent of the method of getting the >>>>>>>>> information there. But yes in the example given the IGP advertisement >>>>>>>>> and MPLS LSP signaling that might be one such mechanism does refer to >>>>>>>>> the IGP and RSVP-TE MPLS/GMPLS that we all are familiar with. >>>>>>>>> >>>>>>>>> If client and server LSP are PSC-3 and PSC-4 in MPLS hierarchy there >>>>>>>>> is only one IGP flooding information for both client and server layer, >>>>>>>>> hence the seemingly endless (and mostly pointless) discussion of >>>>>>>>> sub-layer vs layer from certain ITU people in the MPLS WG mailing list >>>>>>>>> who viewed MPLS as broken for not enforcing a strict layering in this >>>>>>>>> regard. But we need not go into that level of detail in this example >>>>>>>>> of how independent of mechanism the "indicate" is and down that years >>>>>>>>> old MPLS WG terminology rat hole again. >>>>>>>>> >>>>>>>> My comment is that you need to be clear to which layer a requirement >>>>>>>> applies. Is it the server layer, the client layer or the Advanced >>>>>>>> Multipath layer? >>>>>>> >>>>>>> In each of the requirements you cited it is very clear that the client >>>>>>> later is communicating a requirement to the server layer, but if you'd >>>>>>> like I can reword to make that even more clear by rewording of the >>>>>>> form "SHALL provide a means for the client layer to indicate the >>>>>>> requirements of a client LSP [regarding X]", where X is minimize >>>>>>> latency (FR#10), bound latency (FR#11), bound jitter (FR#12), specific >>>>>>> component link (FR#13), bidirection co-routed (FR#14), no reordering >>>>>>> (FR#15), bounded frequency of rebalance (FR#20). >>>>>> >>>>>> Okay, I think this will/may help. My comment goes back to the model I >>>>>> was asking about above. And to which part of the puzzle the requirement >>>>>> applies. >>>>> >>>>> In some of the above requirements client layer communicated to the >>>>> server layer, whatever the server layer is. Means of communication >>>>> presumed to be RSVP-TE but we can't say that until the framework and >>>>> same capability needs to be available to management plane. >>>>> >>>>> In some of the above requirements server layer communicates to the >>>>> client layer. Means of communication is presumed to be IGP >>>>> extensions, again with same capability available to management plane. >>>>> >>>>> There is no distinct Advanced Multipath layer in control plane or data >>>>> plane. And if there was a distinct control plane layer it would be >>>>> defined in a framework, not a requirements document. >>>>> >>>>>>>>>>> It would be trivial to make this FR#1 and renumber the rest. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I don't think the FR helped clarify the above question. >>>>>>>>> >>>>>>>>> The choice of the word "indicate" in FR10-13, FR14, FR15 does not >>>>>>>>> imply usage by a specific layer. That is a direct answer to your >>>>>>>>> question. >>>>>>>>> >>>>>>>>> In all of these specific cases, the the client layer is passing a >>>>>>>>> requirement to the server layer so in the IGP + RSVP-TE world that >>>>>>>>> would be a function of RSVP-TE. In the absense of control plane, it >>>>>>>>> would have to be done through management plane interaction where the >>>>>>>>> client indicates requirements of an LSP and the server layer is free >>>>>>>>> to figure out how to meet those requirements. >>>>>>>>> >>>>>>>>> Do you want me to add the clarification on the use of the word >>>>>>>>> "indicate" or not? >>>>>>>> >>>>>>>> I think you need to be clear that the requirement applies to all three >>>>>>>> layers. >>>>>>> >>>>>>> There are no distinct three layers. You are imagining a model that is >>>>>>> not used in this document so please don't impose model on our document. >>>>>>> >>>>>> >>>>>> Well your old definition of Client LSP said that it was a client of >>>>>> "multipath" and else where you say that "multipath" operates over a >>>>>> server layer. As mentioned above, this sounds like three layers to me. >>>>>> If this is not your intent, I think you need to make it clear (through >>>>>> revised text) what model you do intend. >>>>> >>>>> This is the current text in -13: >>>>> >>>>> Client LSP >>>>> A client LSP is an LSP which has been set up over a server layer. >>>>> In the context of this discussion, a client LSP is a LSP which >>>>> has been set up over a multipath as opposed to an LSP >>>>> representing the multipath itself or any LSP supporting a >>>>> component links of that multipath. >>>>> >>>>> The text is trying to clarify what a "client LSP" is in the first >>>>> sentence and then trying to give two cases of what a client LSP is >>>>> not. This clarification was specifically added *for you* in the last >>>>> iteration. >>>>> >>>>> There was no intention to imply that Advanced Multipath is or is not >>>>> in of itself a type of layer. If you are getting that notion from >>>>> this text, then we need to change it. >>>>> >>>>> OLD: >>>>> >>>>> Client LSP >>>>> A client LSP is an LSP which has been set up over a server layer. >>>>> In the context of this discussion, a client LSP is a LSP which >>>>> has been set up over a multipath as opposed to an LSP >>>>> representing the multipath itself or any LSP supporting a >>>>> component links of that multipath. >>>>> >>>>> NEW: >>>>> >>>>> Client LSP >>>>> >>>>> A client LSP is an LSP which has been set up over a set of one >>>>> or more lower layers. In the context of this discussion, one >>>>> type of client LSP is a LSP which has been set up over an AMG. >>>>> >>>>> We could also add a clarification to the definitions section that >>>>> states: >>>>> >>>>> This document makes no statement on whether Advanced Multipath is >>>>> itself a layer or whether an instance of AMG is itself a layer. >>>>> This is to avoid engaging in long and pointless discussions about >>>>> what consistitutes a proper layer. >>>>> >>>>> I would *really* like to add the above statement. >>>>> >>>>>>> In your sentence above I have no idea what "the requirement" refers to. >>>>>>> >>>>>>> In summary: >>>>>>> >>>>>>> We were discussing why the word "indicate" was used to avoid requiring >>>>>>> specific mechanisms for information passing and I asked if I should >>>>>>> add the following. >>>>>>> >>>>>>> FR#0 In requirements that follow in this document the word >>>>>>> "indicate" is used where information may be provided by either >>>>>>> the combination of link state IGP advertisement and MPLS LSP >>>>>>> signaling or via management plane protocols. In later documents >>>>>>> providing framework and protocol definitions both signaling and >>>>>>> management plane mechanisms MUST be defined. >>>>>>> >>>>>>> Information is two way. The requirements you cited were all worded in >>>>>>> the form "The solution SHALL provide a means to indicate that a client >>>>>>> LSP will ...". So far I have offerred to reword this to the form "The >>>>>>> solution SHALL provide a means for the client layer to indicate a >>>>>>> requirement that a client LSP will ..." (ie: get minimum latency, get >>>>>>> bound latency, etc). >>>>>>> >>>>>>> Is adding FR#0 OK? >>>>>>> >>>>>>> Do you want this sort of rewording to make it more explicit that the >>>>>>> client layer is communication a requirement for a specific client LSP? >>>>>>> >>>>>> >>>>>> I think we need to come back to this once we resolve the "model" topic. >>>>>> >>>>>> ... >>>>>> >>>>>> Thanks, >>>>>> Lou >>>>> >>>>> I hope it is resolved. >>>>> >>>>> Curtis > > > > > From bclaise@cisco.com Fri Jan 31 06:29:27 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F41A1A0233; Fri, 31 Jan 2014 06:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6Ht3X_-4MQn; Fri, 31 Jan 2014 06:29:25 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBAD1A0064; Fri, 31 Jan 2014 06:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6257; q=dns/txt; s=iport; t=1391178561; x=1392388161; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=qXagcwgxKR19tUYYRjkzmob2I/jOO8dg5dsh/jcNcYY=; b=Mp5F22hjXniNaIDAbN5x53Xl5btII4glu8XJ0Ds1L93a2vvmpW8D7Lmc olsvUwFLnwjoH/82VXMm5z58DtdYEsZSof0+leqMACWDTNqrBHHe87fBv s7z8bsyKyMTO0rsm3pMWFzMTVLFT4hY2F/bABJKlKbq9UOcP4fm+Ui44S Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAOqy61KQ/khR/2dsb2JhbABZgww4g1i5aE+BBxZ0giUBAQEDAQEBASAPAQU2CgEQCxQEAgIFFgsCAgkDAgECAQ8GMBMBBQIBAQWHaAMJCA2rHJduDYktF4Epi0OCFgeCb4FJAQOWPoFshkiGFoVDgy47 X-IronPort-AV: E=Sophos;i="4.95,758,1384300800"; d="scan'208";a="4477120" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 31 Jan 2014 14:29:19 +0000 Received: from [10.60.67.88] (ams-bclaise-8917.cisco.com [10.60.67.88]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s0VETJDM009350; Fri, 31 Jan 2014 14:29:19 GMT Message-ID: <52EBB33F.2090304@cisco.com> Date: Fri, 31 Jan 2014 15:29:19 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: akatlas@gmail.com References: <20140125.151847.09968453.mbj@tail-f.com> In-Reply-To: <20140125.151847.09968453.mbj@tail-f.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: rtg-dir@ietf.org, Martin Bjorklund , rtg-ads@tools.ietf.org, netmod@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org Subject: Re: [RTG-DIR] [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 14:29:27 -0000 Alia, Please let us know if your concerns are addressed. We would like to progress the draft. Regards, Benoit > Hi, > > Alia Atlas 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. 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-netmod-ip-cfg-12.txt >> Reviewer: Alia Atlas >> Review Date: 22 January 2014 >> IETF LC End Date: 23 January 2014 >> Intended Status: Proposed Standard >> >> *Summary:* >> I have a few minor concerns about this document (clarifying a few aspects) >> that I think should be resolved before publication. >> >> *Comments:* >> This document is very clearly written, but I did find a few details that >> could use a bit more clarity. I was able to figure out what was intended >> by wandering through the referenced RFCs. >> >> *Major Issues:* >> No major issues found. >> >> *Minor Issues:* >> >> >> 1. ipv4/forwarding and ipv6/forwarding: First, I wasn't sure what this >> meant or how it was different from ipv4/enable or ipv6/enable. I went >> back to look at RFC 4293 to learn that ipv4/forwarding means “acting as a >> router and forwarding traffic not destined to the device”. Could you >> clarify the text to add those key details into the description for >> ipv4/forwarding and ipv6/forwarding? > I think this probably becomes more clear if we clarify the "enabled" > leaf as you suggest below in (2). With the suggested new text below > maybe this "forwarding" leaf is ok? Otherwise, we could write in the > style of 4293: > > OLD: > > "Controls if IPv4 packet forwarding is enabled or disabled > on this interface."; > > NEW: > > "Controls IPv4 packet forwarding of datagrams received by, > but not addressed to, this interface. IPv4 routers forward > datagrams. IPv4 hosts do not (except those source-routed > via the host)"; > >> Second, I was surprised that the >> default is false; I think about this from the router perspective, of >> course, but a bit of explanation as to why that decision was made would be >> useful. > The conceptual variable IsRouter, defined in RFC 4861, has FALSE as > its default value. (see more below). > >> 2. ipv4/enabled and ipv6/enabled: Similarly, what is enabled by >> ipv4/enabled isn’t clear (unless I look at RFC 4293). Could you clarify >> that it means connected to an IPv4 stack for sending out IPv4 packets and >> for receiving to-me packets and do the same clarification for ipv6/enabled? > Would this work? > > OLD: > > "Controls if IPv6 is enabled or disabled on this > interface."; > > NEW: > > "Controls if IPv6 is enabled or disabled on this > interface. When IPv6 is enabled, this interface is > connected to an IPv6 stack, and the interface can send > and receive IPv6 packets."; > > >> 3. ipv4/mtu and ipv6/mtu: This is discussing sending and receiving >> packets – a mention of the MRU would be useful and even quoting RFC2460 in >> Sec 5 which says “From each link to which a node is directly attached, >> the node must be able to accept packets as large as that link's MTU. “ >> so it’s clear. > Hmm, the current text says: > > "The size, in octets, of the largest IPv6 packet that the > interface will send and receive. > > Isn't it clear that it applies also to the size of received packets? > Or maybe I misunderstood your concern? > > >> 4. For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is >> there a reason that lastUpdated isn’t included? This doesn’t seem to >> provide quite enough information to see whenr mappings were last updated? >> Is the assumption that there will be a ARP specific and ND specific YANG >> model for getting the details? > No, the intention is that this model should be sufficient. > > There is not such "last updated" object defined in RFC 4861. Also, it > seems this information is not available in some implementations (not > in linux). Do other implementation typcially store this info? If > so, in what form? > > >> *Nits:* >> >> I've put these as nits because I think that they are probably textual >> errors rather than intentional... >> >> >> 1. ipv6/forwarding: why is the reference RFC 4861 – neighbor >> discovery??? That seems like it applies to the neighbor info, unless I’ve >> misunderstood what ipv6/forwarding is doing… > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the > interface, not to the neighbor. This object is defined as: > > A flag indicating whether routing is enabled on > this interface. Enabling routing on the interface > would imply that a router can forward packets to or > from the interface. > > (The neighbor cache also tags each neighbor as being a router or not). > > >> 2. In the second table in Sec 3, ipv4/neighbor/interface and >> ipv6/neighbor/interface are listed, but I don’t see them in state tree in >> Sec 2. I think that’s because they aren’t necessary?? > No this is a bug - I forgot to remove these when we changed the data > model at some time. Thanks for spotting it! > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From akatlas@gmail.com Fri Jan 31 07:13:29 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C411A020C; Fri, 31 Jan 2014 07:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BmsgxvK0Oo1; Fri, 31 Jan 2014 07:13:24 -0800 (PST) Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by ietfa.amsl.com (Postfix) with ESMTP id 14E931A0193; Fri, 31 Jan 2014 07:13:24 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 131so24173439ykp.7 for ; Fri, 31 Jan 2014 07:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PklrJQLbqZatmpHyUZXE2nn/3ytnqghYnAyE+Sc6eUg=; b=Y1rqVc4NfINF60d/uKqgFspKkF03wKZsFgv9N51J91TXCdTlPvGu+uD8D3G4CUMmrP cZMoBQSNnpWWvC6zVSSyMO+kh/nKYRrYF3CQ/MZ7O2W4mrk0yr19t1YZt/AdRrHXCQmK wpIpW93XEB/6+4Ofu8RhTr/v1h10dyJ00tj92wa2Gryr+r43ANDqi+vHO+Qifc4uPO1G ZbQrMj2vJDj2FfbFsvTskgU17Xs0ncLOoN3Mj5MRWi7EFkjDc+4ucaILvBNnvnFm3c0u EUBLRVZgj7sOsqBQCeXcwA3gz4IyFCQq90gscCSGRaKdecIbDp/ScW674tUZiA+R8aNr GV5g== MIME-Version: 1.0 X-Received: by 10.236.200.35 with SMTP id y23mr18870884yhn.38.1391181163075; Fri, 31 Jan 2014 07:12:43 -0800 (PST) Received: by 10.170.186.88 with HTTP; Fri, 31 Jan 2014 07:12:43 -0800 (PST) In-Reply-To: <20140125.151847.09968453.mbj@tail-f.com> References: <20140125.151847.09968453.mbj@tail-f.com> Date: Fri, 31 Jan 2014 10:12:43 -0500 Message-ID: From: Alia Atlas To: Martin Bjorklund Content-Type: multipart/alternative; boundary=bcaec50b4bde0b2bf404f1459bb4 Cc: "rtg-dir@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org, "netmod@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 15:13:29 -0000 --bcaec50b4bde0b2bf404f1459bb4 Content-Type: text/plain; charset=ISO-8859-1 Responses in-line. On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund wrote: > Hi, > > Alia Atlas 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. 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-netmod-ip-cfg-12.txt > > Reviewer: Alia Atlas > > Review Date: 22 January 2014 > > IETF LC End Date: 23 January 2014 > > Intended Status: Proposed Standard > > > > *Summary:* > > I have a few minor concerns about this document (clarifying a few > aspects) > > that I think should be resolved before publication. > > > > *Comments:* > > This document is very clearly written, but I did find a few details that > > could use a bit more clarity. I was able to figure out what was intended > > by wandering through the referenced RFCs. > > > > *Major Issues:* > > No major issues found. > > > > *Minor Issues:* > > > > > > 1. ipv4/forwarding and ipv6/forwarding: First, I wasn't sure what > this > > meant or how it was different from ipv4/enable or ipv6/enable. I > went > > back to look at RFC 4293 to learn that ipv4/forwarding means "acting > as a > > router and forwarding traffic not destined to the device". Could you > > clarify the text to add those key details into the description for > > ipv4/forwarding and ipv6/forwarding? > > I think this probably becomes more clear if we clarify the "enabled" > leaf as you suggest below in (2). With the suggested new text below > maybe this "forwarding" leaf is ok? Otherwise, we could write in the > style of 4293: > > OLD: > > "Controls if IPv4 packet forwarding is enabled or disabled > on this interface."; > > NEW: > > "Controls IPv4 packet forwarding of datagrams received by, > but not addressed to, this interface. IPv4 routers forward > datagrams. IPv4 hosts do not (except those source-routed > via the host)"; > [Alia] Perfect > > > Second, I was surprised that the > > default is false; I think about this from the router perspective, of > > course, but a bit of explanation as to why that decision was made > would be > > useful. > > The conceptual variable IsRouter, defined in RFC 4861, has FALSE as > its default value. (see more below). > > [Alia] That's fine. > > 2. ipv4/enabled and ipv6/enabled: Similarly, what is enabled by > > ipv4/enabled isn't clear (unless I look at RFC 4293). Could you > clarify > > that it means connected to an IPv4 stack for sending out IPv4 packets > and > > for receiving to-me packets and do the same clarification for > ipv6/enabled? > > Would this work? > > OLD: > > "Controls if IPv6 is enabled or disabled on this > interface."; > > NEW: > > "Controls if IPv6 is enabled or disabled on this > interface. When IPv6 is enabled, this interface is > connected to an IPv6 stack, and the interface can send > and receive IPv6 packets."; > [Alia] Sounds great - same for IPv4? > > > > 3. ipv4/mtu and ipv6/mtu: This is discussing sending and receiving > > packets - a mention of the MRU would be useful and even quoting > RFC2460 in > > Sec 5 which says "From each link to which a node is directly attached, > > the node must be able to accept packets as large as that link's MTU. > " > > so it's clear. > > Hmm, the current text says: > > "The size, in octets, of the largest IPv6 packet that the > interface will send and receive. > > Isn't it clear that it applies also to the size of received packets? > Or maybe I misunderstood your concern? > [Alia] MRU and MTU do not need to be the same thing. The current text assumes that it is - and I agree that is a common way of configuring both in a single move. I was just looking for a bit more clarity that you really do mean MRU as well. It's not something that I feel strongly about. > > > 4. For the ARP cache (ipv4/neighbor) and ND cache (ipv6/neighbor), is > > there a reason that lastUpdated isn't included? This doesn't seem to > > provide quite enough information to see whenr mappings were last > updated? > > Is the assumption that there will be a ARP specific and ND specific > YANG > > model for getting the details? > > No, the intention is that this model should be sufficient. > > There is not such "last updated" object defined in RFC 4861. Also, it > seems this information is not available in some implementations (not > in linux). Do other implementation typcially store this info? If > so, in what form? > [Alia] I was looking at RFC 4293 and your table of comparison of objects between this YANG model and that MIB. If you look at the MIB, it has the following: IpNetToPhysicalEntry ::= SEQUENCE { ipNetToPhysicalIfIndex InterfaceIndex, ipNetToPhysicalNetAddressType InetAddressType, ipNetToPhysicalNetAddress InetAddress, ipNetToPhysicalPhysAddress PhysAddress, ipNetToPhysicalLastUpdated TimeStamp, ipNetToPhysicalType INTEGER, ipNetToPhysicalState INTEGER, ipNetToPhysicalRowStatus RowStatus } ipNetToPhysicalLastUpdated OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime at the time this entry was last updated. If this entry was updated prior to the last re- initialization of the local network management subsystem, then this object contains a zero value." ::= { ipNetToPhysicalEntry 5 } The only piece of information not captured in the YANG model that I noticed is the ipNetToPhysicalLastUpdated. That is why I asked about it being intentionally left out versus accidentally. > > *Nits:* > > > > I've put these as nits because I think that they are probably textual > > errors rather than intentional... > > > > > > 1. ipv6/forwarding: why is the reference RFC 4861 - neighbor > > discovery??? That seems like it applies to the neighbor info, unless > I've > > misunderstood what ipv6/forwarding is doing... > > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the > interface, not to the neighbor. This object is defined as: > > A flag indicating whether routing is enabled on > this interface. Enabling routing on the interface > would imply that a router can forward packets to or > from the interface. > > (The neighbor cache also tags each neighbor as being a router or not). > [Alia] Ok - but a reference to the RFC for neighbor discovery is really not clear when all you are talking about is whether the interface routes packets or not. PLEASE either add a more specific reference to the section or otherwise clarify. I do think that the text changes we discussed above will help also. > > > 2. In the second table in Sec 3, ipv4/neighbor/interface and > > ipv6/neighbor/interface are listed, but I don't see them in state > tree in > > Sec 2. I think that's because they aren't necessary?? > > No this is a bug - I forgot to remove these when we changed the data > model at some time. Thanks for spotting it! [Alia] Another pair of eyes :-) Glad to help. Sorry for the delayed response, Alia --bcaec50b4bde0b2bf404f1459bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Responses in-line.


<= div class=3D"gmail_quote">On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund= <= mbj@tail-f.com> wrote:
Hi,

Alia Atlas <akatlas@gmail.com&g= t; wrote:
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draf= t.
> The Routing Directorate seeks to review all routing or routing-related=
> drafts as they pass through IETF last call and IESG review. The purpos= e 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-netmod-ip-cfg-12.txt
> Reviewer: Alia Atlas
> Review Date: 22 January 2014
> IETF LC End Date: 23 January 2014
> Intended Status: Proposed Standard
>
> *Summary:*
> I have a few minor concerns about this document (cla= rifying a few aspects)
> that I think should be resolved before publication.
>
> *Comments:*
> This document is very clearly written, but I did fin= d a few details that
> could use a bit more clarity.  I was able to figure out what was = intended
> by wandering through the referenced RFCs.
>
> *Major Issues:*
> No major issues found.
>
> *Minor Issues:*
>
>
>    1. ipv4/forwarding and ipv6/forwarding:  First, I wa= sn't sure what this
>    meant or how it was different from ipv4= /enable or ipv6/enable.   I went
>    back to look at RFC 4293 to learn that ipv4/forwarding me= ans “acting as a
>    router and forwarding traffic not destined to the device&= rdquo;.  Could you
>    clarify the text to add those key details into the descri= ption for
>    ipv4/forwarding and ipv6/forwarding?

I think this probably becomes more clear if we clarify the "enab= led"
leaf as you suggest below in (2).  With the suggested new text below maybe this "forwarding" leaf is ok?  Otherwise, we could wri= te in the
style of 4293:

OLD:

          "Controls if IPv4 packet forwarding= is enabled or disabled
           on this interface.";

NEW:

          "Controls IPv4 packet forwarding of= datagrams received by,
           but not addressed to, this interfa= ce.  IPv4 routers forward
           datagrams.  IPv4 hosts do not= (except those source-routed
           via the host)";
[Alia] Perfect 

>    Second, I was surprised that the
>    default is false; I think about this from the router pers= pective, of
>    course, but a bit of explanation as to why that decision = was made would be
>    useful.

The conceptual variable IsRouter, defined in RFC 4861, has FALSE as its default value.  (see more below).

[Alia] That's fine.
=
 
>    2. ipv4/enabled and ipv6/enabled:  Similarly, what i= s enabled by
>    ipv4/enabled isn’t clear (unless I look at RFC 4293= ).   Could you clarify
>    that it means connected to an IPv4 stack for sending out = IPv4 packets and
>    for receiving to-me packets and do the same clarification= for ipv6/enabled?

Would this work?

OLD:

          "Controls if IPv6 is enabled or dis= abled on this
           interface.";

NEW:

          "Controls if IPv6 is enabled or dis= abled on this
           interface.  When IPv6 is enab= led, this interface is
           connected to an IPv6 stack, and th= e interface can send
           and receive IPv6 packets.";
[Alia] Sounds great - same for IPv4? 


>    3. ipv4/mtu and ipv6/mtu:  This is discussing sendin= g and receiving
>    packets – a mention of the MRU wo= uld be useful and even quoting  RFC2460 in
>    Sec 5 which says “From each link to which a node is= directly attached,
>    the node must be  able to accept packets as large as= that link's MTU. “
>    so it’s clear.

Hmm, the current text says:

        "The size, in octets, of the largest IPv6 = packet that the
         interface will send and receive.

Isn't it clear that it applies also to the size of received packets? Or maybe I misunderstood your concern?

= [Alia] MRU and MTU do not need to be the same thing.  The current text= assumes that it is - and I agree that is a common way of configuring both = in a single move.  I was just looking for a bit more clarity that you = really do mean MRU as well.  It's not something that I feel strong= ly about. 

>    4.  For the ARP cache (ipv4/neighbor) and ND cache (= ipv6/neighbor), is
>    there a reason that lastUpdated isn&rsq= uo;t included?  This doesn’t seem to
>    provide quite enough information to see whenr mappings we= re last updated?
>    Is the assumption that there will be a ARP specific and N= D specific YANG
>    model for getting the details?

No, the intention is that this model should be sufficient.

There is not such "last updated" object defined in RFC 4861. &nbs= p;Also, it
seems this information is not available in some implementations (not
in linux).   Do other implementation typcially store this info?  = If
so, in what form?

[Alia] I was looking = at RFC 4293 and your table of comparison of objects between this YANG model= and that MIB.  If you look at the MIB, it has the following:

IpNetToPhysicalEntry ::=3D SEQUENCE {
        ipNetToPhysicalIfIndex         InterfaceIndex,
        ipNetToPhysicalNetAddressType  InetAddressType,
        ipNetToPhysicalNetAddress      InetAddress,
        ipNetToPhysicalPhysAddress     PhysAddress,
        ipNetToPhysicalLastUpdated     TimeStamp,
        ipNetToPhysicalType            INTEGER,
        ipNetToPhysicalState           INTEGER,
        ipNetToPhysicalRowStatus       RowStatus
    }


ipNetToPhysicalLastUpdated OBJECT-TYPE
    SYNTAX     TimeStamp
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
           "The value of sysUpTime at the time this entry was last
            updated.  If this entry was updated prior to the last re-
            initialization of the local network management subsystem,
            then this object contains a zero value."
    ::=3D { ipNetToPhysicalEntry 5 }


The only pie= ce of information not captured in the YANG model that I noticed is the ipNe= tToPhysicalLastUpdated.

That is why I asked about it being intentionally left o= ut versus accidentally.
 
> *Nits:*
>
> I've put these as nits because I think that they are probably text= ual
> errors rather than intentional...
>
>
>    1.  ipv6/forwarding:   why is the referen= ce RFC 4861 – neighbor
>    discovery???  That seems like it a= pplies to the neighbor info, unless I’ve
>    misunderstood what ipv6/forwarding is doing…

Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the
interface, not to the neighbor.  This object is defined as:

                     = ;A flag indicating whether routing is enabled on
                     = ;this interface.  Enabling routing on the interface
                     = ;would imply that a router can forward packets to or
                     = ;from the interface.

(The neighbor cache also tags each neighbor as being a router or not).
<= /blockquote>
[Alia] Ok - but a reference to the RFC for neighbor discov= ery is really not clear when all you are talking about is whether the inter= face routes packets or not.  PLEASE either add a more specific referen= ce to the section or otherwise clarify.  I do think that the text chan= ges we discussed above will help also. 
 

>    2. In the second table in Sec 3, ipv4/neighbor/interface = and
>    ipv6/neighbor/interface are listed, but= I don’t see them in state tree in
>    Sec 2.  I think that’s because they aren&rsquo= ;t necessary??

No this is a bug - I forgot to remove these when we changed the data<= br> model at some time.  Thanks for spotting it!

[Alia] Another pair of eyes :-)  Glad to help.

Sorry for the delayed response,
Alia 
--bcaec50b4bde0b2bf404f1459bb4-- From mbj@tail-f.com Fri Jan 31 08:40:47 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848911A0367; Fri, 31 Jan 2014 08:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TayvOFvDebmU; Fri, 31 Jan 2014 08:40:46 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 06E401A035D; Fri, 31 Jan 2014 08:40:46 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 8E3CD240C58A; Fri, 31 Jan 2014 17:40:41 +0100 (CET) Date: Fri, 31 Jan 2014 17:40:41 +0100 (CET) Message-Id: <20140131.174041.236982788.mbj@tail-f.com> To: akatlas@gmail.com From: Martin Bjorklund In-Reply-To: References: <20140125.151847.09968453.mbj@tail-f.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org, netmod@ietf.org, rtg-ads@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 16:40:47 -0000 Alia Atlas wrote: > Responses in-line. > > > On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund wrote: > > > Hi, > > > > Alia Atlas wrote: [...] > > > 2. ipv4/enabled and ipv6/enabled: Similarly, what is enabled by > > > ipv4/enabled isn't clear (unless I look at RFC 4293). Could you > > clarify > > > that it means connected to an IPv4 stack for sending out IPv4 packets > > and > > > for receiving to-me packets and do the same clarification for > > ipv6/enabled? > > > > Would this work? > > > > OLD: > > > > "Controls if IPv6 is enabled or disabled on this > > interface."; > > > > NEW: > > > > "Controls if IPv6 is enabled or disabled on this > > interface. When IPv6 is enabled, this interface is > > connected to an IPv6 stack, and the interface can send > > and receive IPv6 packets."; > > > [Alia] Sounds great - same for IPv4? Yes. > > > 1. ipv6/forwarding: why is the reference RFC 4861 - neighbor > > > discovery??? That seems like it applies to the neighbor info, unless > > I've > > > misunderstood what ipv6/forwarding is doing... > > > > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the > > interface, not to the neighbor. This object is defined as: > > > > A flag indicating whether routing is enabled on > > this interface. Enabling routing on the interface > > would imply that a router can forward packets to or > > from the interface. > > > > (The neighbor cache also tags each neighbor as being a router or not). > > > [Alia] Ok - but a reference to the RFC for neighbor discovery is really not > clear when all you are talking about is whether the interface routes > packets or not. PLEASE either add a more specific reference to the section > or otherwise clarify. I do think that the text changes we discussed above > will help also. The current reference is: container ipv6 { ... leaf forwarding { ... reference "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) Section 6.2.1, IsRouter"; } } I hope this is specific enough? /martin From akatlas@gmail.com Fri Jan 31 08:50:13 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93F01A0420; Fri, 31 Jan 2014 08:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RrwsvhLSte1c; Fri, 31 Jan 2014 08:50:12 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1C1A03F5; Fri, 31 Jan 2014 08:50:12 -0800 (PST) Received: by mail-yk0-f171.google.com with SMTP id 142so24737086ykq.2 for ; Fri, 31 Jan 2014 08:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QAJzVOuwbqOGHYll+roXr48EBka2EY9kztnxTXyAreE=; b=SWqsbUiApm5vUi9zoQ4HgDXwjts5Wx+vF/bSA+Qjllg2O0gZ8tSOyho7Owr0VspeJJ lKXo/lm18e7D04Kq6+64gjk5HMB2C30Yr8SB/BhzS3aAHCwpc4JkXzNL8YMeAeH+yMTk z9MhYHWH8R4yDPrVDYC9kTCQKz0nOI7rmgMT0ezX95Sra+dC5ghtnZhpVwnl/RbESHTU LW+OPKbabitWk+P/YfSASNExuE+9Ljt3IxL5I5BBFboc/LGfI7YCzcexKV29qZFOAJPH gKBiDvMV6iBxRQrMNMBr7WFEusEzlj9XgjxfosZTQ4szKsrMx+hyvq9sUZ8/mDcMZG0R MBCQ== MIME-Version: 1.0 X-Received: by 10.236.88.75 with SMTP id z51mr1842163yhe.109.1391187008276; Fri, 31 Jan 2014 08:50:08 -0800 (PST) Received: by 10.170.186.88 with HTTP; Fri, 31 Jan 2014 08:50:08 -0800 (PST) In-Reply-To: <20140131.174041.236982788.mbj@tail-f.com> References: <20140125.151847.09968453.mbj@tail-f.com> <20140131.174041.236982788.mbj@tail-f.com> Date: Fri, 31 Jan 2014 11:50:08 -0500 Message-ID: From: Alia Atlas To: Martin Bjorklund Content-Type: multipart/alternative; boundary=bcaec544ed6871ce6104f146f7c7 Cc: "rtg-dir@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org, "netmod@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 16:50:14 -0000 --bcaec544ed6871ce6104f146f7c7 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 31, 2014 at 11:40 AM, Martin Bjorklund wrote: > Alia Atlas wrote: > > Responses in-line. > > > > > > On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund > wrote: > > > > > Hi, > > > > > > Alia Atlas wrote: > > [...] > > > > > 2. ipv4/enabled and ipv6/enabled: Similarly, what is enabled by > > > > ipv4/enabled isn't clear (unless I look at RFC 4293). Could you > > > clarify > > > > that it means connected to an IPv4 stack for sending out IPv4 > packets > > > and > > > > for receiving to-me packets and do the same clarification for > > > ipv6/enabled? > > > > > > Would this work? > > > > > > OLD: > > > > > > "Controls if IPv6 is enabled or disabled on this > > > interface."; > > > > > > NEW: > > > > > > "Controls if IPv6 is enabled or disabled on this > > > interface. When IPv6 is enabled, this interface is > > > connected to an IPv6 stack, and the interface can send > > > and receive IPv6 packets."; > > > > > [Alia] Sounds great - same for IPv4? > > Yes. > > > > > 1. ipv6/forwarding: why is the reference RFC 4861 - neighbor > > > > discovery??? That seems like it applies to the neighbor info, > unless > > > I've > > > > misunderstood what ipv6/forwarding is doing... > > > > > > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the > > > interface, not to the neighbor. This object is defined as: > > > > > > A flag indicating whether routing is enabled on > > > this interface. Enabling routing on the interface > > > would imply that a router can forward packets to > or > > > from the interface. > > > > > > (The neighbor cache also tags each neighbor as being a router or not). > > > > > [Alia] Ok - but a reference to the RFC for neighbor discovery is really > not > > clear when all you are talking about is whether the interface routes > > packets or not. PLEASE either add a more specific reference to the > section > > or otherwise clarify. I do think that the text changes we discussed > above > > will help also. > > The current reference is: > > container ipv6 { > ... > leaf forwarding { > ... > reference > "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) > Section 6.2.1, IsRouter"; > } > } > > I hope this is specific enough? > [Alia] Yes - sorry - should have double-checked the draft again.. Alia > > > > /martin > --bcaec544ed6871ce6104f146f7c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 31, 2014 at 11:40 AM, Martin Bjorklund <mbj@tail-f.com>= wrote:
Alia Atlas <akatlas@gmail.com> wrote:
> Responses in-line.
>
>
> On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Hi,
> >
> > Alia Atlas <akatlas@gmail= .com> wrote:

[...]

> > > =A0 =A02. ipv4/enabled and ipv6/enabled: =A0Similarly, what = is enabled by
> > > =A0 =A0ipv4/enabled isn't clear (unless I look at RFC 42= 93). =A0 Could you
> > clarify
> > > =A0 =A0that it means connected to an IPv4 stack for sending = out IPv4 packets
> > and
> > > =A0 =A0for receiving to-me packets and do the same clarifica= tion for
> > ipv6/enabled?
> >
> > Would this work?
> >
> > OLD:
> >
> > =A0 =A0 =A0 =A0 =A0 "Controls if IPv6 is enabled or disabled= on this
> > =A0 =A0 =A0 =A0 =A0 =A0interface.";
> >
> > NEW:
> >
> > =A0 =A0 =A0 =A0 =A0 "Controls if IPv6 is enabled or disabled= on this
> > =A0 =A0 =A0 =A0 =A0 =A0interface. =A0When IPv6 is enabled, this i= nterface is
> > =A0 =A0 =A0 =A0 =A0 =A0connected to an IPv6 stack, and the interf= ace can send
> > =A0 =A0 =A0 =A0 =A0 =A0and receive IPv6 packets.";
> >
> [Alia] Sounds great - same for IPv4?

Yes.

> > > =A0 =A01. =A0ipv6/forwarding: =A0 why is the reference RFC 4= 861 - neighbor
> > > =A0 =A0discovery??? =A0That seems like it applies to the nei= ghbor info, unless
> > I've
> > > =A0 =A0misunderstood what ipv6/forwarding is doing...<= br>
> >
> > Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the=
> > interface, not to the neighbor. =A0This object is defined as:
> >
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0A flag indicating whet= her routing is enabled on
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0this interface. =A0Ena= bling routing on the interface
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0would imply that a rou= ter can forward packets to or
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0from the interface. > >
> > (The neighbor cache also tags each neighbor as being a router or = not).
> >
> [Alia] Ok - but a reference to the RFC for neighbor discovery is reall= y not
> clear when all you are talking about is whether the interface routes > packets or not. =A0PLEASE either add a more specific reference to the = section
> or otherwise clarify. =A0I do think that the text changes we discussed= above
> will help also.

The current reference is:

=A0 =A0 container ipv6 {
=A0 =A0 =A0 ...
=A0 =A0 =A0 leaf forwarding {
=A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0 reference
=A0 =A0 =A0 =A0 =A0 "RFC 4861: Neighbor Discovery for IP version 6 (IP= v6)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Section 6.2.1, IsRouter"; =A0 =A0 =A0 }
=A0 =A0 }

I hope this is specific enough?
[Alia] Yes - sorry - s= hould have double-checked the draft again..

Alia
=A0



/martin

--bcaec544ed6871ce6104f146f7c7-- From lhotka@nic.cz Fri Jan 31 07:41:11 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E42C1A0522; Fri, 31 Jan 2014 07:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS85gG5gbUZf; Fri, 31 Jan 2014 07:41:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id BED2A1A03F5; Fri, 31 Jan 2014 07:41:10 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 56DCA14014E; Fri, 31 Jan 2014 16:41:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391182866; bh=IwtHjqDdKC755ht30afYFTbyGAG18gR7UJh/D2IfRkU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=qDeP6sDhM330IAmTKWVFMMM/299uZP4cSkdoJk+yHm9thMDnXtz1nCUIexc8vatLg pnxqVB4fWiOMcpZxbyeUkx7gyk8ZRU5AQlxz+6hSsLhELWO3nFkMh26x5p61JLYwOj o9FdTIGGKp6ln7P/z1XOWpzmetqujOHtbHII1TJM= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 31 Jan 2014 16:41:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E60D80A-7F2C-491E-9F5D-BC892E719E92@nic.cz> References: <20140125.151847.09968453.mbj@tail-f.com> To: Alia Atlas X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 31 Jan 2014 09:47:15 -0800 Cc: "rtg-dir@ietf.org" , =?windows-1252?Q?Martin_Bj=F6rklund?= , "rtg-ads@tools.ietf.org" , "netmod@ietf.org" , draft-ietf-netmod-ip-cfg@tools.ietf.org Subject: Re: [RTG-DIR] [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 15:41:11 -0000 On 31 Jan 2014, at 16:12, Alia Atlas wrote: > > 1. ipv4/forwarding and ipv6/forwarding: First, I wasn't sure = what this > > meant or how it was different from ipv4/enable or ipv6/enable. = I went > > back to look at RFC 4293 to learn that ipv4/forwarding means = =93acting as a > > router and forwarding traffic not destined to the device=94. = Could you > > clarify the text to add those key details into the description = for > > ipv4/forwarding and ipv6/forwarding? >=20 > I think this probably becomes more clear if we clarify the "enabled" > leaf as you suggest below in (2). With the suggested new text below > maybe this "forwarding" leaf is ok? Otherwise, we could write in the > style of 4293: >=20 > OLD: >=20 > "Controls if IPv4 packet forwarding is enabled or disabled > on this interface."; >=20 > NEW: >=20 > "Controls IPv4 packet forwarding of datagrams received by, > but not addressed to, this interface. IPv4 routers forward > datagrams. IPv4 hosts do not (except those source-routed > via the host)"; > [Alia] Perfect=20 >=20 This description then might also mention that this leaf has specific = implications for the =93ietf-routing=94 module, see sec. 6.2 in = draft-ietf-netmod-routing-cfg-13. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From lhotka@nic.cz Fri Jan 31 08:54:46 2014 Return-Path: X-Original-To: rtg-dir@ietfa.amsl.com Delivered-To: rtg-dir@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6086D1A0522; Fri, 31 Jan 2014 08:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8qRbUvjt7cF; Fri, 31 Jan 2014 08:54:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE71A0448; Fri, 31 Jan 2014 08:54:44 -0800 (PST) Received: from [172.29.2.201] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id C6E8013FACA; Fri, 31 Jan 2014 17:54:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391187280; bh=6KxLND7Q2TCqn9+EInPNTz9h0rK9B4EQw0u2qdKTtUI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s6xTylYW8eMHUfYQAc4hmXA3/4r+FEXY2KhJwdcqf9S7Gcjy67TEAmF6QQrDQcO6i z0uRoDuwGaqtoPro/IRxARoThS6c/tJ6hMoyrfsv7TZZfYkezkptNMjiq41LL944hU z650BOopTFEnVj2ZU5NWbMGchS/wb33sTTJsZ/3M= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: <20140131.174041.236982788.mbj@tail-f.com> Date: Fri, 31 Jan 2014 17:54:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9BD3F9E8-2BB5-42F4-8F64-41EDDB7FFC32@nic.cz> References: <20140125.151847.09968453.mbj@tail-f.com> <20140131.174041.236982788.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 31 Jan 2014 09:47:17 -0800 Cc: rtg-dir@ietf.org, draft-ietf-netmod-ip-cfg@tools.ietf.org, rtg-ads@tools.ietf.org, netmod@ietf.org, Alia Atlas Subject: Re: [RTG-DIR] [netmod] RtgDir review: draft-ietf-netmod-ip-cfg-12 X-BeenThere: rtg-dir@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Routing Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jan 2014 16:54:46 -0000 On 31 Jan 2014, at 17:40, Martin Bjorklund wrote: > Alia Atlas wrote: >> Responses in-line. >>=20 >>=20 >> On Sat, Jan 25, 2014 at 9:18 AM, Martin Bjorklund = wrote: >>=20 >>> Hi, >>>=20 >>> Alia Atlas wrote: >=20 > [...] >=20 >>>> 2. ipv4/enabled and ipv6/enabled: Similarly, what is enabled by >>>> ipv4/enabled isn't clear (unless I look at RFC 4293). Could you >>> clarify >>>> that it means connected to an IPv4 stack for sending out IPv4 = packets >>> and >>>> for receiving to-me packets and do the same clarification for >>> ipv6/enabled? >>>=20 >>> Would this work? >>>=20 >>> OLD: >>>=20 >>> "Controls if IPv6 is enabled or disabled on this >>> interface."; >>>=20 >>> NEW: >>>=20 >>> "Controls if IPv6 is enabled or disabled on this >>> interface. When IPv6 is enabled, this interface is >>> connected to an IPv6 stack, and the interface can send >>> and receive IPv6 packets."; >>>=20 >> [Alia] Sounds great - same for IPv4? >=20 > Yes. >=20 >>>> 1. ipv6/forwarding: why is the reference RFC 4861 - neighbor >>>> discovery??? That seems like it applies to the neighbor info, = unless >>> I've >>>> misunderstood what ipv6/forwarding is doing... >>>=20 >>> Actually, the object IsRouter in 6.2.1 in RFC 4861 applies to the >>> interface, not to the neighbor. This object is defined as: >>>=20 >>> A flag indicating whether routing is enabled on >>> this interface. Enabling routing on the = interface >>> would imply that a router can forward packets to = or >>> from the interface. >>>=20 >>> (The neighbor cache also tags each neighbor as being a router or = not). >>>=20 >> [Alia] Ok - but a reference to the RFC for neighbor discovery is = really not >> clear when all you are talking about is whether the interface routes >> packets or not. PLEASE either add a more specific reference to the = section >> or otherwise clarify. I do think that the text changes we discussed = above >> will help also. >=20 > The current reference is: >=20 > container ipv6 { > ... > leaf forwarding { > ... > reference > "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) > Section 6.2.1, IsRouter"; > } > } >=20 > I hope this is specific enough? I think it is. The other router configuration parameters that are = specified in that 4861 section are dealt with in the = =93ietf-ipv6-unicast-routing=94 module - perhaps it would be useful to = mention this in the description, too. Lada >=20 >=20 >=20 > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C