From daniel@olddog.co.uk Sat Dec 1 14:59:09 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1F91F0C73 for ; Sat, 1 Dec 2012 14:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] 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 qYjcLJjn5Ccs for ; Sat, 1 Dec 2012 14:59:08 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 64C541F0C61 for ; Sat, 1 Dec 2012 14:59:08 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB1Mx67q025049; Sat, 1 Dec 2012 22:59:06 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB1Mx4Wc025042 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 1 Dec 2012 22:59:05 GMT From: "Daniel King" To: Date: Sat, 1 Dec 2012 22:58:58 -0000 Message-ID: <002401cdd017$7331c840$599558c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3QFvqv94qy0sYLSXmTPR1+P3/Deg== Content-Language: en-gb Subject: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:59:09 -0000 Hi PCE'rs, Adrian and I posted an I-D which is a rather grandiose attempt to pull together a number of existing architectural components (PCE, VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. It needed a name, so we called it Application-Based Network Operations (ABNO), warning it's not house trained and may answer to various other names: A PCE-based Architecture for Application-based Network Operations http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 As some of you will know this is the result of numerous discussions we have had with a number of people over the last three months. Where pieces of the puzzle seem to have been coagulating, we thought it might be nice to build a framework in which the jelly (jello) can set. It is at a really early stage, so we are convinced you will all throw stuff at us, but what the hell! As it stands, the current draft includes: - A brief description of abstraction functional components and the interfaces between them. - An attempt to supply pointers to existing work (tool kit) where that may be applicable and there are some use case examples to give a feel for how it all works. - Various ABNO use cases. A number of areas need further discussion, especially the use cases. We decided to submit with the few we do have, in order to generate some feedback - anyone who wants to supply use case(s) and text, would receive hero status. We have pitched the document as a PCE working group document because PCE is a central component, but the document doesn't really fall inside the PCE charter. For the time being it might be best to send comments direct to us rather than clutter up any WG mailing list with discussions that are outside the charter (but if some WG chair wants to claim the work, then...) Thanks, Dan and Adrian From quintin.zhao@huawei.com Thu Dec 6 11:58:01 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9B21F8801 for ; Thu, 6 Dec 2012 11:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] 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 mV9vDrRpBJpQ for ; Thu, 6 Dec 2012 11:58:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B65C321F87FC for ; Thu, 6 Dec 2012 11:57:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG06508; Thu, 06 Dec 2012 19:57:47 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 19:56:57 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 19:57:12 +0000 Received: from QZHAO (10.212.244.158) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server id 14.1.323.3; Thu, 6 Dec 2012 11:57:08 -0800 From: Quintin Zhao To: , Date: Thu, 6 Dec 2012 14:58:23 -0500 Message-ID: <007201cdd3ec$0d4a7b20$27df7160$@zhao@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CDD3C2.24747320" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3T7AvbA4+EOIR7ShGlOlVdj2CHHQ== Content-Language: zh-cn X-Originating-IP: [10.212.244.158] X-CFilter-Loop: Reflected Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:58:01 -0000 ------=_NextPart_000_0073_01CDD3C2.24747320 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Dan and Adrian, The draft is very good and is helpful coordinate PCE and TE technologies between applications and network. I focused on some sections and have following questions and suggestions. (1) Applicability of ABNO Architecture. Your document abstract and introduction discusses scenarios including content and data-center interconnection ("Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks."). I think the architecture is also relevant to lots of other environments: mobile backhaul, core transport, packet switch network, etc. Do you agree? (2) ABNO Controller. Section 2.2.13 (ABNO controller) needs to be discussed in more detail. Do you think multiple ABNO controllers or just one ABNO controller will be required? Maybe an implementation will use a ABNO Controller per "application" (Service Coordinator/NMS/OSS)? (3) PCE or PCE's? Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used, this is important for VNTM Use Case. Maybe you can show more PCE's in the figure 1 or describe it? (4) Network Resiliency. I am interested in ABNO managing network failures that may be protected with shared mesh protection at the network which could be MPLS TP or WDM. ABNO would provide a shared path protection which optimizes as network conditions change. This is based on client layer requirements of reliability and protection restoration time. To make this possible the shared mesh protection paths would need to be client layer traffic aware and have customer SLA information. Do you think this is a good use case? (5) Custom (Abstracted) Topologies. Could ABNO provide abstracted topologies via the north-bound interface to the requester (provisioning tool)? In China we have the customers who would like IPv6 deployment in IPv4 backbone. If provider can assign specific nodes and links to be used for logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) architecture could be used to provide abstracted topology based on the preferred equipment for carrying tunneled IPv6 traffic. Is this another use case that may be useful? (6) Manageability and Security. Are you going to provide Manageability and Security sections in future versions of the ABNO document or another document? It is an important area for ABNO that needs further discussion. Thanks! Quintin ---------------------------------------------------------------------- Message: 1 Date: Sat, 1 Dec 2012 22:58:58 -0000 From: "Daniel King" To: Subject: [Pce] A new draft on an architecture for application-based network operations Message-ID: <002401cdd017$7331c840$599558c0$@olddog.co.uk> Content-Type: text/plain; charset="us-ascii" Hi PCE'rs, Adrian and I posted an I-D which is a rather grandiose attempt to pull together a number of existing architectural components (PCE, VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. It needed a name, so we called it Application-Based Network Operations (ABNO), warning it's not house trained and may answer to various other names: A PCE-based Architecture for Application-based Network Operations http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 As some of you will know this is the result of numerous discussions we have had with a number of people over the last three months. Where pieces of the puzzle seem to have been coagulating, we thought it might be nice to build a framework in which the jelly (jello) can set. It is at a really early stage, so we are convinced you will all throw stuff at us, but what the hell! As it stands, the current draft includes: - A brief description of abstraction functional components and the interfaces between them. - An attempt to supply pointers to existing work (tool kit) where that may be applicable and there are some use case examples to give a feel for how it all works. - Various ABNO use cases. A number of areas need further discussion, especially the use cases. We decided to submit with the few we do have, in order to generate some feedback - anyone who wants to supply use case(s) and text, would receive hero status. We have pitched the document as a PCE working group document because PCE is a central component, but the document doesn't really fall inside the PCE charter. For the time being it might be best to send comments direct to us rather than clutter up any WG mailing list with discussions that are outside the charter (but if some WG chair wants to claim the work, then...) Thanks, Dan and Adrian ------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 99, Issue 1 ********************************** ------=_NextPart_000_0073_01CDD3C2.24747320 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Dan = and Adrian,

 

The draft is very good and is helpful coordinate PCE and TE = technologies between applications and network. I focused on some = sections and have following questions and suggestions. =

 

(1) Applicability of ABNO Architecture. =

Your = document abstract and introduction discusses scenarios including content = and data-center interconnection ("Services such as content = distribution, distributed databases, or inter-data center connectivity = place a set of new requirements on the operation of networks."). I = think the architecture is also relevant to lots of other environments: = mobile backhaul, core transport, packet switch network, etc. Do you = agree?

 

(2) ABNO Controller.

Section 2.2.13 (ABNO controller) = needs to be discussed in more detail. Do you think multiple ABNO = controllers or just one ABNO controller will be required? Maybe an = implementation will use a ABNO Controller per "application" = (Service Coordinator/NMS/OSS)?

 

(3) PCE or = PCE's?

Figure 1 shows *a* PCE. It is expected that multiple PCE' = would be used, this is important for VNTM Use Case. Maybe you can show = more PCE's in the figure 1 or describe it?

 

(4) Network = Resiliency.

I am interested in ABNO managing network failures that may = be protected with shared mesh protection at the network which could be = MPLS TP or WDM. ABNO would provide a shared path protection which = optimizes as network conditions change. This is based on client layer = requirements of reliability and protection restoration time. To make = this possible the shared mesh protection paths would need to be client = layer traffic aware and have customer SLA information. Do you think this = is a good use case?

 

(5) Custom (Abstracted) Topologies. =      

Could ABNO provide abstracted = topologies via the north-bound interface to the requester (provisioning = tool)? In China we have the customers who would like IPv6 deployment in = IPv4 backbone. If provider can assign specific nodes and links to be = used for logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) = architecture could be used to provide abstracted topology based on the = preferred equipment for carrying tunneled IPv6 traffic. Is this another = use case that may be useful?

 

