[L3sm] RFC 8049 on YANG Data Model for L3VPN Service Delivery

[previousqna]

A new Request for Comments is now available in online RFC libraries.

        RFC 8049

        Title:      YANG Data Model for L3VPN 

                    Service Delivery 

        Author:     S. Litkowski, L. Tomotaki, K. Ogaki

        Status:     Standards Track

        Stream:     IETF

        Date:       February 2017

        Mailbox:    stephane.litkowski@orange.com, 

                    luis.tomotaki@verizon.com, 

                    ke-oogaki@kddi.com

        Pages:      157

        Characters: 272974

        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-l3sm-l3vpn-service-model-19.txt

        URL:        https://www.rfc-editor.org/info/rfc8049

        DOI:        10.17487/RFC8049

This document defines a YANG data model that can be used for

communication between customers and network operators and to deliver

a Layer 3 provider-provisioned VPN service.  This document is limited

to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This

model is intended to be instantiated at the management system to

deliver the overall service.  It is not a configuration model to be

used directly on network elements.  This model provides an abstracted

view of the Layer 3 IP VPN service configuration components.  It will

be up to the management system to take this model as input and use

specific configuration models to configure the different network

elements to deliver the service.  How the configuration of network

elements is done is out of scope for this document.

This document is a product of the L3VPN Service Model Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track

protocol for the Internet community, and requests discussion and suggestions

for improvements.  Please refer to the current edition of the Official

Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 

standardization state and status of this protocol.  Distribution of this 

memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.

To subscribe or unsubscribe, see

  https://www.ietf.org/mailman/listinfo/ietf-announce

  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search

For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the

author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless

specifically noted otherwise on the RFC itself, all RFCs are for

unlimited distribution.

The RFC Editor Team

Association Management Solutions, LLC

[previousqna]

Hi team,

Are there already some plans how we are going to address this standard L3 VPN service model in NSO? E.g. are we going to replace our current example L3 VPN model with this one? Are we going to provide half-baked service implementation for e.g. IOS and IOS XR?

Thanks in advance,

[previousqna]

No such plan at the moment. Any customer interest do you think?

[previousqna]

I think that many of the Tier 2/3 SPs (and this is my customer base) will be looking to reuse the work done by the IETF on the service model. Moreover, it will be hard to explain why we are not using the deliverable from the standard body.

[previousqna · Accepted solution]

We are actively looking for takers (i.e. customers that show tangible interest in deployibg standard l3sm models) to work through how the model would work in a real network. So if you have anyone lined up that would be very helpful.

Just because the IETF published the spec does not mean that it's useful :-) The YANG model itself is valid, so can be loaded into NSO, but it's a little hard to understand from the spec how it is supposed to work. This is what we would be trying to figure out with a motivated customer.

[previousqna]

Just because the IETF published the spec does not mean that it's useful :-) The YANG model itself is valid, so can be loaded into NSO, but it's a little hard to understand from the spec how it is supposed to work. This is what we would be trying to figure out with a motivated customer.

As long as we're writing RFCs instead of code, it's not useful at all.

There is not even a link in the RFC that points to a repo where I can download the model.

[previousqna]

A generic model needs to cater for all eventualities and options, and hence will be very complex. This may be an academically “interesting” thing to do, if you’re into that kind of thing, but I doubt very much it will be practical.

I spent a long time on Prime Provisioning, trying to create a product that worked for as many customers as possible. We ended up with something that was so full of compromises that it didn’t work well for many.

Questions that impact how you model your L3VPN service (amongst many others)

• Is the CPE managed?
• How is CPE connected to the PE (access network technology, topology, dual-homing, dual-cpe, etc. etc.)
• What is the VPN topology? (fully meshed, partially meshed, extranets, etc. etc.)
• Inter-AS considerations
• OSS architecture – do you model the aspects listed above in NSO, or do you manage topologies etc. in another system, and provide them explicitly to NSO at service activation time
• Which resources are automatically allocated? Are they allocated in NSO, or in a layer above (or some in each layer)?
• Etc. etc. etc.

If you look at the ancient L3VPN demo on YouTube, it has made some assumptions for these:

https://www.youtube.com/watch?v=sYuETSuTsrM&t

But you could model exactly the same thing in a million different ways, depending on each SP’s requirements.

[previousqna]

Just because the IETF published the spec does not mean that it's useful :-) The YANG model itself is valid, so can be loaded into NSO, but it's a little hard to understand from the spec how it is supposed to work. This is what we would be trying to figure out with a motivated customer.

As long as we're writing RFCs instead of code, it's not useful at all.

That's why none of us are on the RFC. We are indeed writing code instead!

There is not even a link in the RFC that points to a repo where I can download the model.

RFCs are self-contained. https://github.com/xym-tool/xym is a convenient tool to extract modules from RFCs and drafts.

[previousqna]

Thanks, was not aware of the existence if xym.

[previousqna]

In H2 of this FY we are planning PoCs with two customers (Telekom Serbia and United Group), and primary target for both is L3 VPN service. In next couple of weeks I will have meetings with them and get back to you.

[previousqna]

Hi,

I disagree.

There is not greenfield SPs anymore. They know they cannot apply recipes “as is”. These models are “reference only” and should remain that way. I personally believe they should be “informational” and not “standard” as they only represent what we know today but l3vpn evolve over time.

An actual NSO customer told me: “Roque, there won’t be a McDonald's of service models”.