Subject: [L2sm] Proposed Liaison to 3GPP SA5

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 4 Jun 2018 12:15:24 +0100

Hi WG,

3GPP SA5 is working on Management and orchestration of 5G networks and network slicing (http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G) and is considering various existing data models as references. 3GPP Release-15 is targeting freeze date of September 2018 and plan two meetings in June and August respectively to meet the deadline of 3GPP Release-15.
 
They seem to have been soliciting input from various SDOs (most recently the BBF) but have not approached the IETF. This may be because they already know what we are working on, or it may be because they didn't realise.

So Qin and I propose to send the following liaison statement to them for information. Since the next meeting is on June 26th, we think the deadline for sending this is should be June 15th.

Any comments or edits would be welcomed.

Thanks for any input or advice.

Qin and Adrian

=== Draft LS ===

To: 3GPP SA5
Cc: Thomas Tovinger, 3GPP SA5 Chairman
       Ignas Bagdonas and Warren Kumari, IETF Operations and Management ADs
From: Qin Wu and Adrian Farrel, IETF L2SM working group co-chairs
For: Information

We note that 3GPP SA5 is working on Management and orchestration of 5G networks and network slicing (http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-SA5_5G) and is considering various existing data models as references. 3GPP Release-15 is targeting freeze date of September 2018 and plan two meetings in June and August respectively to meet the deadline of 3GPP Release-15. We would like to take this opportunity to inform you of the status of several pieces of work in the IETF that satisfy the transport support for network slicing on IP services , L2 service, and TE service.

RFC 8299 provides A YANG Data Model for L3VPN Service Delivery.
This document is a published RFC with IETF consensus.
https://www.rfc-editor.org/rfc/rfc8299.txt
 
draft-ietf-l2sm-l2vpn-service-model provides A YANG Data Model for L2VPN
Service Delivery.
This document has achieved working group and IETF consensus, and is currently completing approval for publication as an RFC.
https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model-10.txt
 
RFC 8309 sets the previous two documents in context by explaining what the IETF means by the term "Service Model"
https://www.rfc-editor.org/rfc/rfc8309.txt
 
You may also be interested in work in the TEAS working group on Abstraction and Control of Traffic Engineered networks (ACTN).
In particular, there is YANG model for Virtual Network operation in an ACTN context that may be of specific interest to you:
https://www.ietf.org/id/draft-ietf-teas-actn-vn-yang-00.txt
 
Wishing you all success in your work,
Qin Wu and Adrian Farrel
Co-chairs, IETF L2SM working group
===END===

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 5 Jun 2018 15:01:06 +0000

Hi Adrian, All,
I absolutely agree with the proposed Liaison to 3GPP SA5. I would also suggest to mention RFC8199 on YANG Module Classification.

Best Regards,

Giuseppe

-----Original Message-----
From: L2sm [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: lunedì 4 giugno 2018 13:15
To: [email-masked]
Subject: [L2sm] Proposed Liaison to 3GPP SA5

Hi WG,

Qin and Adrian

=== Draft LS ===

To: 3GPP SA5

 
draft-ietf-l2sm-l2vpn-service-model provides A YANG Data Model for L2VPN Service Delivery.
This document has achieved working group and IETF consensus, and is currently completing approval for publication as an RFC.
https://www.ietf.org/id/draft-ietf-l2sm-l2vpn-service-model-10.txt

 

_______________________________________________
L2sm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/l2sm

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Jun 2018 16:58:08 +0100

Yes, good point.

A

> From: Fioccola Giuseppe [mailto:[email-masked]]
> Sent: 05 June 2018 16:01
> To: [email-masked]; [email-masked]
> Subject: RE: [L2sm] Proposed Liaison to 3GPP SA5
> 
> Hi Adrian, All,
> I absolutely agree with the proposed Liaison to 3GPP SA5. I would also suggest
to
> mention RFC8199 on YANG Module Classification.
> 
> Best Regards,
> 
> Giuseppe
> 
> 3GPP SA5 is working on Management and orchestration of 5G networks and
> network slicing (http://www.3gpp.org/NEWS-EVENTS/3GPP-NEWS/1951-
> SA5_5G) and is considering various existing data models as references. 3GPP
> Release-15 is targeting freeze date of September 2018 and plan two meetings in
> June and August respectively to meet the deadline of 3GPP Release-15.
> 
> They seem to have been soliciting input from various SDOs (most recently the
> BBF) but have not approached the IETF. This may be because they already know
> what we are working on, or it may be because they didn't realise.
> 
> So Qin and I propose to send the following liaison statement to them for
> information. Since the next meeting is on June 26th, we think the deadline for
> sending this is should be June 15th.
> 
> We note that 3GPP SA5 is working on Management and orchestration of 5G
> networks and network slicing (http://www.3gpp.org/NEWS-EVENTS/3GPP-
> NEWS/1951-SA5_5G) and is considering various existing data models as
> references. 3GPP Release-15 is targeting freeze date of September 2018 and
plan
> two meetings in June and August respectively to meet the deadline of 3GPP
> Release-15. We would like to take this opportunity to inform you of the status
of
> several pieces of work in the IETF that satisfy the transport support for
network
> slicing on IP services , L2 service, and TE service.
> 
> This document has achieved working group and IETF consensus, and is currently
> completing approval for publication as an RFC.
> RFC 8309 sets the previous two documents in context by explaining what the
IETF
> means by the term "Service Model"
> You may also be interested in work in the TEAS working group on Abstraction
and
> Control of Traffic Engineered networks (ACTN).
> In particular, there is YANG model for Virtual Network operation in an ACTN
> context that may be of specific interest to you:
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle
persone
> indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di
> queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto
> questo documento per errore siete cortesemente pregati di darne immediata
> comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
> 
> This e-mail and any attachments is confidential and may contain privileged
> information intended for the addressee(s) only. Dissemination, copying,
printing
> or use by anybody else is unauthorised. If you are not the intended recipient,
> please delete this message and any attachments and advise the sender by return
> e-mail, Thanks.
>

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 5 Jun 2018 16:42:03 +0000

Hi Adrian,

I agree that sending this message is a good idea. 

However, I do not think the RFC 8309 is "explaining what the IETF means by the term "Service Model". This is an informational document and as such does not represent consensus or recommendation per RFC 2026. Personally, I agree with Giuseppe that RFC 8199 is a better document but that is also an informational document.

I better text could be:
"RFC 8199 and RFC 8309 are informational documents developed by the IETF community to show examples on how service models could be implemented."

Regards,
Roque

On 05/06/18 17:58, "L2sm on behalf of Adrian Farrel" <[email-masked] on behalf of [email-masked]> wrote:

    Yes, good point.
    
    A
    
    to
    plan
    of
    network
    IETF
    and
    persone
    conoscenza di
    printing

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Jun 2018 18:36:40 +0100

Hi Roque,

Well, both documents went through IETF last call, and both 8309 and 8199 have IETF consensus. As it says in the boilerplate for both documents.

   This document is a product of the Internet Engineering Task Force
   (IETF). It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).