(6) Manageability and = Security. 

Are you going to provide Manageability and Security = sections in future versions of the ABNO document or another document? It = is an important area for ABNO that needs further discussion. =

 

Thanks!

Quintin

 

 

------------------------------------------------------------= ----------

 

Message: 1

Date: Sat, 1 Dec 2012 22:58:58 = -0000

From: "Daniel King" = <daniel@olddog.co.uk>

To: = <pce@ietf.org>

Subject: [Pce] A new draft on an architecture for = application-based

         = network  operations

Message-ID: = <002401cdd017$7331c840$599558c0$@olddog.co.uk>

Content-Type: = text/plain;      = charset=3D"us-ascii"

 

Hi = PCE'rs,

 

Adrian and I posted an I-D which is a rather grandiose = attempt to pull

together a number of existing architectural components = (PCE, VNTM, I2RS,

policy, etc., etc.). This is a sort of meta-SDN PCE-based = architect-thingy.

It needed a name, so we called it Application-Based Network = Operations

(ABNO), warning it's not house trained and may answer to = various other

names:

 

A PCE-based Architecture for Application-based Network = Operations

http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00=

 

As some of you will know this is the result of numerous = discussions we have

had with a number of people over the last three = months.  Where pieces of the

puzzle seem to have been = coagulating, we thought it might be nice to build = a

framework in which the jelly (jello) can set. It is at a = really early stage,

so we are convinced you will all throw stuff at us, but = what the hell!

 

As it stands, the current draft = includes:

 

- A brief description of abstraction functional components = and the

interfaces between them.

- An attempt to supply pointers = to existing work (tool kit) where that may

be applicable and there are some = use case examples to give a feel for how it

all = works.

- = Various ABNO use cases.

 

A number of areas need further = discussion, especially the use cases. We

decided to submit with the few = we do have, in order to generate some

feedback - anyone who wants to = supply use case(s) and text, would receive

hero status. =

 

We have pitched the document as a PCE working group = document because PCE is

a central component, but the = document doesn't really fall inside the PCE

charter. For the time being it = might be best to send comments direct to us

rather than clutter up any WG = mailing list with discussions that are outside

the charter (but if some WG = chair wants to claim the work, then...)

 

Thanks,

Dan and = Adrian

 

 

 

------------------------------

 

_______________________________________________

Pce mailing = list

Pce@ietf.org

https://www.ietf.org/mailman/listinfo/pce<= /p>

 

 

End of Pce Digest, Vol 99, Issue 1

