Subject: [OPSAWG] Review of draft-evenwu-opsawg-yang-composed-vpn-02

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 5 Mar 2019 09:22:51 -0000

Hi authors,

I see you posted -02 and so I have given it a quick review. I spent my time
on the early sections because those are the ones that introduce the ideas to
the new reader.

Feel free to discuss, although the changes are basically editorial.

Best,
Adrian

===

Abstract

OLD
   This document defines a YANG data model that can be used by a network
   operator to configure a VPN service spanning across multiple
   administrative domains environment consisting of L2VPN or L3VPN or a
   mixture of the two.
NEW
   This document defines a YANG data model that can be used by a network
   operator to configure a VPN service that spans multiple
   administrative domains and that is constructed from component VPNs in
   each of those administrative domains.  The component VPNs may be 
   L2VPN or L3VPN or a mixture of the two.
END

Would be nice to split the Abstract into two paragraphs. Probably before
"This model is not a configuration model..."

---

Section 1

OLD
   In some cases, a VPN service needs to span different administrative
   domains of different geographic areas since there is usually an
   internal administrative boundary within a single SP,e.g.,backhaul
   versus core versus data center.  Particularly, the different domain
   could deploy Layer 2 or Layer 3 or both technology and establish
   layer dependent connectivity service.  For example, some SPs extend
   their conventional L2VPN in the metro access network into IP VPN in
   the core network to provide end-to-end BGP IP VPN services to their
   enterprise customers.
NOTES
- Is the mention of "different geographic areas" specially relevant? 
  Isn't this function completely the same for different administrative
  domains in overlapping geographic areas?  I think this is just giving
  an example of why the function may be needed.
- I can't make sense of "e.g., backhaul versus core versus data center."
  I think you mean just to list some different network scenarios.
SUGGESTED NEW
   In some cases, a VPN service needs to span different administrative
   domains.  This will usually arise when there are internal
   administrative boundaries within a single Service Provider's (SP's) 
   network.  The boundaries may reflect geographic dispersal or
   functional decomposition, e.g., access, metro, backhaul, core, and
   data center.
   
   In particular, the different domains could deploy Layer 2 or Layer 3
   technologies or both, and could establish layer-dependent 
   connectivity services.  For example, some SPs offer a L2VPN service 
   in the metro access network and extend it across the core network as
   an IP VPN to provide end-to-end BGP IP VPN services to their 
   enterprise customers.
END

---

Section 1

s/and Core network/and Core networks/
s/mobile broadband service/mobile broadband services/

---

Section 1

OLD
   These require to stitch multiple
   layer dependent connectivity service at different administrative
   domain.
NEW
   These require stitching multiple
   layer-dependent connectivity services at different administrative
   domain boundaries.
END

---

Section 1

OLD
   This document defines a YANG data model that can be used by a network
   operator to provision a VPN service in multiple administrative domain
   environment consisting of Layer 2 or Layer 3 technology and construct
   an end to end VPN connectivity service across multiple administrative
   domain [RFC8309] 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 common view of VPN service configuration
   components segemented at different layer and administrative domain.
   It is up to a management system to take this as an input and generate
   specific configurations models to configure the different network
   elements within each administrative domain to deliver the service.
   How configuration of network elements is done is out of scope of the
   document.
NEW
   This document defines a YANG data model that can be used by a network
   operator to construct an end-to-end service across multiple
   administrative domains.  This service is delivered by provisioning
   VPN services utilising Layer 2 or Layer 3 technologies in each 
   domain.
   
   This model is intended to be instantiated at the management system to
   deliver the overall service per [RFC8309].  It is not a configuration
   model to be used directly on network elements.  This model provides 
   an abstracted common view of VPN service configuration components 
   segmented at different layers and administrative domains.  It is up
   to a management system to take this as an input and generate specific
   configurations models to configure the different network elements
   within each administrative domain to deliver the service.  How
   configuration of network elements is done is out of scope of the
   document.
END

---

Section 2

s/Access point:/Access point (AP):/

OLD
   Segment VPN:  Describes generic information about VPN in the
      corresponding administrative domain and specific information about
      AP connecting either the site or another Segment VPN.

   Composed VPN:  Describes generic information about VPN in the end to
      end manner and specific customer facing information about AP
      connecting to each site.
