Subject: [Teas] consideration of 1 VPN to N VNs mapping

From: "Ogaki, Kenichi" <[email-masked]>
Date: Tue, 4 Aug 2020 18:49:43 +0900

Hi draft-ietf-teas-te-service-mapping-yang authors,

Could you consider 1 to N mapping for the L3VPN to VN mapping?

As we required some changes to actn-vn-yang before/during 108th meeting, we would like to also discuss an additional requirement to te-service-mapping-yang. Sorry, late for 108th meeting.

If we correctly understand the current definition, only one VN is allowed to be mapped to a VPN as described in section 4.1 and the model in section 6.1.1.
However, L3SM expects to differentiate traffic handling per qos-profile which corresponds to key network performance constraints including bandwidth and latency, etc. as described in section 6.12.3.2 of RFC8299.
As an operator, we believe this means that a qos-profile should be mapped to a VN like this:

   module: ietf-l3sm-te-service-mapping
     augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:vpn-services
               /l3vpn-svc:vpn-service:
       +--rw te-service-mapping!
          +--rw te-mapping
             +--rw mapping* [mapping-id]
                +--rw mapping-id
                +--rw target-class-id?        -> /l3vpn-svc:l3vpn-svc/vpn-profiles
                |                                  /valid-provider-identifiers/qos-profile-identifier
                |                                  /id
                +--rw map-type?               identityref
                +--rw availability-type?      identityref
                +--rw (te)?
                   +--:(vn)
                   |  +--rw vn-ref?           -> /vn:vn/vn-list/vn-id
                   +--:(te-topo)
                   |  +--rw vn-topology-id?   te-types:te-topology-id
                   |  +--rw abstract-node?
                   |          -> /nw:networks/network/node/node-id
                   +--:(te-tunnel)
                      +--rw te-tunnel-list*   te:tunnel-ref

Also, in L3SM, qos-profile can be locally defined under site-network-access and also mapped to classification rules defined there as described in 6.12.3.2/6.12.3.1. Then, te-service-mapping-yang should also map a VNAP to the local qos-profile even without vpn-service level mapping like this:

     augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
               /l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access
               /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile
               /l3vpn-svc:profile:
       +--rw (te)?
          +--:(vn)
             +--rw vn-ap-ref?
                     -> /vn:ap/access-point-list/vn-ap/vn-ap-id

     augment /l3vpn-svc:l3vpn-svc/l3vpn-svc:sites/l3vpn-svc:site
               /l3vpn-svc:site-network-accesses/l3vpn-svc:site-network-access
               /l3vpn-svc:service/l3vpn-svc:qos/l3vpn-svc:qos-profile/l3vpn-svc:classes
               /l3vpn-svc:class:
       +--rw (te)?
          +--:(vn)
             +--rw vn-ap-ref?
                     -> /vn:ap/access-point-list/vn-ap/vn-ap-id

Although we may consider the same requirement to L2SM mapping, from our service objectives, the current definition is enough for now.

How do you think?

Thanks in advance,
Kenichi

-- 
Kenichi Ogaki
KDDI Corp. | Operation Automation Promotion Dept.
+81-(0)80-5945-9138 | www.kddi.com

---

From: Dhruv Dhody <[email-masked]>
Date: Tue, 4 Aug 2020 16:24:02 +0530

Hi Kenichi,

I have not looked into it in detail but my understanding of the
classes in the custom qos-profile is that they are about the access
CE-PE link and thus would not lead to the creation of a separate VN
per class.

Even in the example
https://tools.ietf.org/html/rfc8299#section-6.12.3.2 it says how the
100 Mbps on the access link is shared between the 3 classes.

There is an 'end-to-end leaf' that says bandwidth reservation needs to
be done in MPLS network but I did not interpret that it requires
maintaining a separate VN, the consolidated requirements from all
classes can be mapped to a single VN and the QoS is applied at the
edges as per the L3SM YANG.

Anyways, let me get this verified from L3SM experts and come back to you.

Thanks!
Dhruv

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Wed, 5 Aug 2020 09:58:42 +0900

Hi Dhruv,

Thanks for the prompt reply.

>There is an 'end-to-end leaf' that says bandwidth reservation needs to be done in MPLS network but I did not interpret that it requires maintaining a separate VN, the consolidated requirements from all classes can be mapped to a single VN and the QoS is applied at the edges as per the L3SM YANG.

As you saw in section 6.12.3.2, the properties of custom qos-profile include latency, and we honestly want the per-flow, classification rule, based VN mapping mechanism.

>Anyways, let me get this verified from L3SM experts and come back to you.