**********************************

 
------=_NextPart_000_0073_01CDD3C2.24747320-- From leeyoung@huawei.com Thu Dec 6 15:38:58 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3921F8561 for ; Thu, 6 Dec 2012 15:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] 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 cfJ+Z8HzSrx3 for ; Thu, 6 Dec 2012 15:38:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 551E921F855F for ; Thu, 6 Dec 2012 15:38:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMG14841; Thu, 06 Dec 2012 23:38:55 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 23:37:03 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Dec 2012 23:37:34 +0000 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.31]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Thu, 6 Dec 2012 15:37:31 -0800 From: Leeyoung To: Daniel King , "pce@ietf.org" Thread-Topic: [Pce] A new draft on an architecture for application-based network operations Thread-Index: Ac3QFvqv94qy0sYLSXmTPR1+P3/DegD8sxRw Date: Thu, 6 Dec 2012 23:37:31 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17290D1029@dfweml511-mbs.china.huawei.com> References: <002401cdd017$7331c840$599558c0$@olddog.co.uk> In-Reply-To: <002401cdd017$7331c840$599558c0$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 23:38:58 -0000 Hi Dan, I support your draft to be considered in the PCE WG especially in light of = a potential PCE WG re-chartering discussion. There was a related draft that Dhruv presented in a previous PCE WG meeting= .=20 http://datatracker.ietf.org/doc/draft-dhody-pce-cso-enabled-path-computatio= n/ I think some ideas from Dhruv's draft can be integrated together with yours= .=20 Best Regards, Young -----Original Message----- From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Danie= l King Sent: Saturday, December 01, 2012 4:59 PM To: pce@ietf.org Subject: [Pce] A new draft on an architecture for application-based network= operations Hi PCE'rs, Adrian and I posted an I-D which is a rather grandiose attempt to pull together a number of existing architectural components (PCE, VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. It needed a name, so we called it Application-Based Network Operations (ABNO), warning it's not house trained and may answer to various other names: A PCE-based Architecture for Application-based Network Operations http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 As some of you will know this is the result of numerous discussions we have had with a number of people over the last three months. Where pieces of th= e puzzle seem to have been coagulating, we thought it might be nice to build = a framework in which the jelly (jello) can set. It is at a really early stage= , so we are convinced you will all throw stuff at us, but what the hell! As it stands, the current draft includes: - A brief description of abstraction functional components and the interfaces between them.=20 - An attempt to supply pointers to existing work (tool kit) where that may be applicable and there are some use case examples to give a feel for how i= t all works. - Various ABNO use cases.=20 A number of areas need further discussion, especially the use cases. We decided to submit with the few we do have, in order to generate some feedback - anyone who wants to supply use case(s) and text, would receive hero status.=20 We have pitched the document as a PCE working group document because PCE is a central component, but the document doesn't really fall inside the PCE charter. For the time being it might be best to send comments direct to us rather than clutter up any WG mailing list with discussions that are outsid= e the charter (but if some WG chair wants to claim the work, then...) Thanks, Dan and Adrian _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce From adrian@olddog.co.uk Fri Dec 7 06:16:00 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC2FE21F8985 for ; Fri, 7 Dec 2012 06:16:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_32=0.6] 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 oJNb7-L960SZ for ; Fri, 7 Dec 2012 06:16:00 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C147C21F8983 for ; Fri, 7 Dec 2012 06:15:59 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB7EFtNd014240; Fri, 7 Dec 2012 14:15:55 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB7EFr9d014194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Dec 2012 14:15:54 GMT From: "Adrian Farrel" To: "'Leeyoung'" Date: Fri, 7 Dec 2012 14:15:49 -0000 Message-ID: <023a01cdd485$5ca357c0$15ea0740$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3UhNHCPTRVnlI3QHGf8WQZYcNl5Q== Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:16:00 -0000 Hi Young, Yes, CSO was somewhat in our mind our mind as we wrote this, and you'll see one of the use-cases is about virtual topology which is part of the puzzle. Maybe you or Dhruv would like to suggest some text for a CSO use case? Cheers, Adrian > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of > Leeyoung > Sent: 06 December 2012 23:38 > To: Daniel King; pce@ietf.org > Subject: Re: [Pce] A new draft on an architecture for application-based network > operations > > Hi Dan, > > I support your draft to be considered in the PCE WG especially in light of a > potential PCE WG re-chartering discussion. > > There was a related draft that Dhruv presented in a previous PCE WG meeting. > > http://datatracker.ietf.org/doc/draft-dhody-pce-cso-enabled-path- > computation/ > > I think some ideas from Dhruv's draft can be integrated together with yours. > > Best Regards, > Young > > > -----Original Message----- > From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Daniel > King > Sent: Saturday, December 01, 2012 4:59 PM > To: pce@ietf.org > Subject: [Pce] A new draft on an architecture for application-based network > operations > > Hi PCE'rs, > > Adrian and I posted an I-D which is a rather grandiose attempt to pull > together a number of existing architectural components (PCE, VNTM, I2RS, > policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. > It needed a name, so we called it Application-Based Network Operations > (ABNO), warning it's not house trained and may answer to various other > names: > > A PCE-based Architecture for Application-based Network Operations > http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 > > As some of you will know this is the result of numerous discussions we have > had with a number of people over the last three months. Where pieces of the > puzzle seem to have been coagulating, we thought it might be nice to build a > framework in which the jelly (jello) can set. It is at a really early stage, > so we are convinced you will all throw stuff at us, but what the hell! > > As it stands, the current draft includes: > > - A brief description of abstraction functional components and the > interfaces between them. > - An attempt to supply pointers to existing work (tool kit) where that may > be applicable and there are some use case examples to give a feel for how it > all works. > - Various ABNO use cases. > > A number of areas need further discussion, especially the use cases. We > decided to submit with the few we do have, in order to generate some > feedback - anyone who wants to supply use case(s) and text, would receive > hero status. > > We have pitched the document as a PCE working group document because PCE is > a central component, but the document doesn't really fall inside the PCE > charter. For the time being it might be best to send comments direct to us > rather than clutter up any WG mailing list with discussions that are outside > the charter (but if some WG chair wants to claim the work, then...) > > Thanks, > Dan and Adrian > > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce > _______________________________________________ > Pce mailing list > Pce@ietf.org > https://www.ietf.org/mailman/listinfo/pce From daniel@olddog.co.uk Fri Dec 7 06:52:08 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8385F21F86E2 for ; Fri, 7 Dec 2012 06:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] 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 bA0UK7a1dDSg for ; Fri, 7 Dec 2012 06:52:04 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C820221F854B for ; Fri, 7 Dec 2012 06:52:03 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB7EpxlF006353; Fri, 7 Dec 2012 14:51:59 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB7EpvbR006327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Dec 2012 14:51:58 GMT From: "Daniel King" To: "'Quintin Zhao'" References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN@mx.google.com> Date: Fri, 7 Dec 2012 14:51:55 -0000 Message-ID: <008601cdd48a$674f7b90$35ee72b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01CDD48A.6753C150" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFrZjbRxLc5+InYH8ThqvcxIMjyVJjSQ7fg Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 14:52:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0087_01CDD48A.6753C150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Quintin, Thanks, lots of good points. A few quick responses inline and we discuss in more detail offline. (Apologies to the PCE list, we will take this offline until charter discussions have taken place or we hear otherwise.) From: Quintin Zhao [mailto:quintin.zhao@huawei.com] Sent: 06 December 2012 19:58 To: daniel@olddog.co.uk; adrian@olddog.co.uk Cc: pce@ietf.org Subject: Re: A new draft on an architecture for application-based network operations Dear Dan and Adrian, The draft is very good and is helpful coordinate PCE and TE technologies between applications and network. I focused on some sections and have following questions and suggestions. (1) Applicability of ABNO Architecture. Your document abstract and introduction discusses scenarios including content and data-center interconnection ("Services such as content distribution, distributed databases, or inter-data center connectivity place a set of new requirements on the operation of networks."). I think the architecture is also relevant to lots of other environments: mobile backhaul, core transport, packet switch network, etc. Do you agree? DK>> Yes, that's true. We did focus on the data center applicability as we presented some slides at MPLS Washington 2012 which discussed that specific scenario and the draft followed some of the same language. (2) ABNO Controller. Section 2.2.13 (ABNO controller) needs to be discussed in more detail. Do you think multiple ABNO controllers or just one ABNO controller will be required? Maybe an implementation will use a ABNO Controller per "application" (Service Coordinator/NMS/OSS)? DK>> When we were white boarding and discussing the architecture we certainly considered that a number of the ABNO components would require multiple instances per deployment, including the ABNO Controller. As per your next point we will try to be more specific in the ABNO text. (3) PCE or PCE's? Figure 1 shows *a* PCE. It is expected that multiple PCE' would be used, this is important for VNTM Use Case. Maybe you can show more PCE's in the figure 1 or describe it? DK>> As Above, yes. (4) Network Resiliency. I am interested in ABNO managing network failures that may be protected with shared mesh protection at the network which could be MPLS TP or WDM. ABNO would provide a shared path protection which optimizes as network conditions change. This is based on client layer requirements of reliability and protection restoration time. To make this possible the shared mesh protection paths would need to be client layer traffic aware and have customer SLA information. Do you think this is a good use case? DK>> Cool. I think this could represent quite a complex multi-layer optimization problem. Please let Adrian and me have more information on the scenario. Ideally documenting the various component functions (specific for the use case) and each component interaction, again with some detail on what information needs provided and perhaps propose protocol mechanism or extensions. Think of the draft as a tool kit. We would like to reuse existing technology as much as possible. The use case should reflect this. (5) Custom (Abstracted) Topologies. Could ABNO provide abstracted topologies via the north-bound interface to the requester (provisioning tool)? In China we have the customers who would like IPv6 deployment in IPv4 backbone. If provider can assign specific nodes and links to be used for logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) architecture could be used to provide abstracted topology based on the preferred equipment for carrying tunneled IPv6 traffic. Is this another use case that may be useful? DK>>Maybe we can focus on the SMP use case first. This use case might benefit from some of the discussion Young raised yesterday, in terms of the virtual topology presentation. (6) Manageability and Security. Are you going to provide Manageability and Security sections in future versions of the ABNO document or another document? It is an important area for ABNO that needs further discussion. DK>> We will most definitely include some discussion in the ABNO framework, along with policy. Thanks! Quintin ---------------------------------------------------------------------- Message: 1 Date: Sat, 1 Dec 2012 22:58:58 -0000 From: "Daniel King" To: Subject: [Pce] A new draft on an architecture for application-based network operations Message-ID: <002401cdd017$7331c840$599558c0$@olddog.co.uk> Content-Type: text/plain; charset="us-ascii" Hi PCE'rs, Adrian and I posted an I-D which is a rather grandiose attempt to pull together a number of existing architectural components (PCE, VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. It needed a name, so we called it Application-Based Network Operations (ABNO), warning it's not house trained and may answer to various other names: A PCE-based Architecture for Application-based Network Operations http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 As some of you will know this is the result of numerous discussions we have had with a number of people over the last three months. Where pieces of the puzzle seem to have been coagulating, we thought it might be nice to build a framework in which the jelly (jello) can set. It is at a really early stage, so we are convinced you will all throw stuff at us, but what the hell! As it stands, the current draft includes: - A brief description of abstraction functional components and the interfaces between them. - An attempt to supply pointers to existing work (tool kit) where that may be applicable and there are some use case examples to give a feel for how it all works. - Various ABNO use cases. A number of areas need further discussion, especially the use cases. We decided to submit with the few we do have, in order to generate some feedback - anyone who wants to supply use case(s) and text, would receive hero status. We have pitched the document as a PCE working group document because PCE is a central component, but the document doesn't really fall inside the PCE charter. For the time being it might be best to send comments direct to us rather than clutter up any WG mailing list with discussions that are outside the charter (but if some WG chair wants to claim the work, then...) Thanks, Dan and Adrian ------------------------------ _______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce End of Pce Digest, Vol 99, Issue 1 ********************************** ------=_NextPart_000_0087_01CDD48A.6753C150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Quintin,

 