NEW
   Segment VPN:  Describes generic information about a VPN in a single
      administrative domain, and specific information about APs that
      connect the Segment VPN to sites or to other Segment VPNs.

   Composed VPN:  Describes generic end-to-end information about a VPN
      that spans multiple administrative domains, and specific customer-
      facing information about APsconnecting to each site.
END

---

Section 3

s/end to end IP or Ethernet connectivity/end-to-end IP or Ethernet
connectivity service/

s/end to end manner/end-to-end manner/

---

Section 3

You need to clarify the relative positions of Domain 1, Domain 2, and Domain
N. Are 1 and 2 the edges, with N being the transit? Or is 1 the source, 2 a
transit domain, and N the destination? Or is 1 the composed VPN as in Figure
1?

---

Section 3.2

OLD
   Figure 1 describes a scenario of Mobile Backhaul Network with L2VPN
   interconnection to L3VPN.  The network contains two domains, domain A
   and domain B.  Domain A and B are interconnected with links.
NEW
   Figure 1 describes a scenario where connectivity in the form of an 
   L3VPN is provided across a Mobile Backhaul Network.  The network has
   two ASes: connectivity across AS A is achieved with an L2VPN, and 
   across AS B an L3VPN.  The ASes are interconnected, and the composed
   VPN is achieved by interconnecting the L2VPN with the L3VPN.
END

---

Figure 1.

You should label the ASBRs as ASBR A and ASBR B because you refer to them in
the text.

s/|----SegVPN:VLL1.1/|+---SegVPN:VLL1.1/

AP2 is missing a '\'

In ASBR B    s/++ ++++/+++++++/

---

3.2

s/a logic connection/a service/

---

Section 4

It would be good to give the figure a number and title. You can then refer
to the figure from the text using the reference.

Actually, this figure is really helpful to understanding the definition of a
composed VPN and the purpose of the document. I wonder whether it doesn't
belong higher up the document.

---

Section 5

OLD
   The idea of the composed VPN model is to decompose an end to end
   L2VPN or L3VPN service across multiple administrative domain
   environment into point to point VPN segment or multi-point VPN
   segment in each administrative domain and stich these segments by
   using different Interworking options.  Therefore, a complete composed
   VPN instance consists of:
NEW                               
   The idea of the composed VPN model is to decompose an end-to-end
   L2VPN or L3VPN service across multiple administrative domains
   into point-to-point VPN segments or multi-point VPN segments in each
   administrative domain, and to stich these segments together by using
   different interworking options.  Therefore, a complete composed
   VPN instance consists of:
END

s/Similarly with/Similar to the/

---

From: "Roni Even (A)" <[email-masked]>
Date: Tue, 5 Mar 2019 10:41:02 +0000

Hi Adrian,
Thanks for the review. I will update the document using your proposals

BR
Roni

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, March 05, 2019 11:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: Review of draft-evenwu-opsawg-yang-composed-vpn-02

Hi authors,

I see you posted -02 and so I have given it a quick review. I spent my time on the early sections because those are the ones that introduce the ideas to the new reader.

Best,
Adrian

===

Abstract

OLD

Would be nice to split the Abstract into two paragraphs. Probably before "This model is not a configuration model..."

---

Section 1

OLD

---

Section 1

---

Section 1

OLD

---

Section 1

OLD

---

Section 2

OLD

---

Section 3

s/end to end IP or Ethernet connectivity/end-to-end IP or Ethernet connectivity service/

---

Section 3

You need to clarify the relative positions of Domain 1, Domain 2, and Domain N. Are 1 and 2 the edges, with N being the transit? Or is 1 the source, 2 a transit domain, and N the destination? Or is 1 the composed VPN as in Figure 1?

---

Section 3.2

OLD

---

Figure 1.

You should label the ASBRs as ASBR A and ASBR B because you refer to them in the text.

AP2 is missing a '\'

---

3.2

---

Section 4

It would be good to give the figure a number and title. You can then refer to the figure from the text using the reference.

Actually, this figure is really helpful to understanding the definition of a composed VPN and the purpose of the document. I wonder whether it doesn't belong higher up the document.

---

Section 5

OLD