Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt)
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 18 March 2014 10:50 UTC
Return-Path: <adrian@olddog.co.uk>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47CB81A06D6 for <pce@ietfa.amsl.com>; Tue, 18 Mar 2014 03:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.783
X-Spam-Level:
X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, USER_IN_WHITELIST=-100] 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 QxluSmpK0Cto for <pce@ietfa.amsl.com>; Tue, 18 Mar 2014 03:50:25 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id D7D291A06D5 for <pce@ietf.org>; Tue, 18 Mar 2014 03:50:24 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2IAnfC2020352; Tue, 18 Mar 2014 10:49:41 GMT
Received: from 950129200 (108.26.90.92.rev.sfr.net [92.90.26.108]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2IAnXvi020212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 10:49:40 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dhruv.dhody@huawei.com>, pce@ietf.org
References: <20140206112220.911.91885.idtracker@ietfa.amsl.com> <013e01cf232e$d24a0d90$76de28b0$@olddog.co.uk> <CAB75xn4wdFd81RWQ9XjOUKBT+Ag1vSUrrXbcGFQ34N9nTyEF4Q@mail.gmail.com> <268e01cf4162$c4d68fb0$4e83af10$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548BAF@szxeml556-mbs.china.huawei.com> <277201cf41d5$b934d2c0$2b9e7840$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B75548F62@szxeml556-mbs.china.huawei.com>
In-Reply-To: <23CE718903A838468A8B325B80962F9B75548F62@szxeml556-mbs.china.huawei.com>
Date: Tue, 18 Mar 2014 10:49:33 -0000
Message-ID: <013201cf4297$c4021740$4c0645c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNBTAKt13E+qb+7zl793QfaTCZ0wQHZAZ2OAhNqv0oB1xANVQJi0xgoAXB+QJACn46nhZeg2uGg
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20572.005
X-TM-AS-Result: No--39.250-10.0-31-10
X-imss-scan-details: No--39.250-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkAQoD+Lr/yRKZRrnSy7UTtbGSqdEmeD/nXloWjcIeMYgEg9 oIEl5+XgUr9+KuqT2ToMMV3HqxQ6enbjKtRz1M+cxZQoGMRGhhOJ7IEVMTX5x3+0T1ghSvBi5JG tNdr1AhL9pAoscc8kOSnXcFDijwlhfh0BByKSGpOq/ikd9cQmyoEcpMn6x9cZAsunKi0r0b0s8m 1alsmNjYAhuGjJHHyx92ILRMoZN4jfnSLAINKHpi1ei6Dp41mZrLALtod6A6ZI51QyNYVlzskJK MRi4d1cmGIurjuZF5LRyt/Bmr4z8y9FtW7XfHue4nbwqqmOd2mM45JzjPlCaGTld3DbJ1CGyw44 3rwzxPFBFoT14xygSYOzbiG14BOfBR2X5okNNieVjmqvt/p8cp7wR6/2hZzOQ7roRC02qf4lncP TMo+HsSnu9YXs3Agu8snJNwZXAFw0iX4rUaqaeFZ0E+oA5pdVRtu4vtjjtzT52q+ftoTEiLkLNC KogPuNm2R53H/e4SvN3Gz877gbKd15COo1l2N0KWuiyZLRI4A2fwiaBZgD/H3hz57t9YhwgLvKb EFwC52GH7MO6imm4qr/6KM/dG1WDD8u5q9hbJhCnGIuUMP0VQiN6fibvJqqbcPp/oilssifQtB4 GOTvtmL8hHLA3GV3cP5AwFk+RM4cbXO7OGqBZ5rOCW59mY6Hbv16+gil4je7+NPPxj+R6syUvqm DPNmK01CjbbHk5lB9BWsmcYRmLbttu4oRBU6hdXz3l78F3YmBjLzL4do+VhKAWnKBwBf/Bk+/r+ IFkv7zPO4XyfvAQ/1tkEcsYqG43QUmX3MxclSeAiCmPx4NwGNn8XPiALIbYO2CFMU1sNcqtq5d3 cxkNQP90fJP9eHt
Archived-At: http://mailarchive.ietf.org/arch/msg/pce/6usN6Jpeb1PM1s1DpYXSsQyCyB8
Subject: Re: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Mar 2014 10:50:28 -0000
Dhruv, How right you are: a decision is needed and the WG should discuss it. I suspect it will not help us to quote one draft or another, because we are trying to converge on consensus from a variety of work-in-progress documents. *The* crunch from my perspective is whether a PCE is a provisioning source or not. Please note that this is a very different question from whether PCEP can be used as a provisioning protocol. RFC 4655 has: PCE: Path Computation Element. An entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints. The debate, I suppose, is about whether we stick with that definition, or broaden it. I would personally prefer to draw boxes around functional components. Thus, from my point of view, what is being discussed is a variant of Figure 5 from RFC 4655. In that variant, the PCE is a component of the NMS, and the NMS uses PCEP as the service request protocol. This vision keeps the concept of a PCE as a simple computation engine, and allows all of the rest of the function as before. One might draw the following ASCII Art... <font non-proportional> ----------------------------------- | ------ ----- | | NMS |LSP-DB| | TED |<-+-----------> | / ------ ----- | TED synchronization | -------------/ | | | mechanism (for example, | | LSP | | | | routing protocol) | | Coordinator | v v | | | | -------------- | | | |-| PCE | | | ------------- -------------- | | | | | | --------------------------- | | | PCEP Protocol Engine | | | --------------------------- | | | A | | | | | -------+-----+--------------------- Provisioning | |Computation Request | |Request/Response V V ---------- Signaling ---------- | Head-End | Protocol | Adjacent | | Node |<------------->| Node | ---------- ---------- </font> Now, draft-ietf-pce-pce-initiated-lsp currently says... A PCC or PCE indicates its ability to support PCE provisioned dynamic LSPs And I think this is a little confused. I think it is referring to the use of PCEP for provisioning LSPs. Maybe I am splitting hairs, or maybe I am trying to ensure that new work remains consistent with the architecture without preventing any of the new work. In my opinion the use of terms in the new work has conflated what we implement and sell as a PCE (wonderful, glowing marketing term), and what the functional components are. This debate as one of the primary reasons why I started draft-ietf-pce-questions, so I would clearly like to see it resolved. Thanks, Adrian From: Pce [mailto:pce-bounces@ietf.org] On Behalf Of Dhruv Dhody Sent: 18 March 2014 06:24 To: pce@ietf.org Subject: [Pce] Terminology for PCE-Initiated LSP (Was I-D Action: draft-ietf-pce-questions-02.txt) WG, Regarding PCE-Initiated LSP (1) http://tools.ietf.org/html/draft-ietf-pce-questions-04#section-20 use the term suggest or recommend LSP and considers LSP Instantiation as out of scope. (2) http://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-00 http://tools.ietf.org/html/draft-ali-pce-remote-initiated-gmpls-lsp-03 (WG -00 yet to be posted) http://tools.ietf.org/html/draft-palle-pce-stateful-pce-initiated-p2mp-lsp-01 all use the term LSP instantiation for PCE-Initiated LSP. We need to come to some consensus regarding this and use the same terminology across WG documents. Thoughts? Dhruv --------------------------------------------------------------- Dhruv Dhody System Architect, Huawei Technologies India Pvt. Ltd., Banagalore This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Adrian Farrel [mailto:adrian@olddog.co.uk] Sent: 17 March 2014 17:11 To: Dhruv Dhody Cc: pce@ietf.org; 'Dhruv Dhody' Subject: RE: [Pce] I-D Action: draft-ietf-pce-questions-02.txt Sorry for the HTML, but I am hoping this thread can be closed soon You're killing me :-) Hoping you are not red/green colourblind. Look in line for [DD]. [Snipped to only the points for discussion] * Sec 5. How Do I Select Between PCEs? Along with capability, you can also mention the PCE's preference for each computation scope as carried in the PATH-SCOPE subtlv. You are going to have to remind me, I'm afraid. Where is the PATH-SCOPE subtlv defined? I suppose I was considering that a PCC is only going to choose a PCE in its own domain, but I can add a note. [DD] Its in RFC5088, 5089, the idea being PCC should select the PCE in its own domain which matches with the path computation scope (inter-area, inter-AS, inter-layer) along with the capability. Ah, ah, ah! I was busy thinking this was a PCEP sub-tlv. OLD: When more then one PCE is discovered or configured, a PCC will need to select which PCE to use. It may make this decision on any arbitrary algorithm (for example, first-listed, or round-robin), but it may also be the case that different PCEs have different capabilities, in which case the PCC will want to select the PCE most likely to be able to satisfy any one request. The first requirement, of course, is that the PCE can compute paths for the relevant domain. NEW: When more than one PCE is discovered or configured, a PCC will need to select which PCE to use. It may make this decision on any arbitrary algorithm (for example, first-listed, or round-robin), but it may also be the case that different PCEs have different capabilities and path computation scope, in which case the PCC will want to select the PCE most likely to be able to satisfy any one request. The first requirement, of course, is that the PCE can compute paths for the relevant domain. Yeah, OK for that. It duplicates the final sentence I added to this paragraph, but it does no harm. * Sec 20. Comparison of Stateless and Stateful PCE Can you have a re look at this wrt draft-ietf-pce-pce-initiated-lsp-00 is now a WG draft. Mutter! Which document is right? What specific issue are you raising? [DD] http://tools.ietf.org/html/draft-ietf-pce-questions-03#section-20 says | Stateless | Stateful | ------------------------+-----------+-----------+ Passive | 1 | 2 | Active delegated LSPs | 3 | 4 | Active suggest new LSPs | 5 | 6 | Active instantiate LSPs | 7 | 7 | 7. These modes are out of scope for PCE as currently described. Where does draft-ietf-pce-pce-initiated-lsp fits in, in my reading this was 7, and thus I suggested it should not be out of scope. If you agree, ignore below text Otherwise we have some confusion over the terms IMO Suggest new LSP was same as PCE sends an update message triggering setup of a new LSP in MBB fashion. Instantiate LSP was PCE send an LSP initiate message to instantiate an LSP. (7) Maybe you can clarify what is your understanding of these terms OK, the difference I am trying to arrive at is whether the Active PCE can *require* the establishment of an LSP, or whether it is *suggesting* it. The difference is (IMHO) between an NMS or CLI that dictates what the LSR does, and an Active PCE that requests the LSR to act. More precisely, absent access controls, an LSR obeys the NMS, but an LSR can implement policy to filter or modify requests from a PCE. I realise that this view might not be popular with implementers of Active PCEs, but I think that they are failing to distinguish between the blob of code they are writing and naming "Company Foo's most Excellent Active PCE", and the architectural components. This, at least, is part of what I am trying to convey in Section 19 of this document and in the ABNO document. The bottom line, I think, is that a PCE is not a provisioning tool, it is a path computation element. The fact that PCEP is used as a provisioning protocol does not make the thing that does the provisioning into a PCE. Of course, I don't want to go against consensus with this, but I do think it is an important architectural principle. Thus, I have been looking for words that suit both viewpoints... For an Active PCE to "suggest new LSPs" or to "recommend new LSPs" as described in Sections 19 and 20 allows, IMHO, an LSR to have a policy that says "always do what is recommended" and so achieving PCE-initiated LSPs. Yet, these words also allow a policy of "look both ways before crossing the road" which fits more closely with my world-view. >From my perspective "sending an update message to trigger setup of a new LSP in MBB fashion" is no different from setting up any other LSP. First there was no LSP, then there is one. So I think the distinction you are drawing doesn't work. I hope that explains my motivation, and I believe the words in the draft fit this explanation. Cheers, Adrian
- [Pce] I-D Action: draft-ietf-pce-questions-02.txt internet-drafts
- Re: [Pce] I-D Action: draft-ietf-pce-questions-02… Adrian Farrel
- Re: [Pce] I-D Action: draft-ietf-pce-questions-02… Dhruv Dhody
- Re: [Pce] I-D Action: draft-ietf-pce-questions-02… Adrian Farrel
- Re: [Pce] I-D Action: draft-ietf-pce-questions-02… Dhruv Dhody
- Re: [Pce] I-D Action: draft-ietf-pce-questions-02… Adrian Farrel
- [Pce] Terminology for PCE-Initiated LSP (Was I-D … Dhruv Dhody
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Adrian Farrel
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Abdussalam Baryun
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Ramon Casellas
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Zhangxian (Xian)
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Julien Meuric
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Dhruv Dhody
- Re: [Pce] Terminology for PCE-Initiated LSP (Was … Adrian Farrel