Thanks, lots of good = points. A few quick responses inline and we discuss in more detail = offline.

 

(Apologies to the PCE = list, we will take this offline until charter discussions have taken = place or we hear otherwise.)

 

From:= = Quintin Zhao [mailto:quintin.zhao@huawei.com]
Sent: 06 = December 2012 19:58
To: daniel@olddog.co.uk; = adrian@olddog.co.uk
Cc: pce@ietf.org
Subject: Re: A = new draft on an architecture for application-based network = operations

 

Dear Dan and Adrian, =

 

The draft = is very good and is helpful coordinate PCE and TE technologies between = applications and network. I focused on some sections and have following = questions and suggestions.

 

(1) = Applicability of ABNO Architecture.

Your = document abstract and introduction discusses scenarios including content = and data-center interconnection ("Services such as content = distribution, distributed databases, or inter-data center connectivity = place a set of new requirements on the operation of networks."). I = think the architecture is also relevant to lots of other environments: = mobile backhaul, core transport, packet switch network, etc. Do you = agree?

 

DK>> Yes, = that’s true. We did focus on the data center applicability as we = presented some slides at MPLS Washington 2012 which discussed that = specific scenario and the draft followed some of the same language. =

 

(2) ABNO = Controller.

Section 2.2.13 (ABNO controller) = needs to be discussed in more detail. Do you think multiple ABNO = controllers or just one ABNO controller will be required? Maybe an = implementation will use a ABNO Controller per "application" = (Service Coordinator/NMS/OSS)?

 

