Subject: [Rtg-yang-coord] yang models intended for the mpls wg

From: Loa Andersson <[email-masked]>
Date: Fri, 24 Jul 2015 11:39:41 +0200

Folks,

There are four yang models intended for the MPLS working group, we have
not yet started the process of adoption as working group documents.
The four documents are:

1. draft-zhang-mpls-tp-yang-oam (announced earlier)
2. draft-zheng-mpls-lsp-ping-yang-cfg (announced now)
3. draft-openconfig-mpls-consolidated-model (announced now)
4. draft-raza-mpls-ldp-mldp-yang (announced now)

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 24 Jul 2015 15:24:17 +0200

[with yang doctor hat on]

Loa,

Has there been any discussion around how these models interact with each other or how the mpls WG would like to see the models structured.

For example, from this list of models (and I admit I have not looked at a complete list of mpls related yang models or each in detail), a couple of questions arise. 

- Is there a plan for a generic mpls yang model?
- plan for a more specific mpls-tp, mpls-te etc. yang model (they could be an extension of the more generic mpls model)?
- plan for a generic ping module (may belong in NETMOD WG)?
- plan for a mpls ping module (again an extension of the more generic ping module that interfaces with mpls module)?
- plan for a ldp module that interfaces with the mpls module?
- plan for a rsvp-te module that interfaces with mpls-te module?

Having some structure to the models would probably help these and other yang authors in their design.

Thanks.

Mahesh Jethanandani
[email-masked]

> On Jul 24, 2015, at 11:39 AM, Loa Andersson <[email-masked]> wrote:
> 
> Folks,
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Tom Taylor <[email-masked]>
Date: Sat, 25 Jul 2015 08:18:59 -0400

The generic ping module is a LIME work item.

Tom Taylor

---

From: Loa Andersson <[email-masked]>
Date: Sun, 26 Jul 2015 11:21:03 +0200

Tom, et.al.,

Sure generic "ping" are for LIME, but "ping" and "LSP Ping" are not
the same.

/Loa

On 2015-07-25 14:18, Tom Taylor wrote:
>> Has there been any discussion around how these models interact with
>> each other or how the mpls WG would like to see the models structured.
>>
>> For example, from this list of models (and I admit I have not looked
>> at a complete list of mpls related yang models or each in detail), a
>> couple of questions arise.
>>
>> - plan for a more specific mpls-tp, mpls-te etc. yang model (they
>> could be an extension of the more generic mpls model)?
>> - plan for a mpls ping module (again an extension of the more generic
>> ping module that interfaces with mpls module)?

---

From: Lou Berger <[email-masked]>
Date: Sun, 26 Jul 2015 05:53:58 -0400

Mahesh ,
    Some of what you are asking about is happening over in teas and was
discussed in Prague:
          > 3         13:20         20         Title:         YANG Data
Model for
           TE Topologies
          >                        Draft:
           http://tools.ietf.org/html/draft-ietf-teas-yang-te-topo
          >                        Presenter:         Xufeng Liu / Igor
Bryskin
         
           Presentation:
           https://www.ietf.org/proceedings/93/slides/slides-93-teas-3.pdf

          > 4         13:40         25         Title:         RSVP/TE
Yang Models
          >                        Draft:
           http://tools.ietf.org/html/draft-saad-teas-yang-te
           http://tools.ietf.org/html/draft-saad-teas-yang-rsvp
          >                        Presenter:         Tarek Saad
          >       Slides:
           https://www.ietf.org/proceedings/93/slides/slides-93-teas-4.pdf

Also the following is likely to end up being both discussed in MPLS and
TEAS as it includes TE and non-TE related information:
         
          > 5         14:05         10         Title:         MPLS / TE
Model for
           Service Provider Networks
          >                        Draft:
          
https://tools.ietf.org/html/draft-openconfig-mpls-consolidated-model-01
          >                        Presenter:         Ina Minei
          >       Slides:
           https://www.ietf.org/proceedings/93/slides/slides-93-teas-5.pdf
         
Lou

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 26 Jul 2015 07:31:45 -0700

Lou,

I like the approach taken in the draft draft-openconfig-mpls-consolidated-model. In particular, the approach represented in this tree model makes sense to me.

   +--rw mpls!
         +--rw global
         |     ...
         +--rw te-global-attributes
         |     ...
         +--rw signaling-protocols
         |     ...
         +--rw lsps
               ...

However, by its own admission, the draft says:

This model does not aim to be feature complete (i.e., cover all
   possible aspects or features of MPLS). 

My suggestion would be for the MPLS WG to take up the model structure as represented above and to do a more complete work of including all features of MPLS, e.g. GMPLS. 

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 26 Jul 2015 18:48:10 +0000

Hi Mahesh,

Please comment on https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ as this is the latest view of the design team.

Thanks,
Acee

From: Rtg-yang-coord <[email-masked]<mailto:[email-masked]>> on behalf of Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Sunday, July 26, 2015 at 4:31 PM
To: Lou Berger <[email-masked]<mailto:[email-masked]>>
Cc: Routing YANG <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg

Lou,

   +--rw mpls!
         +--rw global
         |     ...

Thanks.

Mahesh Jethanandani
[email-masked]<mailto:[email-masked]>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Jul 2015 21:24:06 +0200

Dear Acee,

