Subject: [Teas] Fwd: [Rtg-yang-coord] Survey for YANG model design : routing protocols CLI implementation

From: Lou Berger <[email-masked]>
Date: Tue, 10 Feb 2015 07:43:03 -0500

Fyi - note request for unicast responses...

--- Forwarded message ---
From: <[email-masked]>
Date: February 10, 2015 7:27:07 AM
Subject: [Rtg-yang-coord] Survey for YANG model design : routing protocols 
CLI implementation
To: "[email-masked]" <[email-masked]>, "[email-masked] list 
([email-masked])" <[email-masked]>, "[email-masked]" <[email-masked]>, 
"[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
CC: "[email-masked]" <[email-masked]>

Hi Folks,

A lot of us are currently working on Yang model drafts. In the framework of 
routing protocols related drafts, we have some discussion regarding how to 
model the configuration of routing protocols and especially do it need to 
be routing-instance centric or protocol centric (see slides for quick 
explanation of the difference). This is a cross protocol discussion, as we 
would like to apply the same design to all.

In order to decide how to progress on this major design point, one point  
is to evaluate current implementations and how many are routing-instance 
centric and protocol centric. The famous implementations are well known, 
but we would like to have a more global view. This metric would be one 
among others.

In order to help us to do this inventory, could you please respond unicast 
to me, if you are an implementor and you have an implementation of a 
routing-protocol (ISIS,OSPF,RIP,BGP, PIM ... but also MPLS-TE, LDP, RSVP 
...) and in this case, what is your CLI flavor ?

Please use this sample format, so it would be easier for me to aggregate :
(If you own multiple implementations, you can fill multiple lines.)

Vendor

OS

Protocol Centric

VRF centric

Cisco

IOS/IOS-XE

X

Thanks for your help !

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

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
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.

----------
_______________________________________________
Rtg-yang-coord mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Lou Berger <[email-masked]>
Date: Wed, 11 Feb 2015 09:19:42 -0500

FYI

-------- Forwarded Message --------

Subject:

RE: [mpls] Survey for YANG model design : routing
protocols CLI implementation

Date:

Wed, 11 Feb 2015 08:43:00 +0000

From:

[email-masked]

To:

[email-masked] list ([email-masked])
<[email-masked]>, [email-masked]
<[email-masked]>, [email-masked]
<[email-masked]>

From:
mpls [mailto:[email-masked]]
On Behalf Of [email-masked]

Sent: Tuesday, February 10, 2015 13:26

To: [email-masked];
[email-masked] list ([email-masked]);
[email-masked];
[email-masked];
[email-masked]

Cc: [email-masked]

Subject: [mpls] Survey for YANG model design :
routing protocols CLI implementation

Importance: High

Hi Folks,

A lot of us are currently working on Yang
model drafts. In the framework of routing protocols related
drafts, we have some discussion regarding how to model the
configuration of routing protocols and

especially do it need to be
routing-instance centric or protocol centric.
This is a cross protocol discussion, as we would like
to apply the same design to all.

Example of
routing-instance centric CLI : (Typically Juniper, ALU)

routing-instance
R1 {

protocol isis {};

protocol ospf {};

protocol ldp {};

}

routing-instance
R2 {

protocol isis {};

protocol ospf {};

protocol ldp {};

}

Example of
protocol centric CLI : (Typically CISCO)

protocol isis {

routing-instance R1 {}

routing-instance R2 {}

}

protocol ospf {

routing-instance R1 {}

routing-instance R2 {}

}

In order to decide how to progress on this
major design point, one point  is to evaluate current
implementations and how many are routing-instance centric and
protocol centric. The famous implementations are well known,
but we would like to have a more global view. This metric
would be one among others.

In order to help us to do this inventory,
could you please respond unicast to me, if you are an
implementor and you have an implementation of a
routing-protocol (ISIS,OSPF,RIP,BGP, PIM … but also MPLS-TE,
LDP, RSVP …) and in this case, what is your CLI flavor ?

Please use this sample format, so it would
be easier for me to aggregate :

(If you own multiple implementations, you
can fill multiple lines.)

Vendor

OS

Protocol
Centric

VRF
centric

Cisco

IOS/IOS-XE

X

Thanks for your help !

Stephane
Litkowski

Network
Architect

phone:
+33 2 23 28 49
83

mobile:
+33 6 37 86 97
52

[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;

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.

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.