Re: [Teas] A New I-D on PCE as a central controller
"Andrew G. Malis" <agmalis@gmail.com> Mon, 23 May 2016 13:43 UTC
Return-Path: <agmalis@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9F912D8E4 for <teas@ietfa.amsl.com>; Mon, 23 May 2016 06:43:52 -0700 (PDT)
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 autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 NPUUKd7UGr_h for <teas@ietfa.amsl.com>; Mon, 23 May 2016 06:43:46 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1061512B034 for <teas@ietf.org>; Mon, 23 May 2016 06:43:46 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id j1so39950310oih.3 for <teas@ietf.org>; Mon, 23 May 2016 06:43:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u/FBkGbWEOnj+pE2ERA1FdyK3eOhqYSYXOxbsdOy8fE=; b=SbYGDCxKzZG3jbP7I28O+gLJzrgCY5dHvue/i34LWkgV7XgT9BthHJOk5VJ+CfAAQg VX0ce8w55bEnX46/UoZbcGu7vH61Ix/4RfzYGZ7nr98UFw5EocbSDexUQiVNUXvVIQls 05REdVdgbsV0lnk0CTxPYuAkYHl0VqUjGukwKps5doUcshz5gqAyQqNkijkOx6oQ+pjO Fw932JmFUmeRt4etJv2h57jMBdysJJoiVznMheMiyP6O5X0PbBSAMU4vQdtOZwleINQ/ bsMT1pBimN6V8eSJv2lFqqBLU0/GjIZENE61KAIXiI87ZjRuDIqHztAh62rezoPzaOXH jN1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u/FBkGbWEOnj+pE2ERA1FdyK3eOhqYSYXOxbsdOy8fE=; b=lQWRPa4owbnhjQMEFs/XebBtv+ziNZxSuUWiAyZoMyRNzoSbrq2v4d09CQNZccV4o+ l0K+6Jv3s02l3UYemmUOQvQ8D8sa6I5O4yW7wTgqdLCtMeSFIOy/YGQoujtFsntWsbHW tzT3shwb3R7xJ+N5uy2ixCYrlphM822LoYV/XADQOfFLOnecFtw71Fbt9cjvH5uqFApv VHvlmGcnpNOBOHCC4G+SxIq711sh2tLu7vEI387EvZ2LXwQFgwJERAOZ7cOsJzQV0pzp 6RpaRwZ+D6d/HBWYuPC8kN4bx4wcYGcUVJl6n9LIUPqWFbjDK28NNCvcfqUpfRzeTHCr AwUg==
X-Gm-Message-State: AOPr4FVuxCa0MEeDeb4U+zSXhUkwlmNkG/GrwhuA7h+48BLKv/DemdRl8TFqeBxnKfbGoViU40qoH5VizDD8uw==
X-Received: by 10.202.66.5 with SMTP id p5mr9452005oia.65.1464011025365; Mon, 23 May 2016 06:43:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.231.106 with HTTP; Mon, 23 May 2016 06:43:25 -0700 (PDT)
In-Reply-To: <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com>
References: <0c6c01d1a7a2$f1a24860$d4e6d920$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48846127@FR712WXCHMBA15.zeu.alcatel-lucent.com> <042101d1ad38$12da5f50$388f1df0$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48860ADB@FR712WXCHMBA15.zeu.alcatel-lucent.com> <001d01d1b3e1$bec637d0$3c52a770$@olddog.co.uk> <655C07320163294895BBADA28372AF5D48862397@FR712WXCHMBA15.zeu.alcatel-lucent.com> <CAA=duU2OpG0=LC40O=y9qYG9iUboCyxJPfktDg6TF-KobP=omg@mail.gmail.com> <655C07320163294895BBADA28372AF5D48862F8B@FR712WXCHMBA15.zeu.alcatel-lucent.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 23 May 2016 09:43:25 -0400
Message-ID: <CAA=duU3BF-4jWjoDPYfPa0AMSXj3CsdyDURgDhW3+vtmL0JNJA@mail.gmail.com>
To: "Scharf, Michael (Nokia - DE)" <michael.scharf@nokia.com>
Content-Type: multipart/alternative; boundary="001a113d6bfc1d6bbd053382a1f9"
Archived-At: <http://mailarchive.ietf.org/arch/msg/teas/F2fH-SRqX66ttbMXJWJUDIg-nuo>
Cc: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "teas@ietf.org" <teas@ietf.org>
Subject: Re: [Teas] A New I-D on PCE as a central controller
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 May 2016 13:43:52 -0000
Michael, The introduction to section 3 says: “As previously mentioned, this section is intended to just make suggestions.”. That sound like hypothetical to me. Cheers, Andy On Mon, May 23, 2016 at 9:37 AM, Scharf, Michael (Nokia - DE) < michael.scharf@nokia.com> wrote: > Why doesn’t the document then mention that the use cases and conclusions > on PCEP are hypothetical? > > > > Michael > > > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* Monday, May 23, 2016 3:35 PM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* adrian@olddog.co.uk; teas@ietf.org > > *Subject:* Re: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I think you’re expecting too much from this draft. It’s meant to be a very > high-level informational document to introduce the concepts and a > non-exhaustive list of possible applications and use cases. As with any > such early document, there’s some amount of speculative writing, and > there’s no expectation that all of the discussed applications or use cases > will actually come to fruition, and there may be others in the future that > do end up being implemented. But the actual details of protocol changes and > applications will be the topics of other standards-track draft(s) to come. > > > > Cheers, > > Andy > > > > > > On Sun, May 22, 2016 at 5:34 PM, Scharf, Michael (Nokia - DE) < > michael.scharf@nokia.com> wrote: > > Hi Adrian, > > > > Many thanks for the tutorial. Since RFC 7491 already acknowledges the role > of a PCE, I see little value of a high-level document that talks about PCEP > as a general SBI for the topics mentioned in Section 3.2.2 and Section > 3.2.3, if that document does not discuss more specifically the impact on > PCEP, data models, etc. > > > > It should be obvious that in my point of view the wording in Sections > 3.2.2 and 3.2.3 is not clear. Just repeating the wording once again does > not address my question, since I have obviously read the document and since > I know the terminology (albeit I am not a native speaker). A generic flow > chart not detailing for which of the messages PCEP would be used, and with > what content, also does not address my concern. > > In any case, if the content of Section 3.2.2 and Section 3.2.3 cannot be > made more explicit, it is impossible for me to understand whether the > conclusion in Section 4 … “As such, no substantial changes to PCEP are > required to support the concept of a PCE-based controller. The only work > needed will be small extensions to carry additional or specific information > elements for the individual use cases.” is correct and how it is actually > justified for the technical areas such as Section 3.2.2 and Section 3.2.3 . > > > > From my personal experience this sort of entirely generic conclusion could > perhaps be a bit of simplification, but this may depend on the actual use > case. But in an I-D, I believe such a generic conclusion needs backing by > content and as far as I understand for Section 3.2.2 and Section 3.2.3 this > backing is lacking in the document right now. > > > > Thanks > > > > Michael > > > > > > *From:* Adrian Farrel [mailto:adrian@olddog.co.uk] > *Sent:* Sunday, May 22, 2016 6:24 AM > *To:* Scharf, Michael (Nokia - DE) > *Cc:* teas@ietf.org > > > *Subject:* RE: [Teas] A New I-D on PCE as a central controller > > > > Michael, > > > > I don't think it is complicated, but it is obviously not clear from the > document, so thank you for raising the concern. > > > > You say it doesn't matter which interface we're talking about, but it > does. PCEP is a protocol and protocols are used on interfaces. > > > > Let's start with southbound of the PCE. We already use PCEP on this > interface. We have always done. It is what PCEP was invented for. And > recent developments in Stateful PCE and PCE-Initiated LSPs have made PCEP > (and this interface) able to send control "commands" as well as respond to > requests. Thus, PCEP is an SBI protocol for use with signaling systems. > > > > Now, we might make several observations... > > > > In many (most?) MPLS-TE networks, every router is capable of being the > head end of LSPs. That means that in a PCE-enabled MPLS-TE network, every > router is a PCEP speaker. > > > > Additionally, we can observe that LSPs (or PWs) can be stitched together. > The stitching, if under the control of a PCE, requires a special > instruction to be sent to the stitching node. > > > > Furthermore, we can understand that a single end-to-end LSP is actually > the stitching of lots of single hop LSPs. That is really what a statically > provisioned LSP is. > > > > Finally, we can see a desire to send TE instructions from a computation > engine (e.g., PCE) to individual network nodes to program their forwarding. > For example, in a Segment Routed network or for static MPLS-TE LSPs. > > > > > > Put all of this together with the recognition that all TE path management > is fundamentally the same and can be performed by the same engine, and that > it does not make sense for such an engine to have to implement multiple SBI > protocols, and you end up with this draft. > > > > I don't think we are saying that this approach is compulsory, but we are > saying that it is possible. Other possibilities exist including using > NETCONF/YANG in place of PCEP, and enhancing BGP in place of PCEP. Others > have suggested XMPP. Frankly, if we were proposing a new protocol it would > be correct to tell us not to, and to persuade us that one of the other > protocols will do the job. But here we are with three (or four) protocols > that fit the bill: each currently covers some of the function space and > each could easily be extended to cover the whole space. I'm not capable of > saying how to decide which protocol does which function, but I do see > pressures of implementation and deployment that lead to this draft. > > > > [Historic note: I was somewhat opposed to adding PCE-Initiated LSP support > to PCEP. I thought this bent the architecture further than was originally > intended. But we went there in the PEC WG and the I-D is now "complete". By > adding support of PCE initiation of LSPs, we naturally opened the path to > this document. FWIW, this is not the first time that PCEP has been > discussed as a more general SBI protocol - RFC 7491 shows it in this > context although does not discuss it much (we should probably add a > reference to ABNO in this document).] > > > > > > Now, you say you are surprised that "the document focuses on using PCEP > e.g. for L3VPN service delivery." I think there is a significant difference > between *requesting* a service and *delivering* that service. The service > request (as, for example, in L3SM) does not involve a PCE and is easily > achieved using a YANG model which, if the service request is on-line, can > be delivered using NETCONF. However, service delivery requires > "orchestration". Orchestration is the process of considering available > network resources and selecting what will be provisioned to support the > service. A PCE is at least a key feature of orchestration, just as it is a > key component of a network controller. > > > > But the document does NOT focus on PCEP in quite the way you describe. In > fact, the only discussion is in 3.2.3 (just two paragraphs in the whole > document) where the focus is on the use of a PCE-based central controller > that can "consider the whole network and all components of a service at > once when planning how to deliver the service." It then goes on to observe > that PCEP can be used "to manage the network resources and to install the > necessary associations between those resources." > > > > > > If we included a message flow chart it would look something like... > > > > Service Manager PCE-based Controller NEs > > Request service---------> > > Compute > > Provision ------> > > <------------- Ack > > Update DBs > > <-------------------Ack > > > > If that simple figure helps with the understanding of this or any other > part of the document, we can surely add it. > > > > Cheers, > > Adrian > > > > > -----Original Message----- > > > From: Scharf, Michael (Nokia - DE) [mailto:michael.scharf@nokia.com > <michael.scharf@nokia.com>] > > > Sent: 20 May 2016 19:07 > > > To: adrian@olddog.co.uk; teas@ietf.org > > > Subject: RE: [Teas] A New I-D on PCE as a central controller > > > > > > As I said, I specifically wonder about Section 3.2.3 "Service Delivery", > which states > > > (omitting some parts that are not relevant here): > > > > > > "Various network services may be offered over a network. These include > > > protection services [...] Virtual Private Network (VPN) service (such as > Layer 3 > > > VPNs [RFC4364] or Ethernet VPNs [RFC7432]), or Pseudowires [RFC3985]. > [...] A > > > PCE-based central control can consider the whole network and all > components of > > > a service at once when planning how to deliver the service. It can then > use PCEP > > > to manage the network resources and to install the necessary associations > > > between those resources." > > > > > > This wording on use of PCEP confuses me, no matter what interface we talk > > > about. I would have assumed that YANG-based protocols such as > > > NETCONF/RESTCONF could be useful in this context, and I am a bit > surprised that > > > the document focuses on using PCEP e.g. for L3VPN service delivery. By > the way, > > > I also wonder how PCEP fits into the discussion on QoS classification in > Section > > > 3.2.2. > > > > > > I wonder if the authors could add to Section 3.2.2 and Section 3.2.3 > e.g. a > > > message sequence chart that illustrates how what is discussed in those > sections > > > relates to PCEP? > > > > > > Michael > > > > > > > > > > > > -----Original Message----- > > > From: Teas [mailto:teas-bounces@ietf.org <teas-bounces@ietf.org>] On > Behalf Of EXT Adrian Farrel > > > Sent: Friday, May 13, 2016 6:54 PM > > > To: Scharf, Michael (Nokia - DE); teas@ietf.org > > > Subject: Re: [Teas] A New I-D on PCE as a central controller > > > > > > Hello again, Michael, it seems to be my day for replying to your emails. > > > > > > > When reading about uses cases such as L3VPN service delivery in > > > > "Section > > > 3.2.3", > > > > what is the author's view on the line of demarcation between NETCONF > > > > and PCEP? > > > > > > Well, I wonder which interface you're talking about. > > > The ones that out in here are: > > > - the interface between customer and operator > > > - the interface between "service orchestrator" and "network orchestrator" > > > > > > The former of these is like the interface used in L3SM. As co-chair of > L3SM, you > > > might not be surprised to hear that my view is that NETCONF is a fine > solution - > > > well, the use of a YANG data model, in any case. > > > > > > The latter is the interface between "Orchestrator / Service Manager / > OSS / > > > NMS" > > > and "PCE-based Controller" as shown on the various figures in the > picture. We > > > haven't discussed this interface in the document, and perhaps we should. > > > > > > If you look at Figure 6 (with the hierarchy of controllers) you might > observe that > > > the parent controller could be implemented to act as though it is > talking to an NE > > > (in the abstract node model) and that means that the southbound > interface of > > > the parent controller would be PCEP. That means (of course) that the > > > northbound interface of the child controller would also be PCEP. Then, > it might > > > seem obvious that we would want all PCE implementations to behave the > same > > > way and so that makes the northbound interface of the parent PCE > > > would/could/should/might also be PCEP. > > > > > > What do you think? > > > > > > Thanks, > > > Adrian > > > > > > _______________________________________________ > > > Teas mailing list > > > Teas@ietf.org > > > https://www.ietf.org/mailman/listinfo/teas > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas > > >
- [Teas] A New I-D on PCE as a central controller Adrian Farrel
- Re: [Teas] A New I-D on PCE as a central controll… Scharf, Michael (Nokia - DE)
- Re: [Teas] A New I-D on PCE as a central controll… Adrian Farrel
- Re: [Teas] A New I-D on PCE as a central controll… Scharf, Michael (Nokia - DE)
- Re: [Teas] A New I-D on PCE as a central controll… Adrian Farrel
- Re: [Teas] A New I-D on PCE as a central controll… Scharf, Michael (Nokia - DE)
- Re: [Teas] A New I-D on PCE as a central controll… Andrew G. Malis
- Re: [Teas] A New I-D on PCE as a central controll… Scharf, Michael (Nokia - DE)
- Re: [Teas] A New I-D on PCE as a central controll… Andrew G. Malis
- Re: [Teas] A New I-D on PCE as a central controll… Scharf, Michael (Nokia - DE)
- Re: [Teas] A New I-D on PCE as a central controll… Andrew G. Malis
- Re: [Teas] A New I-D on PCE as a central controll… Scharf, Michael (Nokia - DE)
- Re: [Teas] A New I-D on PCE as a central controll… Adrian Farrel
- Re: [Teas] A New I-D on PCE as a central controll… Andrew G. Malis