DK>> When we = were white boarding and discussing the architecture we certainly = considered that a number of the ABNO components would require multiple = instances per deployment, including the ABNO Controller. As per your = next point we will try to be more specific in the ABNO text. =

 

(3) PCE or = PCE's?

Figure 1 shows *a* PCE. It is = expected that multiple PCE' would be used, this is important for VNTM = Use Case. Maybe you can show more PCE's in the figure 1 or describe = it?

 

DK>> As Above, = yes.

 

(4) Network = Resiliency.

I am interested in ABNO managing = network failures that may be protected with shared mesh protection at = the network which could be MPLS TP or WDM. ABNO would provide a shared = path protection which optimizes as network conditions change. This is = based on client layer requirements of reliability and protection = restoration time. To make this possible the shared mesh protection paths = would need to be client layer traffic aware and have customer SLA = information. Do you think this is a good use = case?

 

DK>> Cool. I = think this could represent quite a complex multi-layer optimization = problem. Please let Adrian and me have more information on the scenario. = Ideally documenting the various component functions (specific for the = use case) and each component interaction, again with some detail on what = information needs provided and perhaps propose protocol mechanism or = extensions. Think of the draft as a tool kit. We would like to reuse = existing technology as much as possible. The use case should reflect = this.    

 

(5) Custom (Abstracted) Topologies. =      

Could ABNO = provide abstracted topologies via the north-bound interface to the = requester (provisioning tool)? In China we have the customers who would = like IPv6 deployment in IPv4 backbone. If provider can assign specific = nodes and links to be used for logically isolated IPv6 plane, then the = ABNO (I2RS and BGP-LS) architecture could be used to provide abstracted = topology based on the preferred equipment for carrying tunneled IPv6 = traffic. Is this another use case that may be = useful?

 

DK>>Maybe we = can focus on the SMP use case first. This use case might benefit from = some of the discussion Young raised yesterday, in terms of the virtual = topology presentation.  

 

(6) Manageability and = Security. 

Are you going to provide = Manageability and Security sections in future versions of the ABNO = document or another document? It is an important area for ABNO that = needs further discussion.

 

DK>> We will = most definitely include some discussion in the ABNO framework, along = with policy.

 

Thanks!

Quintin

 

 

------------------------------------= ----------------------------------

 

Message: = 1

Date: Sat, 1 Dec 2012 22:58:58 = -0000

From: "Daniel King" = <daniel@olddog.co.uk>

To: <pce@ietf.org>

Subject: [Pce] A new draft on an = architecture for application-based

      =    network  operations

Message-ID: <002401cdd017= $7331c840$599558c0$@olddog.co.uk>

Content-Type: = text/plain;      = charset=3D"us-ascii"

 

Hi = PCE'rs,

 

Adrian = and I posted an I-D which is a rather grandiose attempt to = pull

together a number of existing = architectural components (PCE, VNTM, I2RS,

policy, = etc., etc.). This is a sort of meta-SDN PCE-based = architect-thingy.

It needed a name, so we called it = Application-Based Network Operations

(ABNO), = warning it's not house trained and may answer to various = other

names:

 

A = PCE-based Architecture for Application-based Network = Operations

http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00=

 

As some = of you will know this is the result of numerous discussions we = have

had with a number of people over = the last three months.  Where pieces of the

puzzle = seem to have been coagulating, we thought it might be nice to build = a

framework in which the jelly = (jello) can set. It is at a really early stage,

so we = are convinced you will all throw stuff at us, but what the = hell!

 

As it = stands, the current draft includes:

 

- A = brief description of abstraction functional components and = the

interfaces between them. =

- An attempt to supply pointers to = existing work (tool kit) where that may

be = applicable and there are some use case examples to give a feel for how = it

all works.

- = Various ABNO use cases.

 

A number = of areas need further discussion, especially the use cases. = We

decided to submit with the few we = do have, in order to generate some

feedback = - anyone who wants to supply use case(s) and text, would = receive

hero status. =

 

We have = pitched the document as a PCE working group document because PCE = is

a central component, but the = document doesn't really fall inside the PCE

charter. = For the time being it might be best to send comments direct to = us

rather than clutter up any WG = mailing list with discussions that are outside

the = charter (but if some WG chair wants to claim the work, = then...)

 

Thanks,

Dan and = Adrian

 

 

 

------------------------------<= /o:p>

 

____________________________________= ___________

Pce mailing = list

Pce@ietf.org

https://www.ietf.org/m= ailman/listinfo/pce

 

 

End of = Pce Digest, Vol 99, Issue 1

**********************************

 =