And as 8309 says

   This document describes service models as used within the IETF and
   also shows where a service model might fit into a software-defined
   networking architecture.

So can you clarify what your concern is? 

Thanks,
Adrian

> From: Roque Gagliano (rogaglia) [mailto:[email-masked]]
> Sent: 05 June 2018 17:42
> To: [email-masked]; 'Fioccola Giuseppe'; [email-masked]
> Subject: Re: [L2sm] Proposed Liaison to 3GPP SA5
> 
> Hi Adrian,
> 
> However, I do not think the RFC 8309 is "explaining what the IETF means by the
> term "Service Model". This is an informational document and as such does not
> represent consensus or recommendation per RFC 2026. Personally, I agree with
> Giuseppe that RFC 8199 is a better document but that is also an informational
> document.
> 
> I better text could be:
> "RFC 8199 and RFC 8309 are informational documents developed by the IETF
> community to show examples on how service models could be implemented."
> 
> Regards,
> Roque
> 
>

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 5 Jun 2018 17:41:48 +0000

Hi Adrian,

The definition of IETF informational models can be found in RFC 2026 section 4.2.2:

--------
4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.
--------

That is my point, you can't call it consensus as the purpuse of an informational model is not to reach consensus.

Roque

On 05/06/18 19:36, "Adrian Farrel" <[email-masked]> wrote:

    Hi Roque,

    
    And as 8309 says

    
    Thanks,
    Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Jun 2018 19:46:30 +0100

Hi again,

It has been a while since anyone quoted 2026 at me :-)

I think you have interpreted the text you quote the wrong way around. It is true that you cannot take an Informational RFC and make any assumption of IETF consensus. That is, it is possible to have Informational RFCs that have or do not have IETF consensus. The second paragraph describes documents that are produced under what is now called the Independent Submissions stream: they are Informational RFCs that do not (cannot) have IETF consensus.

You might find RFC 7841 helpful in understanding how IETF consensus can be applied across a range of documents: mandatory for some; optional for others.

The IESG Statement at https://www.ietf.org/blog/last-call-guidance-community/?secondary_topic=22&primary_topic=7& makes clear that the IESG considers it reasonable to IETF last call an Informational RFC. I believe that the current IESG continues the practice of issuing IETF last call and so judging IETF consensus on all RFCs on the IETF stream.

Cheers,
Adrian

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 5 Jun 2018 19:53:23 +0000

Hi Adrian,

Independently if RFC 8309 was approved following the correct process (which I believe is your latest point), we cannot refer to it as the IETF community consensual opinion on how service models should be interpreted as it was expressed in your original statement but just a recompilation of possible examples.

Please consider my contribution for a modified text:
"RFC 8199 and RFC 8309 are informational documents developed by the IETF community to show examples on how service models could be implemented."

Regards,
Roque

— 

On 05/06/18 20:46, "Adrian Farrel" <[email-masked]> wrote:

    Hi again,

    

    Cheers,
    Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Jun 2018 21:36:00 +0100

> Independently if RFC 8309 was approved following the correct process (which I
> believe is your latest point), we cannot refer to it as the IETF community
> consensual opinion on how service models should be interpreted as it was
> expressed in your original statement but just a recompilation of possible
> examples.

OK, I'm talking as a co-author of 8309, and not as L2SM co-chair. 

Why cannot we refer to it as the IETF community consensual opinion? Or is your point that I am misrepresenting the content of the document?

Cheers,
Adrian

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Tue, 5 Jun 2018 21:09:28 +0000

Hi Adrian,

In my view, the "IETF consensual opinion" for a best practice (such as how to use a service model) is the role of the IETF BCP documents track  and not informational documents tracks. Both RFC8199 and RFC8309 are at the same level as just documentation pieces that the IETF agreed they were worth publishing and recording. I do not believe the IETF should write a BCP on this domain and I agree on the classification of both documents as informational.

Please consider my contribution for a modified text to the 3GPP:
    "RFC 8199 and RFC 8309 are informational documents developed by the IETF community to show examples on how service models could be implemented."

Roque

    

    Cheers,
    Adrian