Re: [L3sm] https://tools.ietf.org/html/rfc8299 issue

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

Hi Erez,

See comments inline, please.

All the best,
Kenichi

-----Original Message-----
From: Erez Segev [mailto:[e-mail]] 
Sent: Thursday, September 20, 2018 7:30 PM
To: Ogaki, Kenichi
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Kenichi,

I have two further questions regarding the IM:

1) how would you apply a metric to static route (assuming there are several site-network -access which act as next-hop of the same prefix)  ?

[KO] See section 6.7. Site Network Access Availability, you can differentiate the priority of multiple site network accesses to the same prefix by site-network-accesses/site-network-access/availability/access-priority outside the routing protocol.

2) How would you apply a VLAN attribute is the access to CE is via VLAN, I believe it is by using bearer but where does this bearer defined?

[KO] The current data model doesn't define any specific layer 2 protocol information. You may be able to augment bearer, site-network-accesses/site-network-access/bearer to request a specific VLAN.

Thanks,
Erez,



-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Friday, August 17, 2018 2:56 AM
To: Erez Segev <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Erez,

Please see comments[KO] inline.

All the best,
Kenichi

-----Original Message-----
From: Erez Segev [mailto:[e-mail]]
Sent: Thursday, August 16, 2018 7:30 PM
To: Ogaki, Kenichi
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi , 

We are using the role to calculate Max Routes and RTs of VRF by considering other sites. When several site-network-access's of the same site attached to the same VPN using different role, it confusing the calculation , since we don’t know if the VRF is eventually hub or spoke.

[KO] Whatever you use the model object for other purposes is out of scope for this model.
Anyway, a hub spoke model differentiates the RTs between hub site and spoke sites, and the hub site's VRF exports the hub RT and imports the spoke RT, and the spoke site's reverses them. Then, the service provider must know each VRF belongs to hub or spoke site in order to configure the PE.

I have another question regarding the direct connected routes (6.11.2. and 6.11.3); in the 'routing-protocols' container it doesn’t exist so I wonder if the provider-address + prefix is treated as direct connected lan?

[KO] Yes. You are right.

Thanks,
Erez


-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Thursday, August 16, 2018 3:16 AM
To: Erez Segev <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Erez,

Please see comments[KO] inline.

All the best,
Kenichi

-----Original Message-----
From: Erez Segev [mailto:[e-mail]]
Sent: Monday, August 13, 2018 7:04 PM
To: Ogaki, Kenichi
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Kenichi,

One minor issue that need to be fixed in 8299 is the description of site-role(section 6.4) which is under site-network-access container. The description should indicate that the site-role value must be the same for all site-network-access objects referencing to the same VPN. In another words the site cannot play more than single role in the same VPN.

[KO] I'm sorry. I can't understand what you intend. A vpn with hub-and-spoke service topology requires, basically, one site-network-access with hub-role and the other site-network-accesses with spoke-role.

Regards,
Erez


-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Tuesday, August 07, 2018 3:10 AM
To: Erez Segev <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Erez,

Please see comments[KO4] inline.

All the best,
Kenichi

-----Original Message-----
From: Erez Segev [mailto:[e-mail]]
Sent: Monday, August 06, 2018 7:04 PM
To: Ogaki, Kenichi
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Kenichi,

Thanks for your reply. 

I was on vacation in the last month and like to re-open  the discussion.

I'm trying the understand the RFC8299 point of view, Why can't a user define several IPv6 subnets to be connected to the same site-network-access, in single VPN mode?

[KO4] This is the definition of site-network-access in this model. Section 6.3 says "a site-network-access represents an IP logical connection of a site."
As I wrote before, if you want to connect multiple subnets to a single VPN, this model enables it by MultiVPN defined in section 6.5.


It is not commercial L3VPN Service, buy it L3VPN imitates a router , 

[KO4] I'm sorry. I can't understand what you are saying.


This routing capability will be missing.

[KO4] You might have wanted to say this model doesn't support a certain capability of a router, but this is not "Network Element YANG Modules" or device model, but "Network Service YANG Modules" in the sense of RFC8199.
It's not necessary that this model defines all the capability of a router. But, a service model only defines what the service really requires.


Thanks,
Erez







-----Original Message-----
From: Ogaki, Kenichi [mailto:[e-mail]]
Sent: Monday, July 09, 2018 4:08 AM
To: Erez Segev <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Erez,

Please see comments[KO3] inline.

All the best,
Kenichi

-----Original Message-----
From: Erez Segev [mailto:[e-mail]]
Sent: Sunday, July 08, 2018 2:30 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Kenichi,

I believe the example I put is not the best one but if we look in Juniper or CISCO routers, which are the most common in the industry, there is an ability to define several IP Addresses on the same interface as primary and secondary addresses (usually the primary is used for routing protocols). 

[KO3] You mentioned "1. Customer need to connect several CE (up to 4) devices with IPv6 access, each has its own IPv6 address/prefix length, and prefix length is the same for all of them (it usually is /64)" earlier.
In that case, your customer agrees that other than one CE cannot use a routing protocol? Is that a commercial L3VPN service?


