Hi, Roque:
Should rd-pool-name be defined in L3SM, how does upper layer OSS the RD pool
list and related names?
If rd-pool-name is introduced only for troubleshooting, should a separate NBI
interface should be defined to expose RD pool resource to the upper layer OSS
and maintain the binding between RD and RD pool?
Please give your troubleshooting usage example to explain how the anomaly in
the network change can be located and repaired.
Also in your proposed, I think RD should be defined as
rt-types:route-distinguisher instead of empty type.
-Qin
发件人: OPSAWG [mailto:opsawg-boun...@ietf.org] 代表 Roque Gagliano (rogaglia)
发送时间: 2020年5月26日 17:39
收件人: Oscar González de Dios ; opsawg
主题: Re: [OPSAWG] Minutes of L3NM/L2NM module discussions
Hi Oscar,
Thursday was a national holiday and I was not able to participate.
I believe I did say in my previous email that there are not syntax issues with
using the union of an empty leaf. I implemented two logics for dynamic rd, one
using the current draft construct and one using a different construct with a
presence container (to avoid an extra leaf). The reason for a container is that
I believe we are also missing to say something about the pool from where the RD
should be chosen as there could be more than one pool in a network. So, we will
need additional leafs anyhow:
leaf rd {
type empty;
}
container dynamic-assign-rd {
presence "Aut-assign-rd";
when "not(../rd)";
leaf rd-pool-name {
type string;
}
}
Now, let’s put owerselves on the shoes of a person troubleshooting some
provisioning problems of validating a posible network change, Which of these
two payloads are clearer to know that a dynamic RD should be used?
1) Implicit using current draft:
{
"data": {
"ietf-l3vpn-ntw:l3vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "650087400",
"ie-profiles": {
"ie-profile": [
{
"ie-profile-id": "ie_00”
}
]
}
}
]
}
}
}
}
2) Using Explicit mentioned with a presence container and specifying the
name of the pool:
{
"data": {
"ietf-l3vpn-ntw:l3vpn-ntw": {
"vpn-services": {
"vpn-service": [
{
"vpn-id": "650087400",
"ie-profiles": {
"ie-profile": [
{
"ie-profile-id": "ie_00",
"dynamic-assign-rd": {
"rd-pool-name": "metro1_rd_pool"
}
}
]
}
}
]
}
}
}
}
Regards,
Roque
From: OPSAWG mailto:opsawg-boun...@ietf.org>> on
behalf of Oscar González de Dios
mailto:oscar.gonzalezded...@telefonica.com>>
Date: Thursday, 21 May 2020 at 16:27
To: opsawg mailto:opsawg@ietf.org>>
Subject: [OPSAWG] Minutes of L3NM/L2NM module discussions
Dear OPSAWG colleagues,
Thanks for participating in the call today. Please find bellow
the minutes:
L3NM and L2NM module discussions
* Date: 21-May-2020
Participants
- Oscar Gonzalez de Dios (Telefonica)
- Samier Barguil (Telefonica)
- Anton Snizar (Sedona)
- Daniel King (Old Dog Consulting)
- Adrian Farrel (Old Dog Consulting)
- Qin Wu (Huawei)
- Sergio Belotti ()
- Sriram Krishnamurthy (Nokia)
- Italo Busi (Huawei)
1. Agenda:
- Revision of the L3NM Github issues
(https://github.com/IETF-OPSAWG-WG/l3nm/issues)
2. L3NM
Revision of the three main issues:
Implementation Report by Cisco. It has two main issues
(https://github.com/IETF-OPSAWG-WG/l3nm/issues/110)
- Common module to have all the L3NM specific requirements. Type-like module.
[Anton]: It makes implementation simpler. Does not generate unnecessary
dependencies
[Adrian]: It depends on if we need module for specific types, to avoid
unnecessary imports. Also don't you only need to import types, not the entire
module?
[Qin]: With L3SM we did not take an augmentation approach. If there are common
types defined in both models, then we may need to find the common components.
We should decouple of L3SM.
[Sriram]: Prefer to have a separate type-file for the specific parameters.
[Oscar]: Define a common type-file for the service models.
[Qin]: Is it possible to manage it as an independent draft?
[Oscar in github issues]: After the discussions, it seems reasonable to have a
separate Yang module to contain the types. The suggestion is to write the
module to cover the four service models (client service models, l3sm, l2sm and
Network service models, l2nm, l3nm). It seems reasonable to include this module
in l3nm draft instead of creating a new one to avoid dependencies.
Samier, Dan and Anton to collaborate for a first version of the split
- RD Auto-assigment implementation issue
(https://github.com/IETF-OPSAWG-WG/l3nm/issues/114)
