Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use
David Allan I <david.i.allan@ericsson.com> Wed, 23 January 2013 18:43 UTC
Return-Path: <david.i.allan@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE4F21F8790 for <mpls@ietfa.amsl.com>; Wed, 23 Jan 2013 10:43:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHGBkxbeLpLR for <mpls@ietfa.amsl.com>; Wed, 23 Jan 2013 10:43:17 -0800 (PST)
Received: from usevmg21.ericsson.net (unknown [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id F198B21F871F for <mpls@ietf.org>; Wed, 23 Jan 2013 10:43:16 -0800 (PST)
X-AuditID: c6180641-b7f926d000000e79-31-51002f439787
Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5C.52.03705.34F20015; Wed, 23 Jan 2013 19:43:16 +0100 (CET)
Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0318.004; Wed, 23 Jan 2013 13:43:15 -0500
From: David Allan I <david.i.allan@ericsson.com>
To: "curtis@occnc.com" <curtis@occnc.com>
Thread-Topic: MPLS-RT review of draft-villamizar-mpls-multipath-use
Thread-Index: AQHN+RLRhjn59v73gkmIPrV6gzHbXZhXO2uA
Date: Wed, 23 Jan 2013 18:43:15 +0000
Message-ID: <E6C17D2345AC7A45B7D054D407AA205C051BBD@eusaamb105.ericsson.se>
References: Your message of "Thu, 17 Jan 2013 14:45:06 GMT." <E6C17D2345AC7A45B7D054D407AA205C04F53E@eusaamb105.ericsson.se> <201301230238.r0N2cvFh068921@gateway1.orleans.occnc.com>
In-Reply-To: <201301230238.r0N2cvFh068921@gateway1.orleans.occnc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.134]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPgq6LPkOgQV8/u8XhA9PZLf7NncNs cWfXF1aL75eWsFjcWrqS1YHVo/XZXlaPJUt+Mnks/uLnMWt6G5vHl8uf2QJYo7hsUlJzMstS i/TtErgyXrycy1Lw1rVixeG5zA2MC826GDk5JARMJJqPH2WFsMUkLtxbz9bFyMUhJHCEUaKl 9ywzSEJIYDmjRN+SLBCbTcBAYs//L4wgtoiApsTfSZvZQWxmga2MEqt3iILYwgJOEt8Wz2aC qHGW6Dn6EqreSOLMv2MsIDaLgKrE02e7gWwODl4Bb4n7Czkh9h5llHhwdgfYXk4BV4kzU9eA HccIdNz3U2uYIHaJS9x6Mp8J4mgBiSV7zjND2KISLx//g3pGWWLJk/0sEPU6Egt2f2KDsLUl li18DVbPKyAocXLmE5YJjGKzkIydhaRlFpKWWUhaFjCyrGLkKC1OLctNNzLcxAiMr2MSbI47 GBd8sjzEKM3BoiTOG+p6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD46xnrfp3Le+eTv68 2TksbnFhX6eEbmNe4fU5GsZxhbpyRvlVMVbOW0vlj1tdv3xnedXrOE8z1nt6dRdt8xyU+19k bKxlOBT2ZsXF78p/WS/N2i29/cYphlfbNxS6xX3KC351YG6NxI7jj1ctuXb7+wu9WdIVvcK+ 9VL9SayelvU2zu/59+VrK7EUZyQaajEXFScCACl46LF9AgAA
Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-multipath-use
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jan 2013 18:43:18 -0000
HI Curtis: Some snipping to help readability and replies prefixed by [Dave] <snipped> If it is unclear to you, then the document is not sufficiently clear and needs fixing. See below. [Dave] Great.... > Nit: > > Section 1 para 2: Refers to MPLS-TP packet ordering as the constraint. > I'm a bit confused by this, any aggregate that shares an ordering > constraint does not get spread across parallel links while a set of > traffic COULD be in theory load spread across a set of MPLS-TP paths > so long as individual ordering constraints were respected. Is this > text document really discussing midbox spreading out of load that > respects ordering constraints but would mean MPLS-TP OAM no longer > fate shared? Should be reworded if so. Clarified otherwise. Section 1 paragraph 2 contains: RFC 5654 requirement 33 requires the capability to carry a client MPLS-TP or MPLS layer over a server MPLS-TP or MPLS layer [RFC5654]. This is possible in all cases with one exception. When an MPLS LSP exceeds the capacity of any single component link it may be carried by a network using multipath techniques, but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints. The sentence in question is: When an MPLS LSP exceeds the capacity of any single component link it may be carried by a network using multipath techniques, but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints. Perhaps I could clarify this by changing "carried by an MPLS-TP LSP" to "carried by a single MPLS-TP LSP". The "MPLS-TP OAM packet ordering constraints" is the "fate sharing" which is the reason that MPLS-TP prohibits using ECMP (aka multipath, though ECMP is only one form of multipath) with MPLS-TP. This is why an MPLS LSP (client layer) with capacity greater than a component link cannot be carried over a *single* MPLS-TP LSP. Since this is explained in later sections I could make the substitution suggested above or I could drop the last sentence and mention that limitation later. [Dave] the sentence I had a problem with was "but may not be carried by an MPLS-TP LSP due to the inherent MPLS-TP capacity limitation imposed by MPLS-TP OAM packet ordering constraints." It is not an ordering constraint, it is a fate sharing constraint. It read fairly strangely to me as to what the problem was you were trying to expose. IMO the TP requirements are focused on both determinism of commitment of network resources for network planning & SLA purposes, and ability to fully and reliably instrument the connectivity. IMO multipath violates the latter, whether it violates the former would be a topic of debate unresolvable in the reality of LAG. LAG simply scoping the domain of uncertainty for OAM purposes to a link, and requiring extra link OAM and inheritance... [Dave] To make the discussion short, replacing "OAM packet ordering constraints" with "OAM fate sharing constraints" should be sufficient. > Main issue: > > Section 3: I think this needs a bit of work, it starts to discuss > tractable solutions but IMO is technically incomplete. IF an entropy > label and ELI (where all traffic associated with the MPLS_TP LSP > shares a common randomly selected entropy label value, which is not > stated) are the only mechanisms of ensuring proper treatment (with all > transit nodes implementing entropy and ELI processing such that > seeking sources of entropy is capped for such LSPs), and the ingress > node (which by some means SHOULD be able to know it is a TP LSP as it > has layer visibility) and the egress node can strip entropy and ELI > then a solution exists for proper fate sharing and ordering of a TP > LSP over MPLS. It is IMO not quiet eluciated completely. Your paragraph above describes the solution, but then says "It is IMO not quiet eluciated completely." [Dave] Well I know you and I know the solution, but someone newer to the subject would not necessarily be able to infer it from the document in its current state. So lets parse your paragraph and see what the draft is missing: > Section 3: I think this needs a bit of work, it starts to discuss > tractable solutions but IMO is technically incomplete. OK ... > IF an entropy label and ELI (where all traffic associated with the > MPLS_TP LSP shares a common randomly selected entropy label value, > which is not stated) You mention "IF an entropy label and ELI (where all traffic associated with the MPLS_TP LSP shares a common randomly selected entropy label value, which is not stated)". Regarding the "which is not stated" part of that phrase I can change the following paragraph: OLD: MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if an Entropy Label Indicator (ELI) and entropy label (EL) is added after the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. [...] NEW: MPLS-TP LSP can be carried as client LSP within an MPLS server LSP if an Entropy Label Indicator (ELI) and Entropy Label (EL) is added after the server layer LSP label(s) in the label stack, just above the MPLS-TP LSP label entry [RFC6790]. The value of EL can be randomly selected at LSP setup time and the same EL value used for all packets of the MPLS-TP LSP. [...] [Dave] That edit works for me. One sentence is added to the end. (and Entropy Label is capitalized). > are the only mechanisms of ensuring proper treatment Actually link-bundling is mentioned as another mechanism. > (with all transit nodes implementing entropy and ELI processing such > that seeking sources of entropy is capped for such LSPs), The requirement to terminate search for additional entropy below the EL is a requirement of RFC 6790. The intent is to say that non-compliant midpoint LSR would in this case cause packet order problems where in MPLS only (no TP carried) use of RFC 6790, those non-compliant midpoint LSR are tolerable as long as they can get enough entropy from the traffic to adequately load split. [Dave] Given the relative newness of 6790, I'm assuming some statement to the effect that this solution is not necessarily backwards compatible with existing deployments needs to be said. > and the ingress node (which by some means SHOULD be able to know it is > a TP LSP as it has layer visibility) That is discussed in the following paragraph: There is currently no signaling mechanism defined to support requirement MP#1. In the absense of a signaling extension, MPLS-TP can be identified through some form of configuration, such as configuration which provides an MPLS-TP compatible server layer to all LSP arriving on a specific interface or originating from a specific set of ingress LSR. Alternately an MPLS-TP LSP can be created with and Entropy Label Indicator (ELI) and entropy label (EL) below the MPLS-TP label [RFC6790]. Obviously the EL can be added at the MPLS-TP ingress LSR. This paragraph is considering the case where a set of MPLS-TP LSR are not EL capable but also do not have multipath enabled, but multipath is enabled elsewhere (ie: the core where lots of traffic needs to get aggregated into a smaller number of LSP). The lack of a signaling extension is noted as a (fixable) limitation. The fix comes in a later draft (draft-villamizar-mpls-multipath-extn). > and the egress node can strip entropy and ELI That is a hard requirement of RFC 6790 for an LSR claiming to support RFC 6790. > then a solution exists for proper fate sharing and ordering of a TP > LSP over MPLS. OK ... agreed. > It is IMO not quiet eluciated completely. You seem to have figured out all of the details. If there are additional clarifications that are needed besides the ones suggested above, please point out what details of the solution are still not clear in the existing text. > If I'm unclear on any of the above, am happy to discuss... Thanks. Please let me know if the above clarifications are sufficient or whether additional clarifications are needed. [Dave] I think with the change of ordering constraint to fate sharing constraint in section 1, the EL "fixed value" addition and some disclaimer about 6790 support in the MPLS network, I would be happy. I'm clearer on what you were saying. Best Dave
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… David Allan I
- [mpls] MPLS-RT review of draft-villamizar-mpls-mu… Carlos Pignataro (cpignata)
- [mpls] MPLS-RT review of draft-villamizar-mpls-mu… Mach Chen
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… David Allan I
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… David Allan I
- [mpls] minor clarification (was Re: MPLS-RT revie… Curtis Villamizar
- Re: [mpls] minor clarification (was Re: MPLS-RT r… Carlos Pignataro (cpignata)
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Carlos Pignataro (cpignata)
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… David Allan I
- [mpls] ref to rtgwg (was Re: MPLS-RT review of dr… Curtis Villamizar
- Re: [mpls] ref to rtgwg (was Re: MPLS-RT review o… Carlos Pignataro (cpignata)
- Re: [mpls] minor clarification (was Re: MPLS-RT r… Curtis Villamizar
- Re: [mpls] MPLS-RT review of draft-villamizar-mpl… Markus Jork