So even for CE point of view, if the CE just route between two networks attached to the same interface, the model doesn't give a solution to overload the interface with several IPs.

[KO3] In this case, RFC8299 supposes MultiVPN model defined in 6.5.1.2. Multiple IP subnets isn't necessary for this purpose.


Regards,
Erez


 




-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, July 05, 2018 2:55 PM
To: Erez Segev <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: RE: https://tools.ietf.org/html/rfc8299 issue

Hi Erez,

 Please see comments [KO2] inline.

All the best,
Kenichi

On Jul 5, 2018 4:14 PM, "Erez Segev" 
<[e-mail]> wrote:
 
 
>Hi Kenichi,
>
>
>
>I'm not sure that the sub-VPN matches my case since the need is for single VPN.
>
[KO2] That is a subset of subVPN model that multiple site-network-accesses connected to a single VPN. 

>
>
>I my case both subnets are carried under the same VLAN the PE interface 
>(and I don’t have any information about the CEs)
>
[KO2] As an L3VPN provider, your usecase is irregular for us and we don't do this. A single broadcast domain (vlan) must be basically used for a single IP subnet. Then, we differentiate vlan per IP subnet.
A single broadcast domain with multiple subnets may cause some issues. Can PE appropriately answer ARP with a single mac address for multiple IP addresses (I know it probably works)? The most major vendor's PE cannot talk at least a routing protocol from the secondary IP address.
When we don't know our customer site's environment, we eliminate any  possibility which may cause any issue.

If you still want to use the case, RFC8299 supposes subVPN model for the case.

