Re: [Supa] minutes of the 5/26 SUPA call

Maxim Klyus <klyus@NetCracker.com> Fri, 29 May 2015 09:04 UTC

Return-Path: <klyus@NetCracker.com>
X-Original-To: supa@ietfa.amsl.com
Delivered-To: supa@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359901A1A97 for <supa@ietfa.amsl.com>; Fri, 29 May 2015 02:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.211
X-Spam-Level:
X-Spam-Status: No, score=-6.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 8lpBOvMQE2KQ for <supa@ietfa.amsl.com>; Fri, 29 May 2015 02:04:56 -0700 (PDT)
Received: from umail.netcracker.com (umail.netcracker.com [84.47.142.180]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C67C1A8AD9 for <supa@ietf.org>; Fri, 29 May 2015 02:04:55 -0700 (PDT)
From: Maxim Klyus <klyus@NetCracker.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "supa@ietf.org" <supa@ietf.org>
Thread-Topic: [Supa] minutes of the 5/26 SUPA call
Thread-Index: AdCYSiOkiq1tm2v1QVaQ9v1ncItXCABJhq1w
Date: Fri, 29 May 2015 09:04:52 +0000
Message-ID: <11D8792D50CD7F46BFBA62E9E61D5A3A9DAC7C5A@umaildb5.netcracker.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA5CA3BEA1@AZ-FFEXMB04.global.avaya.com>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5CA3BEA1@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/supa/JGO3wUVxr9_WfycQ69fLpekDPno>
Subject: Re: [Supa] minutes of the 5/26 SUPA call
X-BeenThere: supa@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This list is to discuss SUPA \(Shared Unified Policy Automation\) related issues." <supa.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/supa>, <mailto:supa-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/supa/>
List-Post: <mailto:supa@ietf.org>
List-Help: <mailto:supa-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/supa>, <mailto:supa-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 09:04:58 -0000

Hi, SUPA.

As I said on the last meeting my proposal for supa ---> ietf connection is define inside or outside Johns draft some additional classes inherited from Composite Policy - Traffic Management, QoS and Security.
I already mentioned it in my previous letter, but it looks like nobody disagreed or agreed with me, unfortunately just no comments at all.

I checked BGP draft https://tools.ietf.org/html/draft-zhdankin-idr-bgp-cfg-00 and I still have the same proposal (please see below).
I don't think now this mapping can be done directly may be, but we can think how to do it best way.
And I would like to have some argumented comments on it. Why it's unreasonable /reasonable, how it could be done more properly.
Thanks to everybody in advance.

BGP policy in overall Policy structure

+-SUPAPolicyComposite
     |
     +--Traffic Management Policy (SUPAPolicyComposite class)
         +--MPLS Policy
         +--L2 Policy
         +--L3 Policy
              |
              +--L3 Routing policy   (SUPAPolicyComposite class)
                   |
             +--Protocol based routing policy     (SUPAPolicyComposite class)
             |     +--RIP Policy
                   |     +--OSPF Policy
                   |     +--ISIS Policy                                                           [BGP Module]
                   |     +--BGP Policy                                          ----->    +--rw bgp-router                      (SUPAPolicyAtomic class)
                   |           +--BGP generic attributes policy   ----->    +--rw bgp-router                     (SUPAECAComponent class)
                   |           +--AF Policy                                       ----->    +--rw af-configuration           (SUPAECAComponent class)
                   |           +--BGP Neighbors Policy                ----->    +--rw bgp-neighbors              (SUPAECAComponent class)
                   |           +--RPKI Policy                                   ----->    +--rw rpki-config                     (SUPAECAComponent class)
                   |           +--Prefix-list Policy                         ----->    +--rw prefix-lists                     (SUPAECAComponent class)
             |
                   +--Source-based routing policy

Best Regards,
Max Klyus


From: Supa [mailto:supa-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, May 27, 2015 9:56 AM
To: supa@ietf.org
Subject: [Supa] minutes of the 5/26 SUPA call

Hi,

Please find below the meeting notes from the SUPA call on 5/26. Please let me know if anything important is missing, or I caught it wrongly.

Thanks and Regards,

Dan

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

Initial agenda:

1. Note Well, logistics, agenda bashing (chairs, 0 min)

2. Updated charter (Juergen/John, 20 min)

3. How does the framework improve and simplify existing work - for example in routing, or ACLs. (John/Juergen, 20 min)

4. Steering (Benoit, 20 min)



2. Tina and Dan reported on discussions with Benoit during the last week. Benoit feels now more comfortable with the scope of work, but his opinion is that the charter is still hard to read for somebody not familiar with the previous discussions, and the scope of work does not appear evident from the charter. His advice is that the team works to simplify the charter text and include some of the discussions related to 'critical questions' in order to make the scope and deliverables appear clear in a manner simple to understand for people not familiar with the work, and also explain relations with other WGs work as well as how other WGs will relate and use this work.

Benoit also advised to create a wiki where the principal discussions can be documented in a Q&A format.

Benoit delegated the co-chairs of the BOF to go ahead and submit a request for a WG-forming BOF in the wiki if they feel comfortable that the team made enough progress in focusing the scope and deliverables and writing a more clear charter.

John and Juergen will make another pass on the charter text, provide new improved version to be included in the BOF request.

Giorgios and the other authors will work to update the problem statement I-D until the end of the next week, so that an update version can be ready together with the other materials to support the BOF request.

3. John shared notes from reading and reviewing the DiffServ Policy I-D form NETMOD. It contains very little policy stuff, the way SUPA approaches policy. Dan asked what would be different if the SUPA work already existed. John replied that the Information Model would provide the basic constructs and objects for defining policies, and this would allow for the DiffServ model to be smaller and more consistent, avoid duplication and definition of many non-reusable objects.   Dan observed that this could be a good example of Q&A to be included in the wiki page.

John suggested that some of the policy data modelling work done in other WGs could be moved to SUPA. Dan responded that this does not seem to be realistic, as other WGs are already chartered and work is ongoing, with their own schedules. Sue agreed and observed that the data models work in the routing area is proceeding and cannot wait for SUPA to define the generic model. The BGP data model is cornerstone for work done by all other modeling efforts in I2RS, IVR, TESS. Mid-June is the milestone for providing significant input. SUPA should proceed as fast as it can with the abstract framework, but it would be a concurrent effort at best that needs collaboration and synchronization.

4. Benoit could not attend the call, but we discussed his comments and advice to Tina and Dan.

Tina entered a request for a wiki page. Dan suggested to make it accessible to all participants in the SUPA work and in the IETF, so that it can become an interactive page for sharing information. Sue agrees and suggested that separate sections or children pages can be dedicated to specific policy work in other WGs. Dan is fine with the proposal, and encourages other WG participants to ask questions and contribute with material. Sue will distribute information about the wiki as soon as it becomes available. Dan will write some of the initial content based on the responses to the 'critical questions'.

John, Max and Sue will work on the review of the policy models from I2RS. Will be presented in the call next Monday.

Juergen observed that there is need to consolidate some of the information and content of the current I-Ds. Dan pointed to the documents related to the distributed data center use case. These need consolidation, as we need to decide soon whether they stay in the deliverables list (currently #5). Right now the focus is on #1, #2, #3.



________________________________
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.