------=_NextPart_000_0087_01CDD48A.6753C150-- From adrian@olddog.co.uk Fri Dec 7 07:13:21 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A0821F8A87 for ; Fri, 7 Dec 2012 07:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] 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 UUUbtFMH4wHa for ; Fri, 7 Dec 2012 07:13:20 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1382721F8A1B for ; Fri, 7 Dec 2012 07:13:19 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB7FDEuN012788; Fri, 7 Dec 2012 15:13:14 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qB7FDCWA012777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Dec 2012 15:13:13 GMT From: "Adrian Farrel" To: "'Daniel King'" , "'Quintin Zhao'" References: <50c0f8a1.2218b40a.2c1e.48c1SMTPIN_ADDED_BROKEN@mx.google.com> <008601cdd48a$674f7b90$35ee72b0$@olddog.co.uk> In-Reply-To: <008601cdd48a$674f7b90$35ee72b0$@olddog.co.uk> Date: Fri, 7 Dec 2012 15:13:08 -0000 Message-ID: <025301cdd48d$5e2ae880$1a80b980$@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: AQFrZjbRxLc5+InYH8ThqvcxIMjyVAEBEe1kmMpCNpA= Content-Language: en-gb Cc: pce@ietf.org Subject: Re: [Pce] A new draft on an architecture for application-based network operations X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 15:13:21 -0000 Hi Quintin, Following up with some more detail on top of Dan's email. >> The draft is very good and is helpful coordinate PCE and TE = technologies >> between applications and network. I focused on some sections and have >> following questions and suggestions.=20 Thanks for reading and commenting. Answers in line. >> (1) Applicability of ABNO Architecture.=20 >> Your document abstract and introduction discusses scenarios including >> content and data-center interconnection ("Services such as content >> distribution, distributed databases, or inter-data center = connectivity >> place a set of new requirements on the operation of networks."). I >> think the architecture is also relevant to lots of other = environments: >> mobile backhaul, core transport, packet switch network, etc. Do you >> agree?=20 > > DK>> Yes, that=92s true. We did focus on the data center applicability = as > we presented some slides at MPLS Washington 2012 which discussed > that specific scenario and the draft followed some of the same = language. I agree. We were trying to describe some service environments rather = than network environments, and we certainly don't want to imply any = limitations on the uses or the network environments. We expect that the architecture = could be used in a whole range of applications: both at the static end of the = spectrum (such as mobile backhaul), and for more dynamic services. We will highlight this point in the next revision. >> (2) ABNO Controller. >> Section 2.2.13 (ABNO controller) needs to be discussed in more = detail. >> Do you think multiple ABNO controllers or just one ABNO controller >> will be required? Maybe an implementation will use a ABNO Controller >> per "application" (Service Coordinator/NMS/OSS)?=20 > > DK>> When we were white boarding and discussing the architecture we > certainly considered that a number of the ABNO components would = require > multiple instances per deployment, including the ABNO Controller. As = per > your next point we will try to be more specific in the ABNO text.=20 > >> (3) PCE or PCE's? >> Figure 1 shows *a* PCE. It is expected that multiple PCE' would be = used, >> this is important for VNTM Use Case. Maybe you can show more PCE's >> in the figure 1 or describe it? > > DK>> As Above, yes. As Dan says, there can certainly be multiple instances of the functional components in the figure. This could arise within an implementation to load-share, provide specialist capabilities (as you suggest for the ABNO Controller), to maintain confidentiality or separation of function (as = you suggest for PCE), or to distribute the function across platforms. We are = keen to stress that this is a functional architecture, not an implementation = road-map. I think we will add a section on "Implementation of the Architecture" to = discuss these points. >> (4) Network Resiliency. >> I am interested in ABNO managing network failures that may be=20 >> protected with shared mesh protection at the network which could >> be MPLS TP or WDM. ABNO would provide a shared path protection >> which optimizes as network conditions change. This is based on >> client layer requirements of reliability and protection restoration >> time. To make this possible the shared mesh protection paths would >> need to be client layer traffic aware and have customer SLA >> information. Do you think this is a good use case? > > DK>> Cool. I think this could represent quite a complex multi-layer > optimization problem. Please let Adrian and me have more > information on the scenario. Ideally documenting the various > component functions (specific for the use case) and each > component interaction, again with some detail on what information > needs provided and perhaps propose protocol mechanism or > extensions. Think of the draft as a tool kit. We would like to reuse > existing technology as much as possible. The use case should reflect > this.=20 Yes, this sounds like an interesting use case. Shared mesh protection = (and also 1:n protection) can be a complex provisioning problem, and changes in = services as well as changes in network availability can require significant = dynamic reassessment of the placement of LSPs. If you would like to suggest text = for a use case, I think we would be happy to see it. >> (5) Custom (Abstracted) Topologies. =A0=A0=A0=A0=A0=20 >> Could ABNO provide abstracted topologies via the north-bound >> interface to the requester (provisioning tool)? In China we have >> the customers who would like IPv6 deployment in IPv4 backbone. >> If provider can assign specific nodes and links to be used for >> logically isolated IPv6 plane, then the ABNO (I2RS and BGP-LS) >> architecture could be used to provide abstracted topology based >> on the preferred equipment for carrying tunneled IPv6 traffic. Is >> this another use case that may be useful? > > DK>>Maybe we can focus on the SMP use case first. This use case > might benefit from some of the discussion Young raised yesterday, > in terms of the virtual topology presentation. =A0 Actually, I think the model already supports exporting information from = the TED as described in Section 2.2.2.4. This section does not clearly explain = that the TED could be "abstracted", but it should! We will add some text. >> (6) Manageability and Security.=A0=20 >> Are you going to provide Manageability and Security sections in >> future versions of the ABNO document or another document?=20 >> It is an important area for ABNO that needs further discussion.=20 > > DK>> We will most definitely include some discussion in the ABNO=20 > framework, along with policy.=20 Agreed. (Unless someone else writes the text first :-) Thanks, Adrian From dhruv.dhody@huawei.com Mon Dec 10 20:10:34 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1CE21F86FC for ; Mon, 10 Dec 2012 20:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, RCVD_IN_DNSWL_MED=-4] 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 QRJJdbFUeLpO for ; Mon, 10 Dec 2012 20:10:33 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 406D921F86F5 for ; Mon, 10 Dec 2012 20:10:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANS00360; Tue, 11 Dec 2012 04:10:30 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 04:09:42 +0000 Received: from SZXEML444-HUB.china.huawei.com (10.82.67.182) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 11 Dec 2012 04:10:28 +0000 Received: from blrprnc03ns (10.18.96.92) by szxeml444-hub.china.huawei.com (10.82.67.182) with Microsoft SMTP Server id 14.1.323.3; Tue, 11 Dec 2012 12:10:26 +0800 From: Dhruv Dhody To: Date: Tue, 11 Dec 2012 09:40:23 +0530 Organization: HTIPL Message-ID: <004b01cdd755$71d55210$557ff630$@dhody@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01CDD783.8B8D8E10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac3We/295XJuIkTTR6e0/yt5JlaO2wA2FIBA Content-Language: en-us X-Originating-IP: [10.18.96.92] X-CFilter-Loop: Reflected Subject: [Pce] FW: New Version Notification for draft-dhody-pce-pcep-service-aware-04.txt X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dhruv.dhody@huawei.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 04:10:34 -0000 ------=_NextPart_000_004C_01CDD783.8B8D8E10 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear PCE=E2=80=99rs,=20 =20 We have updated the service-aware draft (delay, jitter, packet-loss) and = merged with 'draft-ali-pce-additional-of-and-metric' as discussed during = the Atlanta WG meeting. =20 =20 Any comments would be highly appreciated.=20 =20 Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-pcep-service-aware-04 =20 Regards, Dhruv =20 *************************************************************************= ****** Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, = Ph. +91-9845062422 This e-mail and 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! =20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, December 10, 2012 7:44 AM > To: dhruv.ietf@gmail.com > Cc: vishwas.manral@hp.com; swallow@cisco.com; zali@cisco.com; > dhruv.dhody@huawei.com; ke-kumaki@kddi.com > Subject: New Version Notification for = draft-dhody-pce-pcep-service-aware- > 04.txt >=20 >=20 > A new version of I-D, draft-dhody-pce-pcep-service-aware-04.txt > has been successfully submitted by Dhruv Dhody and posted to the > IETF repository. >=20 > Filename: draft-dhody-pce-pcep-service-aware > Revision: 04 > Title: Extensions to the Path Computation Element = Communication > Protocol (PCEP) to compute service aware Label Switched Path (LSP). > Creation date: 2012-12-10 > WG ID: Individual Submission > Number of pages: 17 > URL: = http://www.ietf.org/internet-drafts/draft-dhody-pce-pcep-service-aware-04= .txt > Status: = http://datatracker.ietf.org/doc/draft-dhody-pce-pcep-service-aware > Htmlized: = http://tools.ietf.org/html/draft-dhody-pce-pcep-service-aware-04 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-pcep-service-aware-04 >=20 > Abstract: > In certain networks like financial information network (stock/ > commodity trading) and enterprises using cloud based applications, > Latency (delay), Latency-Variation (jitter) and Packet loss is > becoming a key requirement for path computation along with other > constraints and metrics. Latency, Latency-Variation and Packet = Loss > is associated with the Service Level Agreement (SLA) between > customers and service providers. >=20 > [MPLS-DELAY-FWK] describes MPLS architecture to allow Latency > (delay), Latency-Variation (jitter) and Packet loss as properties. > [OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes mechanisms with > which network performance information is distributed via OSPF and > ISIS respectively. This document describes the extension to PCEP = to > carry Latency, Latency-Variation and Loss as constraints for end to > end path computation. >=20 >=20 >=20 >=20 > The IETF Secretariat ------=_NextPart_000_004C_01CDD783.8B8D8E10 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear = PCE=E2=80=99rs,

 =