>
>
>
>
>[cid:image002.png@01D41448.4C19B120]
>
>
>
>
>
>Regards,
>
>Erez
>
>
>
>
>
>-----Original Message-----
>From: Ogaki, Kenichi [mailto:[e-mail]]
>Sent: Thursday, July 05, 2018 9:41 AM
>To: Erez Segev <[e-mail]>; [e-mail]; 
>[e-mail]; [e-mail]
>Subject: RE: https://tools.ietf.org/html/rfc8299 issue
>
>
>
>Hi Erez,
>
>
>
>Please see comments[KO] inline.
>
>
>
>All the best,
>
>Kenichi
>
>
>
>-----Original Message-----
>
>From: Erez Segev [mailto:[e-mail]]
>
>Sent: Thursday, July 05, 2018 12:01 AM
>
>To: Ogaki, Kenichi; [e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>
>
>Subject: RE: https://tools.ietf.org/html/rfc8299 issue
>
>
>
>Hi Kenichi,
>
>
>
>We are using the model in a way that the user has only knowledge about 
>the PEs while the CEs are not managed by the user;
>
>
>
>[KO] In RFC8299, if a CE is managed by a provider, that is provider-managed model and ip-connection refers to CE-to-LAN connection defined in 6.3.2.2. However the following usecase seems about a PE-CE-connection.
>
>
>
>so the devices list of the Site are PE devices only and the site-network-access is a port on the PE, is it problematic from RFC8299 point of view? This is the provider point of view.
>
>
>
>Anyway the use case in which it is relevant to set several IP address is as follows:
>
>
>
>1.            Customer need to connect several CE (up to 4) devices 
>with IPv6 access, each has its own IPv6 address/prefix length, and 
>prefix length is the same for all of them (it usually is /64)
>
>2.            Bearer parameters of these CEs in site are such that are 
>connected using a single VLAN on a single VLAN-tagged port in a single 
>PE in you're the provider network (The customer probably not  aware of
>that)
>
>
>
>[KO] Even if customer-managed or co-managed ce case, does this mean that a single physical PE port has multiple VLAN-tagged ports(sub-interface) and each VLAN-tagged port belongs to an IPv6 subnet to a CE?
>
>If correct, RFC8299 models this as a subVPN defined in 6.5.1.3. Multiple site-network-accesses use the same bearer.
>
>
>
>
>
>3.            There are no diversity requirements for the access of 
>these site
>
>So, If the IP connection would be list based , I could have support this use case.
>
>
>
>Thanks,
>
>Erez
>
>
>
>
>
>
>
>
>
>-----Original Message-----
>
>From: Ogaki, Kenichi [mailto:[e-mail]]
>
>Sent: Wednesday, July 04, 2018 9:24 AM
>
>To: Erez Segev <[e-mail]<mailto:[e-mail]>>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>
>
>Subject: RE: https://tools.ietf.org/html/rfc8299 issue
>
>
>
>Hi Erez,
>
>
>
>>In my case the OSS has visibility of my PE devices so the site devices are PEs.
>
>>Site network access is translated to interface on the PE it reference to, and I like to define multiple IPv6 addresses on this interface.
>
>
>
>We want to know why you have to assign multiple IPv6 addresses on a PE interface. What's your objective, service and usecase?
>
>Could you show us the example configuration what you want to do?
>
>
>
>>I wouldn't want to duplicated the whole site-network -access structure for adding static IP configuration.
>
>
>
>It depends on your usecase, whether this model covers it or not.
>
>We necessarily defined this model to differentiate IP addresses with different site-network-accesses from the L3VPN operator's viewpoint.
>
>
>
>All the best,
>
>Kenichi
>
>
>
>-----Original Message-----
>
>From: Erez Segev [mailto:[e-mail]]
>
>Sent: Tuesday, July 03, 2018 5:31 PM
>
>To: Ogaki, Kenichi; [e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>
>
>Subject: RE: https://tools.ietf.org/html/rfc8299 issue
>
>
>
>Hi Kenichi,
>
>
>
>In my case the OSS has visibility of my PE devices so the site devices are PEs.
>
>Site network access is translated to interface on the PE it reference to, and I like to define multiple IPv6 addresses on this interface.
>
>
>
>I wouldn't want to duplicated the whole site-network -access structure for adding static IP configuration.
>
>
>
>
>
>Thanks,
>
>Erez
>
>
>
>
>
>
>
>-----Original Message-----
>
>From: Ogaki, Kenichi [mailto:[e-mail]]
>
>Sent: Tuesday, July 03, 2018 6:11 AM
>
>To: Erez Segev <[e-mail]<mailto:[e-mail]>>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>
>
>Subject: RE: https://tools.ietf.org/html/rfc8299 issue
>
>
>
>Hi Erez,
>
>
>
>>I am trying to configure a device and like to define several IP address to the edge port. However the model allows me to define a single one only, although the description of provider address talks about address  List.
>
>
>
>What's your concrete usecase to define multiple IP addresses to an edge port? Which edge port, PE or CE?
>
>The RFC can allow to assign multiple IP addresses on the same physical edge port with multiple site network accesses defined in Section 6.3.2.
>
>
>
>Thanks,
>
>Kenichi
>
>
>
>-----Original Message-----
>
>From: Erez Segev [mailto:[e-mail]]
>
>Sent: Monday, July 02, 2018 9:07 PM
>
>To: [e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>;
>[e-mail]<mailto:[e-mail]>
>
>Subject: https://tools.ietf.org/html/rfc8299 issue
>
>
>
>Hi,
>
>
>
>
>
>My name is Erez and I am a system engineer at ECI Telecom.
>
>
>
>
>
>I'm trying to adopt the rfc8299 IM (which you are mentioned as contributors to it)   for creation of L3VPN service and I think there is something missing or unclear (to me).
>
>
>
>
>
>I am trying to configure a device and like to define several IP address to the edge port. However the model allows me to define a single one only, although the description of provider address talks about address  List.
>
>
>
>In  rfc7277 which defines IP data model , IP addresses is a List.
>
>
>
>
>
>
>
>The same problem exist in IPv6.
>
>
>
>
>
>Thanks,
>
>
>
>Erez
>
>
>
>
>
>
>
>
>
>
>
>
>
>  container addresses {
>
>    when "derived-from-or-self(../address-allocation-type, "+
>
>    "'l3vpn-svc:static-address')" {
>
>    description
>
>    "Only applies when protocol allocation type is static.";
>
>     }
>
>      leaf provider-address {
>
>       type inet:ipv4-address;
>
>          description
>
>          "IPv4 Address List of the provider side.
>
>          When the protocol allocation type is static,
>
>          the provider address must be configured.";
>
>      }
>
>      leaf customer-address {
>
>       type inet:ipv4-address;
>
>          description
>
>          "IPv4 Address of customer side.";
>
>      }
>
>      leaf prefix-length {
>
>       type uint8 {
>
>        range "0..32";
>
>       }
>
>
>
>
>
>
>
>
>
>
>
>Erez Segev
>
>
>
>NFV&SDN System Engineer
>
>
>
>
>
>T:
>
>
>
>+972.3.9287393
>
>
>
>M:
>
>
>
>+972.50.7057393
>
>
>
>E:
>
>
>
>[e-mail]<mailto:[e-mail]>
><mailto:[e-mail]>
>
>
>
>
>
>www.ecitele.com<http://www.ecitele.com> <http://www.ecitele.com/>
>
>
>
>cid:image001.png@01D0A206.A2B15AE0
>
>
>
>
>
>
>
>
>
>_______________________________________________________________________
>____
>
>
>
>This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>
>_______________________________________________________________________
>____
>
>
>
>
>
>
>
>_______________________________________________________________________
>____
>
>
>
>This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>
>_______________________________________________________________________
>____
>
>
>
>
>
>
>
>_______________________________________________________________________
>____
>
>
>
>This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
>
>_______________________________________________________________________
>____
>
>
>
>
>
>_______________________________________________________________________
>____
>
>This e-mail message is intended for the recipient only and contains 
>information which is CONFIDENTIAL and which may be proprietary to ECI 
>Telecom. If you have received this transmission in error, please inform 
>us by e-mail, phone or fax, and then delete the original and all copies thereof.
>_______________________________________________________________________
>____
>


 
 
--
Kenichi Ogaki
KDDI Corp. | Next Gen NW Dev. Dept.
[phone] | www.kddi.com
 

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
___________________________________________________________________________



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
___________________________________________________________________________



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
___________________________________________________________________________



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
___________________________________________________________________________



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.
___________________________________________________________________________