Your colleague and one of co-editors of both te-service-mapping and RFC8299, Qin Wu, is familiar with this discussion like this:
https://mailarchive.ietf.org/arch/msg/l3sm/i5srx8YpD9296bu3VuIkHgAEi3g/
Q.12 from David Ball

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Dhruv Dhody
Sent: Tuesday, August 4, 2020 7:54 PM
To: Ogaki, Kenichi <[email-masked]>
Cc: 宮坂 拓也 <[email-masked]>; 丹羽 朝信 <[email-masked]>; [email-masked]; TEAS WG ([email-masked]) <[email-masked]>
Subject: Re: [Teas] consideration of 1 VPN to N VNs mapping

Hi Kenichi,

I have not looked into it in detail but my understanding of the classes in the custom qos-profile is that they are about the access CE-PE link and thus would not lead to the creation of a separate VN per class.

Even in the example

There is an 'end-to-end leaf' that says bandwidth reservation needs to be done in MPLS network but I did not interpret that it requires maintaining a separate VN, the consolidated requirements from all classes can be mapped to a single VN and the QoS is applied at the edges as per the L3SM YANG.

Thanks!
Dhruv

> Although we may consider the same requirement to L2SM mapping, from our service objectives, the current definition is enough for now.

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

---

From: Young Lee <[email-masked]>
Date: Wed, 5 Aug 2020 19:05:34 +0900

Hi Kenichi and Dhruv,

I think we can relax the mapping between VPN: VN to 1:N as Kenichi was
asking this question. I carefully read RFC 8299 and captured the following:
in section 6.12.3.2 where QoS profile is defined:

  o  latency: used to define the latency constraint of the class.  The
      latency constraint can be expressed as the lowest possible latency
      or a latency boundary expressed in milliseconds.  How this latency
      constraint will be fulfilled is up to the SP's implementation of
      the service: a strict priority queuing may be used on the access
      and in the core network, and/or a low-latency routing
      configuration may be created for this traffic class.

   o  jitter: used to define the jitter constraint of the class.  The
      jitter constraint can be expressed as the lowest possible jitter
      or a jitter boundary expressed in microseconds.  How this jitter
      constraint will be fulfilled is up to the SP's implementation of
      the service: a strict priority queuing may be used on the access
      and in the core network, and/or a jitter-aware routing
      configuration may be created for this traffic class.
   o  bandwidth: used to define a guaranteed amount of bandwidth for the
      class of service.  It is expressed as a percentage.  The
      "guaranteed-bw-percent" parameter uses available bandwidth as a
      reference.  When the qos-profile container is implemented on the
      CE side, svc-output-bandwidth is taken into account as a
      reference.  When it is implemented on the PE side, svc-input-
      bandwidth is used.  By default, the bandwidth reservation is only
      guaranteed at the access level.  The user can use the "end-to-end"
      leaf to request an end-to-end bandwidth reservation, including
      across the MPLS transport network.  (In other words, the SP will
      activate something in the MPLS core to ensure that the bandwidth
      request from the customer will be fulfilled by the MPLS core as
      well.)  How this is done (e.g., RSVP reservation, controller

      reservation) is out of scope for this document.

>From the highighted text, VPN may have different QoS profile within VPN

identifier. Although it is primarily meant for CE-PE level commitment,

depending on the operator's need, it can be extended site to site (source to

destination) per the colored text. This implies a set of different
TE-tunnels that

meet the corresponding QoS profile can be supported. In that sense, I think

1:N mapping between a VPN instance to a VN instance is possible.

Kenichi, is that what you are trying to say? Please correct me if my
understaning

is incorrect.

Thanks.

Young

2020년 8월 5일 (수) 오전 10:08, Ogaki, Kenichi <[email-masked]>님이 작성:

