Subject: [Rtg-yang-coord] Routing YANG Design Team Scope

From: "Acee Lindem (acee)" <[email-masked]>
Date: Sun, 26 Jul 2015 19:50:40 +0000

Juergen, 

Since this E-mail thread is about the hierarchy and granularity of MPLS
models, I’m somewhat confused by your response. Nevertheless, I’ve updated
the subject line to correspond to your concern.

Our assumption is that the Routing YANG design team will attempt to use
the existing models but will not be constrained by them. However, I agree
that any changes or augmentations to the existing NETMOD RFCs would need
to be reviewed in the NETMOD WG.

Thanks,
Acee 

On 7/26/15, 3:24 PM, "Juergen Schoenwaelder"
<[email-masked]> wrote:

>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
>
>On Sun, Jul 26, 2015 at 06:48:10PM +0000, Acee Lindem (acee) wrote:
>> 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,
>> 
>> 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]<mailto:[email-masked]>
>> 
>> 
>> 
>> 
>> 
>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>-- 
>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: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 26 Jul 2015 22:49:27 +0200

Acee,

you pointed to a document that seems to go out of the scope of this
routing yang design team and since this document is called
draft-rtgyangdt-rtgwg-* so I felt it is necessary to react.

/js

---

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

Acee,

Juergen’s concerns aside, I am curious about the intent of the design. I see the device model as a abstract model that allows for plenty of extensions. Since the discussion started with MPLS, I am going to focus on that part for now. 

BTW, the TOC in the html version of the draft have no hyper links.

I see that the mpls model in the draft to be very similar to the one in the OC MPLS draft. Is the idea that the device model is trying to define everything under a device tree? I would have thought that the device model would define networking-instance as a 'type identityref’ which would form a base identity, and from which specific networking-instance types would be derived, such as mpls - much like what the interfaces model does for all types of interfaces. That will allow the device model to be a fairly compact model, leaving the feature specific models to be developed elsewhere.

Thanks.

> On Jul 26, 2015, at 1:49 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Acee,
> 

Mahesh Jethanandani
[email-masked]

---

From: Rob Shakir <[email-masked]>
Date: Mon, 27 Jul 2015 11:38:57 +0100

My assumption, and understanding of the ask that the ADs put to the DT, is that the routing design team should consider usability of YANG models from a routing perspective, and not constrain itself on essentially arbitrary IETF-boundaries.

If the output of the DT means that we need cross-area review to further its work as any form of standard, or document that the IETF would choose to commit to RFC - then engagement with the relevant area should be sought, of course.

I am very much opposed to considering that point parts of a solution should be set as constraints on anything that can be done relating to network management going forward.

I have a feeling that this opinion may not be aligned with that of the netmod working group - it needs to be openly discussed as to what the best technical solution is, rather than calling foul on ‘scope’ related discussions.

Thanks for your consideration,
r.

On 26 July 2015 at 20:50:41, Acee Lindem (acee) ([email-masked]) wrote:

Juergen,  

Thanks,  
Acee

---

From: Nadeau Thomas <[email-masked]>
Date: Mon, 27 Jul 2015 06:06:49 -0700

Speaking as NETMOD co-chair:

	This is precisely why we are doing this effort and the others in the way that we are - across areas, with a wide enough group of people involved to hopefully cover the real requirements not just say server implementations, or client implementations - we want to cover those and operators who would using them.  So if one of the outputs of a DT is to conclude that the existing standard models are insufficient, then we will work to revise them.  The DTs should strive to recycle what is there as much as possible, but if in the end it is insufficient there is no other option.  So in summary: The DT should not believe that it is constrained to using only existing models as-is,

	—Tom