We have = updated the service-aware draft (delay, jitter, packet-loss) and merged = with 'draft-ali-pce-additional-of-and-metric' as discussed during the = Atlanta WG meeting. =C2=A0

 =

Any = comments would be highly appreciated.

 =

Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-pcep-service-= aware-04

 =

Regards,

Dhruv<= /o:p>

 

****************************************************= ***************************

Dhruv = Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph. = +91-9845062422

This e-mail and = 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!

 

> = -----Original Message-----

> = From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]

> Sent: Monday, December 10, 2012 7:44 = AM

> To: = dhruv.ietf@gmail.com

> Cc: = vishwas.manral@hp.com; swallow@cisco.com; = zali@cisco.com;

> = dhruv.dhody@huawei.com; ke-kumaki@kddi.com

> Subject: New Version Notification for = draft-dhody-pce-pcep-service-aware-

> 04.txt

>

> =

> A new version of I-D, = draft-dhody-pce-pcep-service-aware-04.txt

> has been successfully submitted by Dhruv Dhody = and posted to the

> IETF = repository.

>

> Filename: = draft-dhody-pce-pcep-service-aware

> Revision: 04

> = Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Extensions = to the Path Computation Element Communication

> Protocol (PCEP) to compute service aware Label = Switched Path (LSP).

> Creation = date:=C2=A0 2012-12-10

> WG = ID:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individual = Submission

> Number of pages: = 17

> = URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 = http://www.ietf.org/internet-drafts/draft-dhody-pce-pcep-service-aware-04= .txt

> = Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = http://datatracker.ietf.org/doc/draft-dhody-pce-pcep-service-aware

> = Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = http://tools.ietf.org/html/draft-dhody-pce-pcep-service-aware-04

> = Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = http://www.ietf.org/rfcdiff?url2=3Ddraft-dhody-pce-pcep-service-aware-04<= o:p>

>

> Abstract:

> =C2=A0=C2=A0=C2=A0In certain networks like = financial information network (stock/

> =C2=A0=C2=A0=C2=A0commodity trading) and = enterprises using cloud based applications,

> =C2=A0=C2=A0=C2=A0Latency (delay), = Latency-Variation (jitter) and Packet loss is

> =C2=A0=C2=A0=C2=A0becoming a key requirement = for path computation along with other

> =C2=A0=C2=A0=C2=A0constraints and = metrics.=C2=A0 Latency, Latency-Variation and Packet = Loss

> =C2=A0=C2=A0=C2=A0is = associated with the Service Level Agreement (SLA) = between

> = =C2=A0=C2=A0=C2=A0customers and service providers.

>

> = =C2=A0=C2=A0=C2=A0[MPLS-DELAY-FWK] describes MPLS architecture to allow = Latency

> = =C2=A0=C2=A0=C2=A0(delay), Latency-Variation (jitter) and Packet loss as = properties.