> >There is an 'end-to-end leaf' that says bandwidth reservation needs to be
> done in MPLS network but I did not interpret that it requires maintaining a
> separate VN, the consolidated requirements from all classes can be mapped
> to a single VN and the QoS is applied at the edges as per the L3SM YANG.
>
> As you saw in section 6.12.3.2, the properties of custom qos-profile
> include latency, and we honestly want the per-flow, classification rule,
> based VN mapping mechanism.
>
> Your colleague and one of co-editors of both te-service-mapping and
> RFC8299, Qin Wu, is familiar with this discussion like this:
> Cc: 宮坂 拓也 <[email-masked]>; 丹羽 朝信 <[email-masked]>;
> [email-masked]; TEAS WG ([email-masked])
> <[email-masked]>
> I have not looked into it in detail but my understanding of the classes in
> the custom qos-profile is that they are about the access CE-PE link and
> thus would not lead to the creation of a separate VN per class.
>
> Even in the example
> There is an 'end-to-end leaf' that says bandwidth reservation needs to be
> done in MPLS network but I did not interpret that it requires maintaining a
> separate VN, the consolidated requirements from all classes can be mapped
> to a single VN and the QoS is applied at the edges as per the L3SM YANG.
>
> > As we required some changes to actn-vn-yang before/during 108th meeting,
> we would like to also discuss an additional requirement to
> te-service-mapping-yang. Sorry, late for 108th meeting.
> >
> > If we correctly understand the current definition, only one VN is
> allowed to be mapped to a VPN as described in section 4.1 and the model in
> section 6.1.1.
> > However, L3SM expects to differentiate traffic handling per qos-profile
> which corresponds to key network performance constraints including
> bandwidth and latency, etc. as described in section 6.12.3.2 of RFC8299.
> >                 |
> /valid-provider-identifiers/qos-profile-identifier
> >                 |                                  /id
> > Also, in L3SM, qos-profile can be locally defined under
> site-network-access and also mapped to classification rules defined there
> as described in 6.12.3.2/6.12.3.1. Then, te-service-mapping-yang should
> also map a VNAP to the local qos-profile even without vpn-service level
> mapping like this:
> >
> > Although we may consider the same requirement to L2SM mapping, from our
> service objectives, the current definition is enough for now.
> >
> > How do you think?
> >
> > Thanks in advance,
> > Kenichi
> >
> > --
> > Kenichi Ogaki

---

From: "Ogaki, Kenichi" <[email-masked]>
Date: Thu, 6 Aug 2020 09:27:17 +0900

Hi Young,

Thanks for your comment.

>Kenichi, is that what you are trying to say? Please correct me if my understaning is incorrect.  

Yes! That’s our intention.

Thanks,
Kenichi

-----Original Message-----
From: Teas <[email-masked]> On Behalf Of Young Lee
Sent: Wednesday, August 5, 2020 7:06 PM
To: Ogaki, Kenichi <[email-masked]>
Cc: Dhruv Dhody <[email-masked]>; 丹羽 朝信 <[email-masked]>; 宮坂 拓也 <[email-masked]>; TEAS WG <[email-masked]>; [email-masked]
Subject: Re: [Teas] consideration of 1 VPN to N VNs mapping

Hi Kenichi and Dhruv,

I think we can relax the mapping between VPN: VN to 1:N as Kenichi was asking this question. I carefully read RFC 8299 and captured the following:
in section 6.12.3.2 where QoS profile is defined:

>From the highighted text, VPN may have different QoS profile within VPN identifier. Although it is primarily meant for CE-PE level commitment, depending on the operator's need, it can be extended site to site (source to
destination) per the colored text.. This implies a set of different TE-tunnels that meet the corresponding QoS profile can be supported. In that sense, I think 1:N mapping between a VPN instance to a VN instance is possible. 

Kenichi, is that what you are trying to say? Please correct me if my understaning is incorrect.  

Thanks.
Young

2020년 8월 5일 (수) 오전 10:08, Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> >님이 작성:

	Hi Dhruv,

	

	
	Thanks,
	Kenichi
	
	-----Original Message-----
	From: Teas <[email-masked] <mailto:[email-masked]> > On Behalf Of Dhruv Dhody
	Sent: Tuesday, August 4, 2020 7:54 PM
	To: Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> >
	Cc: 宮坂 拓也 <[email-masked] <mailto:[email-masked]> >; 丹羽 朝信 <[email-masked] <mailto:to-niwa@kddi..com> >; [email-masked] <mailto:[email-masked]> ; TEAS WG ([email-masked] <mailto:[email-masked]> ) <[email-masked] <mailto:[email-masked]> >
	Subject: Re: [Teas] consideration of 1 VPN to N VNs mapping
	
	Hi Kenichi,

	Even in the example

	
	Thanks!
	Dhruv
	
	On Tue, Aug 4, 2020 at 3:29 PM Ogaki, Kenichi <[email-masked] <mailto:[email-masked]> > wrote:
	> Also, in L3SM, qos-profile can be locally defined under site-network-access and also mapped to classification rules defined there as described in 6.12.3.2/6.12.3.1 <http://6.12.3.2/6.12.3.1> . Then, te-service-mapping-yang should also map a VNAP to the local qos-profile even without vpn-service level mapping like this:
	>
	> +81-(0)80-5945-9138 | www.kddi.com <http://www.kddi.com> 
	>
	>
	>
	
	_______________________________________________
	Teas mailing list
	[email-masked] <mailto:[email-masked]> 
	https://www.ietf.org/mailman/listinfo/teas