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

["Ogaki, Kenichi" <[e-mail]>]

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 <[e-mail]> On Behalf Of Young Lee
Sent: Wednesday, August 5, 2020 7:06 PM
To: Ogaki, Kenichi <[e-mail]>
Cc: Dhruv Dhody <[e-mail]>; 丹羽 朝信 <[e-mail]>; 宮坂 拓也 <[e-mail]>; TEAS WG <[e-mail]>; [e-mail]
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:

  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 <[e-mail] <mailto:[e-mail]> >님이 작성:


	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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Dhruv Dhody
	Sent: Tuesday, August 4, 2020 7:54 PM
	To: Ogaki, Kenichi <[e-mail] <mailto:[e-mail]> >
	Cc: 宮坂 拓也 <[e-mail] <mailto:[e-mail]> >; 丹羽 朝信 <[e-mail] <mailto:to-niwa@kddi..com> >; [e-mail] <mailto:[e-mail]> ; TEAS WG ([e-mail] <mailto:[e-mail]> ) <[e-mail] <mailto:[e-mail]> >
	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
	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
	
	On Tue, Aug 4, 2020 at 3:29 PM Ogaki, Kenichi <[e-mail] <mailto:[e-mail]> > wrote:
	>
	> 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 <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:
	>
	>      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.
	> [phone] | www.kddi.com <http://www.kddi.com> 
	>
	>
	>
	
	_______________________________________________
	Teas mailing list
	[e-mail] <mailto:[e-mail]> 
	https://www.ietf.org/mailman/listinfo/teas