> = =C2=A0=C2=A0=C2=A0[OSPF-TE-EXPRESS] and [ISIS-TE-EXPRESS] describes = mechanisms with

> = =C2=A0=C2=A0=C2=A0which network performance information is distributed = via OSPF and

> = =C2=A0=C2=A0=C2=A0ISIS respectively.=C2=A0 This document describes the = extension to PCEP to

> = =C2=A0=C2=A0=C2=A0carry Latency, Latency-Variation and Loss as = constraints for end to

> = =C2=A0=C2=A0=C2=A0end path computation.

>

> =

>

>

> = The IETF Secretariat

------=_NextPart_000_004C_01CDD783.8B8D8E10-- From daniel@olddog.co.uk Thu Dec 13 12:27:37 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F9121F8B83 for ; Thu, 13 Dec 2012 12:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] 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 m0KNvy8hN1ge for ; Thu, 13 Dec 2012 12:27:36 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7F821F898B for ; Thu, 13 Dec 2012 12:27:36 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBDKRWH6015771; Thu, 13 Dec 2012 20:27:32 GMT Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id qBDKRTX6015740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Dec 2012 20:27:31 GMT From: "Daniel King" To: Date: Thu, 13 Dec 2012 20:27:26 -0000 Message-ID: <004d01cdd970$45cdeb60$d169c220$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac3ZbwnWbGiUqhoGR3SOjUnH7na5kQ== Content-Language: en-gb Subject: [Pce] ABNO Updated - draft-farrkingel-pce-abno-architecture-01 X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 20:27:37 -0000 Hi All, Thanks for all the feedback so far. Please find a new version of the document: http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-01 Updates include: - Clarification of scope (>data center and CDN) - Updates to architecture model - Discussing implementation of the architecture - Placeholder for survivability and redundancy - General readability and nit fixes We know several people are working on text for additional use cases, and we look forward to seeing those contributions! Br, Dan & Adrian. -----Original Message----- From: Daniel King [mailto:daniel@olddog.co.uk] Sent: 01 December 2012 22:59 To: pce@ietf.org Cc: adrian@olddog.co.uk; daniel@olddog.co.uk Subject: A new draft on an architecture for application-based network operations Hi PCE'rs, Adrian and I posted an I-D which is a rather grandiose attempt to pull together a number of existing architectural components (PCE, VNTM, I2RS, policy, etc., etc.). This is a sort of meta-SDN PCE-based architect-thingy. It needed a name, so we called it Application-Based Network Operations (ABNO), warning it's not house trained and may answer to various other names: A PCE-based Architecture for Application-based Network Operations http://tools.ietf.org/html/draft-farrkingel-pce-abno-architecture-00 As some of you will know this is the result of numerous discussions we have had with a number of people over the last three months. Where pieces of the puzzle seem to have been coagulating, we thought it might be nice to build a framework in which the jelly (jello) can set. It is at a really early stage, so we are convinced you will all throw stuff at us, but what the hell! As it stands, the current draft includes: - A brief description of abstraction functional components and the interfaces between them. - An attempt to supply pointers to existing work (tool kit) where that may be applicable. - Various ABNO use cases. A number of areas need further discussion, especially the use cases. We decided to submit with the few we do have, in order to generate some feedback - anyone who wants to supply use case(s) and text, would receive hero status. We have pitched the document as a PCE working group document because PCE is a central component, but the document doesn't really fall inside the PCE charter. For the time being it might be best to send comments direct to us rather than clutter up any WG mailing list with discussions that are outside the charter (but if some WG chair wants to claim the work, then...) Thanks, Dan and Adrian From stbryant@cisco.com Mon Dec 17 10:29:50 2012 Return-Path: X-Original-To: pce@ietfa.amsl.com Delivered-To: pce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C83121F8BBB; Mon, 17 Dec 2012 10:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 vLaiBuWbibVH; Mon, 17 Dec 2012 10:29:49 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 24D7B21F8B77; Mon, 17 Dec 2012 10:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=512; q=dns/txt; s=iport; t=1355768985; x=1356978585; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=dck+bk0rjEv/+grlwx0T65yVNVJXXdWaTcqbnH0isYw=; b=Y/7BHA3L7q6Mhyqqc9OS+cYhKtkLWmvHTBb0MFokJeWMcTc9KW7YR4S+ XdBU0GaKOWvdA4NlzJGUoikq6+m5tdO0lekh9XQipor7t7WvOwTmKAOKH WTYM+L1PfdwmoU0tuIdJHUPwobJzgFDs+USmB6Bax4uVayfpKfWsCY4rC 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYHADZiz1CQ/khR/2dsb2JhbABFg0i6axZzgl1AATwWGAMCAQIBSwEMAQcBAYgPn0aaRZEgA5YKkEiCcw X-IronPort-AV: E=Sophos;i="4.84,303,1355097600"; d="scan'208";a="148473663" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 17 Dec 2012 18:29:43 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBHITgJR017592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Dec 2012 18:29:42 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id qBHITftV009601; Mon, 17 Dec 2012 18:29:41 GMT Message-ID: <50CF64A3.8060208@cisco.com> Date: Mon, 17 Dec 2012 18:29:55 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: idr mailing list , "mpls@ietf.org" , pce@ietf.org, pim@ietf.org, "idr-chairs@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , pce-chairs@tools.ietf.org, pim-chairs@toosl.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-ads@tools.ietf.org" Subject: [Pce] draft-ietf-karp-routing-tcp-analysis review requested X-BeenThere: pce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Path Computation Element List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 18:29:50 -0000 Hi all, draft-ietf-karp-routing-tcp-analysis is on the IESG agenda for 10/Jan. It has been through IETF LC, but we realize that it would be useful for the IDR, MPLS, PCE and PIM working groups to pay special attention to the draft review the sections of this draft that are relevant to their (your) work. I would appreciate feedback from anyone in the WG, but it would be helpful if the WG Chairs could nominate at least one person to review the draft on behalf of the WG. Thanks Stewart