please note that the interfaces model plus the IP model plus the core
system model plus the SNMP configuration model the IETF agreed on are
defined in RFC 7223, RFC 7277, RFC 7317, and RFC 7407. All these RFCs
were produced by the NETMOD working group.  Work is starting in other
SDOs to extend these models. Hence, I think any attempts to replace
them with something different should not only be discussed on the
NETMOD list but also seek support from the NETMOD working group.

Note that https://www.ietf.org/mailman/listinfo/rtg-yang-coord says:

    The rtg-yang-coord mailing list will provide a forum for
    coordination of the development of YANG models being worked on for
    Routing, in order to provide a consistent view to the NMS.

It seems some of the content of draft-rtgyangdt-rtgwg-device-model-00
seems to leave the routing scope.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 27 Jul 2015 05:36:09 +0000

Hi Tom,
what is relationship between MPLS LSP Ping and "generic ping" models? Or, between BFD and "generic continuity check"?

	Regards,
		Greg

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Saturday, July 25, 2015 5:19 AM
To: Mahesh Jethanandani; Loa Andersson
Cc: [email-masked]; YANG Doctors
Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg

Tom Taylor

On 24/07/2015 9:24 AM, Mahesh Jethanandani wrote:
>> There are four yang models intended for the MPLS working group, we 
>> have not yet started the process of adoption as working group documents.
>> The four documents are:
>>
>> 1. draft-zhang-mpls-tp-yang-oam (announced earlier) 2. 
>> draft-zheng-mpls-lsp-ping-yang-cfg (announced now) 3. 
>> draft-openconfig-mpls-consolidated-model (announced now) 4. 
>> draft-raza-mpls-ldp-mldp-yang (announced now)
>>
>> /Loa
>>
>>
>>
>>
>> --
>>
>>

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jul 2015 11:06:01 -0400

LSP ping really corresponds to the generic tracert model, in that it 
provides hop-by-hop path characterization. I can see the LIME tracert 
RPC being invoked, and the MPLS nodes returning the parameters defined 
for that RPC to the extent that they correspond to what LSP ping reports.

BFD seems to correspond quite nicely to LIME ping in terms of the 
function performed.

Tom

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 27 Jul 2015 15:18:19 +0000

Hi Tom,
I think I cannot agree with any of your comparisons.
LSP Ping provides both on-demand ping and traceroute functions.
BFD, if you refer to RFC 5880, provides variety of functions, primarily as proactive continuity check (Asynchronous and on-demand modes, as well as ping by Echo mode). RFC 5884 BFD over MPLS LSP consider only Asynchronous mode.
One can argue that ping may be used as proactive continuity check mechanism but that is not what it was originally designed and such application would, most likely, require use of another application, e.g. Measurement Agent per LMAP Reference model.

I think it would be really helpful to define relationships between objects of LIME model and models specified in MPLS, BFD and other groups that had developed OAM tools that broadly used in the industry.

	Regards,
		Greg

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Monday, July 27, 2015 8:06 AM
To: Gregory Mirsky; Mahesh Jethanandani; Loa Andersson
Cc: [email-masked]; YANG Doctors
Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg

LSP ping really corresponds to the generic tracert model, in that it provides hop-by-hop path characterization. I can see the LIME tracert RPC being invoked, and the MPLS nodes returning the parameters defined for that RPC to the extent that they correspond to what LSP ping reports.

BFD seems to correspond quite nicely to LIME ping in terms of the function performed.

Tom

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jul 2015 11:34:15 -0400

I am not claiming that the capabilities of LSP ping are limited to those 
of tracert, or that the capabilities of BFD are limited to those of 
ping. I am saying that if I want to request these two functions 
(continuity check and hop-by-hop path characterization) at a generic 
level then the corresponding implementations at the MPLS 
technology-specific level would be invoked when the LIME RPCs were 
invoked at the boundaries of an MPLS segment.

The idea would be that once a fault was localized to that segment and to 
the MPLS layer as opposed to a supporting layer, the manager could 
invoke the technology-specific models as necessary to get details.

Tom

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 27 Jul 2015 15:51:12 +0000

Hi Tom,
I don't think that BFD is or will be used as on-demand OAM tool as it does not have localization capability. Ping or traceroute are more suitable, in my opinion. But if that is how LIME model maps existing OAM tools, then I'd encourage presenting and asking for review of the LIME model by WGs that designed this OAM mechanisms, e.g. MPLS Ping and BFD.

	Regards,
		Greg

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: Monday, July 27, 2015 8:34 AM
To: Gregory Mirsky; Mahesh Jethanandani; Loa Andersson
Cc: [email-masked]; YANG Doctors
Subject: Re: [Rtg-yang-coord] yang models intended for the mpls wg

I am not claiming that the capabilities of LSP ping are limited to those of tracert, or that the capabilities of BFD are limited to those of ping. I am saying that if I want to request these two functions (continuity check and hop-by-hop path characterization) at a generic level then the corresponding implementations at the MPLS technology-specific level would be invoked when the LIME RPCs were invoked at the boundaries of an MPLS segment.

The idea would be that once a fault was localized to that segment and to the MPLS layer as opposed to a supporting layer, the manager could invoke the technology-specific models as necessary to get details.

Tom

---

From: Tom Taylor <[email-masked]>
Date: Mon, 27 Jul 2015 12:34:30 -0400

I do not consider ping to have localization capability. That's why I 
consider BFD to be the functional equivalent.

Review is certainly something that LIME will welcome, I'm sure.

Tom