Subject: Re: [Supa] Fwd.: [L3sm] Some background on the L3VPN Service YANG Model work

From: "Jun Bi" <[email-masked]>
Date: Sat, 7 Mar 2015 13:03:34 +0800

Thanks！

Certainly I agree with the charter. 

I just saw there are some discussion on overlap with other WG, then show my personal option.

To avoid any conflicts with other WGs, if the SUPA charter could focus on policy/protocols in multiple controllers environment

(a policy needs to be applied to more than two domains, e.g. two DDCs), it might be a more clear picture.

Just my two cents.

Jun

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tina TSOU
Sent: Saturday, March 7, 2015 10:38 AM
To: Juergen Schoenwaelder
Cc: Benoit Claise; Jun Bi; [email-masked]
Subject: Re: [Supa] Fwd: [L3sm] Some background on the L3VPN Service YANG Model work

Dear Jun et al,

If you go to

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

Under

Operations and Management

SUPA (Approved as BOF for IETF 92)

Click

Draft charter:  <http://cnds.eecs.jacobs-university.de/users/schoenw/supa/> ​http://cnds.eecs.jacobs-university.de/users/schoenw/supa/

You could find

http://cnds.eecs.jacobs-university.de/users/schoenw/supa/supa-charter-2015-02-04.txt

Thank you,

Tina

On Mar 7, 2015, at 1:30 AM, Juergen Schoenwaelder <[email-masked] <mailto:[email-masked]> > wrote:

There once was a draft charter we agreed on and I think that answered
your question.

/js

On Sat, Mar 07, 2015 at 12:09:22AM +0800, Jun Bi wrote:

Hi All,

I have a couple of questions or suggestions on SUPA scope.

Is SUPA for policy for Traffic Steering on cross-DDC traffic or we want to

general SUPA policy framework ?

(1)

In the initial stage, shall SUPA only define policy for Traffic Steering on

cross-DDC traffic ?

Thought this is a limited scope, it would be easier to state the problem and

the gap.

It might be considered as the initial goal of SUPA and after we finish the

first phase, we may consider to extend to other scenarios.

(2)

If we want a boarder scope and general scenario, then could SUPA only define

protocol between service managers and controllers, then the service manager

provide programming interfaces to the highest level of users/administrators.

It means that SUPA works at any scenario that *two or more controllers are

involved*, and a higher level server manager is on top of them to centralize

and coordinate policies between different controllers.

In this case, I2RS or other L3VPN service mode are working between

manager/controller and devices, while SUPA won't tough any part of devices. 

Each controller use I2R, etc. to talk with devices, and talk with upper

manager/policy controller by using SUPA. When an user wants read a topology

and set a policy, it use SUPA's Yang model to define. 

The topology required could be virtual topology, then controllers translate

to physical topology and talk to devices by I2RS, etc.

Just my two cents.

Best Regards,

Jun

-----Original Message-----

From: [email-masked] <mailto:[email-masked]>  [mailto:[email-masked]] On Behalf Of

Juergen Schoenwaelder

Sent: Thursday, March 5, 2015 7:14 PM

To: Benoit Claise

Cc: [email-masked] <mailto:[email-masked]> 

Subject: Re: [Supa] Fwd: [L3sm] Some background on the L3VPN Service YANG

Model work

Benoit,

this of course comes along as a BIG surprise for those who have been working

towards service management models in the public.

/js

On Wed, Mar 04, 2015 at 02:52:06PM +0100, Benoit Claise wrote:

FYI.

Regards, Benoit

-------- Forwarded Message --------

Subject:    [L3sm] Some background on the L3VPN Service YANG Model work

Date:    Wed, 4 Mar 2015 14:40:52 +0100

From:    Benoit Claise <[email-masked] <mailto:[email-masked]> >

To:    [email-masked] <mailto:[email-masked]> 

Dear all,

Let me give you some background on this new piece of work: The Layer 

Three Virtual Private Network Service Model (L3SM)

Three months ago, Adrian Farrel and I set up a design team to create a 

L3VPN _service _YANG model.

It needs to be clearly understood that this L3VPN _service _model is 

not an L3VPN configuration model. That is, it does not provide details 

for configuring network elements or protocols. Instead it contains the 

characteristics of the service, as discussed between the operators and 

their customers.  Therefore, that design team was composed of 

operators only.

That design team created a first draft: 

http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/

Now that the draft has been posted, the work and discussion should 

continue in a public forum, i.e. this [email-masked] <mailto:[email-masked]>  mailing list.

Next step? we're busy trying to create a new short-lived WG, focusing 

solely on this L3VPN service YANG model.

See the proposal at 

https://datatracker.ietf.org/doc/charter-ietf-l3sm/

If this WG is created (This proposal is on the IESG telechat this week 

for external review approval), this would be a good test for the IETF

community: are we ready to standardize a first service YANG model? 

Personally, I believe we are.

IMO, the advantage/driver for this work is explained in the charter

proposal:

  The deliverable from this working group will provide information to 

  evaluate the

  set of YANG models that have already been developed or are under 

  development,

  and will help identify any missing models or details.  The deliverable 

  can be

  viewed as driving requirements for protocol configuration model so that

  the

  service parameters can be mapped into inputs used by the protocol

models.

Don't hesitate to forward this email.

   List address: [email-masked] <mailto:[email-masked]> 

   Archive: http://www.ietf.org/mail-archive/web/l3sm/

   To subscribe: https://www.ietf.org/mailman/listinfo/l3sm

Regards, Benoit

 

_______________________________________________

L3sm mailing list

[email-masked] <mailto:[email-masked]> 

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

_______________________________________________

Supa mailing list

[email-masked] <mailto:[email-masked]> 

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

-- 

Juergen Schoenwaelder           Jacobs University Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany

Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________

Supa mailing list

[email-masked] <mailto:[email-masked]> 

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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

_______________________________________________
Supa mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/supa