Subject: Re: [Pce] A new draft on an architecture for application-based network operations

From: "Daniel King" <[email-masked]>
Date: Fri, 7 Dec 2012 14:51:55 -0000

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:[email-masked]] 
Sent: 06 December 2012 19:58
To: [email-masked]; [email-masked]
Cc: [email-masked]
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" <[email-masked]>

To: <[email-masked]>

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

         network  operations

Message-ID: <[email-masked]>

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

[email-masked]

https://www.ietf.org/mailman/listinfo/pce

End of Pce Digest, Vol 99, Issue 1

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Dec 2012 15:13:08 -0000

Hi Quintin,

Following up with some more detail on top of Dan's email.

>> following questions and suggestions. 

Thanks for reading and commenting.
Answers in line.

>> 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.

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)? 
>
>> 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 
>> 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?
>
> 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

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.

>> 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.  

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.

>> 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. 

Agreed. (Unless someone else writes the text first :-)

Thanks,
Adrian