Subject: [Rtg-yang-coord] Address family management in YANG models

From: <[email-masked]>
Date: Tue, 16 Dec 2014 12:01:56 +0000

Hi,

I don't know if the topic has already been discussed or not.
In most of protocols we have to support multiple address families. In order to have more consistencies between data model, it would be good to agree on common way to reference address-families and not let everyone using strings, as strings will let open some doors to misalignment between vendors.

Current core routing model introduces the address-family identity which is good.
Could we agree on using identityref using this base for AF type ?

In case of yes, where should the AF be defined ? All in core routing model ? How to manage extensions ? Current model  proposes twos AFs ipv4 and ipv6 but may be a renaming is required to be more precise.

ipv4 -> ipv4-unicast
ipv6 -> ipv6-unicast

Thoughts ?

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert NoF
phone: +33 2 23 28 49 83 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: +33 6 37 86 97 52 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Dec 2014 14:04:45 +0100

Hi,

> On 16 Dec 2014, at 13:01, <[email-masked]> <[email-masked]> wrote:
> 
> Hi,
>  
> I don’t know if the topic has already been discussed or not.

Right, strings are a bad idea. The other two options are an enumeration and identities. The main difference is in extensibility: an enumeration can be extended only via publishing a new revision of the YANG module where it is defined. Identities, on the other hand, allow for distributed extensibility - new identities can be defined at any time by writing a new module (standard or proprietary).

Identities are also organized in a hierarchy so that, say, an identity of a modified OSPF can be derived from regular OSPF, i.e. reuse its data and add some extra if necessary.

> In case of yes, where should the AF be defined ? All in core routing model ?

I’d suggest to define each protocol’s identity in the module where its configuration and state data are defined. Appendix C in draft-ietf-netmod-routing-cfg-16 gives an example.

> How to manage extensions ?

As I said, it is easy and needn’t be tightly coordinated. Even if two parties happen to choose same names, they will be distinct due to namespaces.

> Current model  proposes twos AFs ipv4 and ipv6 but may be a renaming is required to be more precise.
>  
> ipv4 -> ipv4-unicast
> ipv6 -> ipv6-unicast

Of course, go ahead and propose a better hierarchy. When designing it, I guess it might be useful to know that YANG 1.1 will most likely support multiple inheritance of identities, see

https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-14

In our case it would be possible to treat address family and “cast” as two orthogonal facets: for instance, ipv4-unicast identity could inherit from ipv4 and unicast.

Lada 

> phone: +33 2 23 28 49 83 
> mobile: +33 6 37 86 97 52 
> [email-masked]
>  
>  
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: <[email-masked]>
Date: Tue, 16 Dec 2014 14:02:08 +0000

Hi Lada,

Thanks for adding your view on the topic.

I agree that using identity for AF sounds the more reasonable solution.

For the place of definition of the AF identity, we need to agree on what kind of protocols. I'm not sure that routing protocol models are a good place to define AFs. 
May be we can follow what you started today :
- IPv4 unicast defined in IPv4 unicast routing management (Before posting my previous mail, I missed that your defined ipv4-unicast in this module ...) -> already done
- IPv6 unicast defined in IPv6 unicast routing management -> already done
- IPv4 multicast in a future multicast IPv4 routing management module
- IPv6 multicast in a future multicast IPv6 routing management module
- vpn ipv4 and ipv6 in a L3VPN routing module
- ...

Regarding the hierarchy, I have no opinion today, if a hierarchy is required or not.

I'm wondering if a new appendix or section in your document (netmod-routing-cfg) would be necessary to describe such guideline for child modules.

Stephane

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Tuesday, December 16, 2014 14:05
To: LITKOWSKI Stephane SCE/IBNF
Cc: [email-masked]
Subject: Re: [Rtg-yang-coord] Address family management in YANG models

Hi,

Lada