> On Jul 27, 2015:3:38 AM, at 3:38 AM, Rob Shakir <[email-masked]> wrote:
> 
> On 26 July 2015 at 20:50:41, Acee Lindem (acee) ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> Juergen,  
>> 
>> <[email-masked] <mailto:[email-masked]>> wrote: 
>> 
>> >Dear Acee, 
>> > 
>> >Note that https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord> says: 
>> > 
>> >>https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/ <https://datatracker.ietf.org/doc/draft-rtgyangdt-rtgwg-device-model/> as 
>> >><[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> 
>> >><[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> 
>> >> To: Lou Berger <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> 
>> >> Cc: Routing YANG 
>> >><[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, YANG Doctors 
>> >><[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>, Loa Andersson 
>> >><[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> 
>> >> [email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>> 
>> >>  
>> >>  
>> >>  
>> >>  
>> >>  
>> > 
>> >> [email-masked] <mailto:[email-masked]> 
>> >> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord> 
>> > 
>> > 
>> >--  
>> >Fax: +49 421 200 3103 <http://www.jacobs-university.de/ <http://www.jacobs-university.de/>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord <https://www.ietf.org/mailman/listinfo/rtg-yang-coord>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 27 Jul 2015 09:25:55 -0400

The constraint to routing was to try and pick a plausibly sized set of work
to focus on, with the assumption it would
feed into other similar work as well.

Regards,
Alia

On Mon, Jul 27, 2015 at 6:38 AM, Rob Shakir <[email-masked]> wrote:

> My assumption, and understanding of the ask that the ADs put to the DT, is
> that the routing design team should consider *usability* of YANG models
> from a routing perspective, and not constrain itself on essentially
> arbitrary IETF-boundaries.
>
> If the output of the DT means that we need cross-area review to further
> its work as any form of standard, or document that the IETF would choose to
> commit to RFC - then engagement with the relevant area should be sought, of
> course.
>
> I am *very* much opposed to considering that point parts of a solution
> should be set as constraints on anything that can be done relating to
> network management going forward.
>
> I have a feeling that this opinion may not be aligned with that of the
> netmod working group - it needs to be openly discussed as to what the best
> technical solution is, rather than calling foul on ‘scope’ related
> discussions.
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 27 Jul 2015 14:14:32 +0000

Mahesh,

From: Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 27, 2015 at 4:18 AM
To: Acee Lindem <[email-masked]<mailto:[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>, Routing YANG <[email-masked]<mailto:[email-masked]>>, YANG Doctors <[email-masked]<mailto:[email-masked]>>, Loa Andersson <[email-masked]<mailto:[email-masked]>>, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>>
Subject: Re: Routing YANG Design Team Scope

Acee,

I see that the mpls model in the draft to be very similar to the one in the OC MPLS draft.

Yes - the OC MPLS model was a starting point.

Is the idea that the device model is trying to define everything under a device tree? I would have thought that the device model would define networking-instance as a 'type identityref’ which would form a base identity, and from which specific networking-instance types would be derived, such as mpls - much like what the interfaces model does for all types of interfaces. That will allow the device model to be a fairly compact model, leaving the feature specific models to be developed elsewhere.

The design team started with https://www.ietf.org/id/draft-openconfig-netmod-model-structure-00.txt and went through several iterations. The motivation excerpted from this draft is:

1.1.  Goals and approach

   In this document, we describe a structure for organizing YANG
   [RFC6020] models that is broadly applicable to physical and virtual
   devices.  Individual models are composed such that the data they
   define can be accessed in a predictable and operationally intuitive
   way that is common across implementations.  This organization enables
   several important capabilities:

   o  a common schema to access data related to all aspects of a device

   o  an extensible structure that makes it clear where additional
      models or data should be fit (e.g., using YANG augmentation or
      imports)

   o  a place for including metadata that provides useful information
      about the corresponding individual models, such as which
      organization provides them, which vendors support them, or which
      version of the model is deployed

   o  a common infrastructure model layer on which higher layer service
      models can be built, for example by specifying which models are
      needed to provide the service

   o  an ability to express an instance of the structure consisting of
      models that have been validated to work together (i.e., with
      information about sources of the models, their versions, etc.), so
      that operators can easily identify a set of models that is known
      to be mutually consistent

   Our approach is to organize the models describing various aspects of
   network infrastructure, including devices and their subsystems, and
   relevant protocols operating at the link and network layers.  The
   proposal does not consider a common model for higher level network
   services, nor does it specify details of how hardware-related data
   should be organized.  Both of these are challenging to standardize --
   services are subject to operational and business considerations that
   vary across network operators, and hardware models are necessarily
   dependent on specific platform features and architecture -- and are
   thus out of scope of this document.  We instead consider the set of
   models that are commonly used by network operators, and suggest a
   corresponding organization.

   As with other models developed from an operator perspective, the
   intent is not to be exhaustive by including all possible models in
   the overall structure, whether currently available or not.  We focus
   on components that are deemed most useful for network operators
   across a variety of use cases.  We recognize, however, that
   additional models will be needed in some cases, and this structure is
   useful for describing how new models can be fit into the overall
   structure.

Thanks,
Acee

Thanks.

On Jul 26, 2015, at 1:49 PM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

Acee,

/js

Thanks,
Acee

On 7/26/15, 3:24 PM, "Juergen Schoenwaelder"
<[email-masked]<mailto:[email-masked]>> wrote:

Dear Acee,

/js

Please comment on

Thanks,
Acee

From: Rtg-yang-coord
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
on behalf of Mahesh Jethanandani
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Date: Sunday, July 26, 2015 at 4:31 PM
To: Lou Berger <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>
Cc: Routing YANG
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, YANG Doctors
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>>, Loa Andersson
<[email-masked]<mailto:[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]><mailto:[email-masked]>

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

Mahesh Jethanandani

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 27 Jul 2015 08:49:53 -0700

Acee,

The boiler plate goals and approach does not answer what I thought was a very specific question. Let me reiterate:

What was thought behind defining a mpls feature in the devices model, vs say defining networking-instance as a 'type identityref’ which would form a base identity, and from which specific networking-instance types such as mpls would be derived? 

The latter in my mind lays the framework for how models could augment the base devices model without defining each and every feature, while the former has to define at least a basic model for each feature which then would have to be augmented anyway to realize the full feature.

Mahesh Jethanandani
[email-masked]

> On Jul 27, 2015, at 7:14 AM, Acee Lindem (acee) <[email-masked]> wrote:
>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Jul 2015 14:07:41 +0000

Mahesh,
The networking-instance is used to instantiate separate layer-3 or layer-2 domains as opposed to protocol domains. For example, in many implementations, a networking-instance would correspond to a VRF or a Virtual Switch Instance (VSI). Hence, it would not make sense to define a separate networking-instance for MPLS since it is only one piece of a layer-3 domain.
Thanks,
Acee

On Jul 27, 2015, at 11:49 AM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

Acee,

Mahesh Jethanandani

On Jul 27, 2015, at 7:14 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

1.1.  Goals and approach

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 28 Jul 2015 09:13:21 -0700

Acee,

> On Jul 28, 2015, at 7:07 AM, Acee Lindem (acee) <[email-masked]> wrote:
> 

Ok.

Similarly, could oam-protocols, control-plane-protocols, system-management, networking-services be identityrefs also? mpls could be part of tunneling-protocols that would include protocols such as gre. 

My concern with the model as it is structured, is its size. Not in terms of code size (because you are using groupings judiciously) but the ultimate size of the tree. I expect the device model to lay the framework for other models to augment the model. In addition, groupings cannot be augmented and if there is a new system-management definition tomorrow, the current structure does not allow for that to be added.

Mahesh Jethanandani
[email-masked]

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 28 Jul 2015 18:29:13 +0000

Mahesh,
The meta model is a “model of models” the proposes a hierarchy. The individual models are separate.
With respect to augmentation, if “grouping” cannot be augmented directly we then must provide containers that can be augmented.
I think you are getting down into the YANG mechanics when the focus should be on the overall model structure. However, the design team is certainly open to suggestions if you have a better representation.
Thanks,
Acee
On Jul 28, 2015, at 12:13 PM, Mahesh Jethanandani <[email-masked]<mailto:[email-masked]>> wrote:

Acee,

On Jul 28, 2015, at 7:07 AM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:

Ok.

Mahesh Jethanandani

---

From: Lou Berger <[email-masked]>
Date: Tue, 28 Jul 2015 15:16:13 -0400

On 07/28/2015 02:29 PM, Acee Lindem (acee) wrote:
> However, the design team is
> certainly open to suggestions if you have a better representation. 

Going a step further, we'd love to hear more from you on this  --
although perhaps  we should do this off list (and on a call).  I'll send
mail...

Thanks,
Lou

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2015 11:18:28 +0200

I disagree that a routing design team can be in charge to do work
that fundamentally affects several standards-track RFCs that only
marginally are routing specific.

Yes, I agree a discussion needs to be held. Being old fashioned, I
believe the place to have this discussions that affects 'network
management going forward' is the OPS area.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2015 11:31:12 +0200

> 	This is precisely why we are doing this effort and the others in the way that we are - across areas, with a wide enough group of people involved to hopefully cover the real requirements not just s…

Tom,

the value of standards is their stability and that we do not change
them every other day. In other words, someone proposing to redo a
standard must have very strong arguments that the current one is
fundamentally flawed and unusable. And these arguments should in my
view be brought to the place where the affected standards were
created.

If the routing area starts to work on the premise that published IETF
standards will be redone based on some ideas originating from a DT but
without agreement of the people who were involved in creating and
implementing the standard, then I think we have a problem.

/js

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jul 2015 07:44:30 -0400

Juergen,

On 07/30/2015 05:31 AM, Juergen Schoenwaelder wrote:
...
> without agreement

Per my previous message.  We, the DT members, understand that from a
process perspective [1] that what we produce is no different than any
other individual contribution/position/draft put forward.  And that
agreement is subject to normal IETF process.

> of the people who were involved in creating and

>From our perspective, we too are people implementing the standard, and
doing so from both the user and vendor sides.

Also ownership of RFCs and WG drafts belongs to the IETF, not to
specific people, and modifications follow the process.

Lou

> /js

[1] https://www.ietf.org/iesg/statement/design-team.html

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jul 2015 07:31:34 -0400

Juergen,

> marginally are routing specific.

I'll defer to the folks that put the DT together to talk to their
motivation.  Of course their desired scope/outcome is documented on the
DT wiki [1].

That said, I think we, the DT, understand the process here and that what
we produce is simply input to the normal IETF process [2].  We're not
"in charge", we are trying to be "agile" and "solve a particular"
problem for users of YANG and YANG model writers for protocols and
mechanisms defined in the routing area.  Certainly our perspective is
different than some, and focused on a certain class of users and authors.

> 
> Yes, I agree a discussion needs to be held. 

Excellent.  And we agree that our work has implication beyond routing
area YANG model users and writers -- and these implications must, as Rob
said, be discussed in the appropriate area/WG.  We've already identified
two such pretty fundamental requirements that we're planning to continue
discussing with folks/WGs in the OPS area.  (i.e., the topics that were
discussed in the netmod interims.)

> Being old fashioned, I

So this can be read to mean that you are saying that all YANG model
definitions and discussions, as they "affect network management", should
take place in the OPS area.  Is this a correct interpretation?  If so,
this isn't a particular scalable approach and doesn't reflect how the
IETF has done things in the past.  If you are saying that changes to
YANG, netconf, restconf, ..., must be discussed in the OPS area, then I
completely agree.

Lou

[1] http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgYangArchDT
[2] https://www.ietf.org/iesg/statement/design-team.html

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2015 14:44:05 +0200

On Thu, Jul 30, 2015 at 07:31:34AM -0400, Lou Berger wrote:
> take place in the OPS area.  Is this a correct interpretation?

No.

> If so, this isn't a particular scalable approach and doesn't reflect how the

I am saying that if RFCs are affected that were done in the OPS area,
then I think it is good idea to explain to the OPS area why they are
not good enough. Except in special cases, I also think that WGs that
produced an RFC ars the default place to discuss shortcomings of an
RFC. This is perhaps formally not required since everything belongs to
the IETF but still I believe this is a good approach to avoid flapping
(trying to use routing vocabular here, I might fail badly with it).

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 30 Jul 2015 15:28:48 +0200

> implementing the standard, then I think we have a problem.
This is the reason why we organized a NETMOD interim meeting on the YANG 
model structure in June (and another one on the oper status btw).
Unfortunately, some key openconfig people were not in Prague to discuss 
further. Another NETMOD interim is the way to go. Currently in 
discussion with the NETMOD chairs.

Regards, Benoit

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jul 2015 09:32:53 -0400

> discussion with the NETMOD chairs.

Agreed & Thanks!

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jul 2015 09:37:24 -0400

Juergen,

>> take place in the OPS area.  Is this a correct interpretation?

Great.

> RFC. 

100% agree.

> This is perhaps formally not required since everything belongs to

WFM.  I appreciate the effort to try to understand our (user and vendor)
perspective(s) as it clearly is different than what has been the focus
to date -- to me this is a symptom of the growing pains related to
successful use/adoption of a new technology.

Lou

---

From: Andy Bierman <[email-masked]>
Date: Thu, 30 Jul 2015 08:53:34 -0700

Hi,

Is there a design team report published yet?
I agree with Juergen that existing YANG data
such as /interfaces, system, netconf-state MUST NOT
be moved to a different place in the data tree.

You should restrict your activities to new routing modules.

Andy

---

From: Nadeau Thomas <[email-masked]>
Date: Thu, 30 Jul 2015 09:33:31 -0700

We are planning one for the second week of September, but I have not booked it yet. I will do so early next week. 

	—Tom

> On Jul 30, 2015:6:32 AM, at 6:32 AM, Lou Berger <[email-masked]> wrote:
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 30 Jul 2015 16:42:17 -0400

Hi Andy,

> Is there a design team report published yet?

The work is still underway.
see https://www.ietf.org/proceedings/93/slides/slides-93-rtgwg-3.pdf
and draft-rtgyangdt-rtgwg-device-model-00.txt

> be moved to a different place in the data tree.

This is part of the discussion that was and will be subject to the
Netmod interims.  We'd like to find a solution to our use case /
requirements that coexists with existing models/RFCs.

> You should restrict your activities to new routing modules.

The objective is to reuse and augment what's there to the maximum extent
possible and to work with the groups that own the respective mechanisms
when we hit limitations/restrictions to come up with a consensus-based
solution.

Lou

> 
> 
> Andy
> 
> 
> On Tue, Jul 28, 2015 at 12:16 PM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>