[Teas] consideration of 1 VPN to N VNs mapping

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

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.
[phone] | www.kddi.com