Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

From: "Susan Hares" <[email-masked]>
Date: Sat, 19 Apr 2014 08:17:22 -0400

Nitin:

I've been digging into the RBNF forms in Section 6
draft-ietf-i2rs-rib-info-model-02  based on what you indicated to mach.  I
would like to confirm I understand your intent of the RBNF.   

1)  match will augment its sequence with a type 
 <match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> | <mac-route> |
<interface-route> 

Will be redefined as: 
<match> ::= <route-type> [ <ipv4-route> | <ipv6-route> | <mpls-route> |
mac-route> | <interface-route>]

This sequence occurs wit: 1 route-type, 1 following definition.  

Route-type::= <IPv4> | <IPv6> | <MPLS> | <IEEE-MAC> | <INTERFACE> 
(these are the values)

Do I understand your values?  

2) Let's take one example of your IPv4 

<ipv4-route> ::= <IPv4>  [<destination-ipv4-address> | <source-ipv4-address>
| <destination-ipv4-address> <source-ipv4-address> 
<destination-ipv4-address>::=<ipv4-prefix> 
<ipv4-prefix> ::=<IPV4_ADDRESS> <IPV4_PREFIX_LENGTH> 

Are you intending to allow:  destination-ipv4-address or source-ipv4-address
or the combination of <destination-ipv4-address-> <source-ipv4-address>?  If
so, do you want a tag to identify the type of form it is? 

<ipv4-route> ::= <rt-form> [<destination-ipv4-address> |
<source-ipv4-address> | <destination-ipv4-address> <source-ipv4-address>] 
<ip-form>::=<DST>|<SRC> | <DSTSRC> | <

3)  Let's take the use case of matching a destination-ipv4-address: 

<match> ::= <IPv4> <IPv4><IPV4_ADDRESS><IPV4_PREFIX_LENGTH>

I doubt you really wanted the redundant tag.   This will occur for IPv6 as
well.

If you use a tag form that has ip-form
<match>::<IPv4><DST><IPV4_ADDRESS><IPv4_PREFIX_LENGTH> 

4) Would a corrections to the above be useful:
Given the above you could simplify your match RBNF:

<match>:: = <route-tag> <rt-form> [ipv4-route | ipv6-route | mpls-route |
mac-route]
ipv4-route ::= [ipv4-prefix] | [ipv4-prefix][ipv4-prefix] 
ipv6-route ::= [ipv6-prefix] | [ipv6-prefix][ipv6-prefix]
mpls-route::= [mpls-label]  | [mpls-label][mpls-label]
mac-route::= [MAC_ADDRESS] | [MAC_ADDRESS][MAC_ADDRESS]

These basic variables are defined in YANG Data Models and FORCES data
models.  You do not need to go further with the simple definitions. 

5) Why did you specify differently? 

multicast-source-ipv4-address ::=<IPv4-Address> <IPV4_PREFIX_LENGTH>
multicast-source-ipv6-address ::=<IPv6-Address><IPV6_PREFIX_LENGTH>

Where you trying to express some checking that the node should have on these
address?  I've got similar questions on <next-hop-list>, <route-attributes>
and <vendor-attributes>.  I will start a different mail thread for these. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Nitin Bahadur
Sent: Friday, February 14, 2014 4:55 PM
To: Mach Chen; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

Hi Mach,

  Thanks for your comments. Please see inline below..

>General comments:
>According to the recent discussion about "Multi-Headed Control", seems 
>there needs to define the unit of the "data" that will be changed by 
>the I2RS clients in this rib im document.
>
>
>Specific Comments:
>1. Section 6
><mpls-route> ::= <MPLS> <MPLS_LABEL>
><mac-route> ::= <IEEE_MAC> ( <MAC_ADDRESS> )
>
>1.1 Seems the brackets of " ( <MAC_ADDRESS> )" are redundant.

Yes. We will remove them in next rev.

>
>1.2 What's the <MPLS> and <IEEE_MAC> stands for here? The route type?

Yes..route type.

> 
>If so, why not apply this to the <ipv4-prefix> and <ipv6-prefix> as 
>well ,hence <ipv4-prefix> ::= <IPV4_ADDRESS> <IPV4_ADDRESS_LENGTH> 
>would be <ipv4-prefix> ::= <IPv4> <IPV4_ADDRESS> <IPV4_ADDRESS_LENGTH>, 
>and <ipv6-prefix> ::= <IPV6_ADDRESS> <IPV6_ADDRESS_LENGTH> would be 
><ipv6-prefix> ::= <IPv6> <IPV6_ADDRESS> <IPV6_ADDRESS_LENGTH>

I think I know what you mean. What might be more appropriate would be:

<ipv4-route> ::= <IPv4> (<destination-ipv4-address> | <source-ipv4-address>
|
                         (<destination-ipv4-address>
<source-ipv4-address>))

Or the other way to model this would be:

<match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
                          <mac-route> | <interface-route>) <route-type> ::=
<IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>

>
>
>2. Section 6
><rib-family> ::= <IPV4_RIB_FAMILY> | <IPV6_RIB_FAMILY> |
>                    <MPLS_RIB_FAMILY> | <IEEE_MAC_RIB_FAMILY>,
>
>and
>
><match> ::= <ipv4-route> | <ipv6-route> | <mpls-route> |
>               <mac-route> | <interface-route> There are four rib 
>families defined, but there are five types route, so which rib family 
>does the interface-route belong to? Seems there needs a 
><INTERFACE_RIB_FAMILY>.

An interface is part of a routing-instance <routing-instance> ::=
<INSTANCE_NAME>
                       [<interface-list>] <rib-list> [<ROUTER_ID>]

The purpose of a RIB family is essentially to identify what protocol
treatment to give to a packet. For example, for an IPv4 packet, you would do
a TTL check. For an interface-route, there is no such behavior. An IPv4
route can be associated with any interface in the <interface-list> above.
Interface-route is more of a container (match) for all packets coming in on
an interface. The network-device can choose to do DPI on the packet and run
checks before it processes interface-route matching packets, or it can just
choose to do what the interface-route says (match all packet coming in
interface-A and send them out via interface-B).

So in summary, I don¹t see a real need for INTERFACE_RIB_FAMILY.

> 
>3. Section 6
><route> ::= <match> <nexthop-list>
>               [<route-attributes>]
>               [<route-vendor-attributes>]
>
>When a route was installed in the RIB, there should be an indication to 
>identify from which protocols (e.g., ISIS, OSPF, BGP, I2RS, CLI etc.) 
>the route is. So there may need a <Origin> attribute.
>Maybe similar like this:
><Origin> ::= <RIP> | <OSPF> | <ISIS> | <BGP> | <LDP> | <RSVP-TE> | 
><CLI>
>| <I2RS>
>
>How do you think?

Yes, there ³could² be such an optional attribute. What we need to think more
towards is, is just the protocol-type sufficient or do you need other things
as well, like protocol peer address (just thinking aloud).

>
>4. Section 6
><tunnel-type> ::= <IP> | <MPLS> | <GRE> | <VxLAN> | <NVGRE>
>
>Should the <IP> be more specific to <IPv4> and <IPv6>? What does the 
><IP> really intend for? UDP, TCP? And there may be other tunnel, e.g.,
l2tp.

Makes sense to have IPv4 and IPv6 called out separately. The IPv4/v6 is
basically for IP-in-IP tunnels. And yes, there could be other tunnels like
L2TP, etc. I guess we don¹t want to create an exhaustive list of tunnels in
the info model, but rather leave it to the data model and data-model
extensions. We¹ll split the v4/v6 stuff in next rev.

>
>5. Section 7.1
>
>AS-data information and AS length comparison are BGP related stuff, 
>this should be transparent to RIB manager. I am not sure whether this 
>belongs to Rib info model.

This has been removed in the latest version.

Thanks
Nitin

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 28 Apr 2014 18:00:49 -0700

Hi Sue,

>Do I understand your values?

Correct.

><ip-form>::=<DST>|<SRC> | <DSTSRC> | <

Yes, I am intending to allow all 3 possibilities. A tag is needed.

<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
(this will apply to IPv4 and IPv6)

><match>:: = <route-tag> <rt-form> [ipv4-route | ipv6-route | mpls-route |

The <rt-form> is not needed for mpls and mac routesŠ.since MPLS has no
concept of SRC or DEST. So that simplification will actually not help :(

The <ip-route-type> will need to be associated specifically with
<ipv4-route> and <ipv6-route>.

>address? 

Thanks for catching this. They have no reference in the -02 version. They
are a remnant of -00 of the draft. After the grammar was modified in -01,
they should have been deleted.

> I've got similar questions on <next-hop-list>, <route-attributes>

Looking forwardŠ

Thanks
Nitin

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 28 Apr 2014 21:19:55 -0400

Nitin:

Thanks for the quick response.  Just one thing to consider: 

><match>:: = <route-tag> <rt-form> [ipv4-route | ipv6-route | mpls-route 
>| mac-route]

[Nitin] The <rt-form> is not needed for mpls and mac routesŠ.since MPLS has
no concept of SRC or DEST. So that simplification will actually not help :(

[Sue]: Yes, not all forms would benefit.  However, MPLS does have the stack
tags that we may want to save and match on.  Also: the 5-tuples may be a
part of matching some routes.  By using rt-form, we are using the TLV format
to set-up these multiple formats.  Each format, would have the appropriate
expectations for the appropriate address families. 

[Sue]:  I think it provides table based code. 

[Sue]: yes, it could.  With the rt-form and the rib-family type, perhaps we
can remove the rt-type. 
[snip] 

>Where you trying to express some checking that the node should have on 
>these address?

Here's the next question - how were you planning to handle the multiple
next-hops for the multicast.  Did you have a plan? 
You will have both ECMP (unicast) multiple nexthops, and multicast
replication next hops.   A flag might do nicely to differentiate.
We could put this on the next hop.

Thanks for your review 

Sue

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 28 Apr 2014 23:36:43 -0700

Hi Sue,

>[Sue]:  I think it provides table based code.

The main issue is that the grammar will not be deterministic. In other
words, one needs a way to specify that <route-tag-1> <rt-form-A> is valid
and <route-tag-1> <rt-form-B> is NOT valid.

>[Sue]: yes, it could.  With the rt-form and the rib-family type, perhaps

Rib-family-type and route-type are kind of the same thing. I need to think
if there is a case where they can be different...

>You will have both ECMP (unicast) multiple nexthops,

Unicast multiple next hops are covered in Section 7.2.3.

> and multicast replication next hops.

Section 7.3 talks about multicast replication (and refers to Section
7.2.2).

> A flag might do nicely to differentiate.

LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to indicate
ECMP/load-balancing.

Thanks
Nitin

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 29 Apr 2014 06:14:53 -0400

Nitin:

Thanks for responding 
[snip] 
>
>[Sue]: Yes, not all forms would benefit.  However, MPLS does have the 
>stack tags that we may want to save and match on.  Also: the 5-tuples 
>may be a part of matching some routes.  By using rt-form, we are using 
>the TLV format to set-up these multiple formats.  Each format, would 
>have the appropriate expectations for the appropriate address families.
>

[Nitin] The main issue is that the grammar will not be deterministic. 
[Nitin] In other words, one needs a way to specify that <route-tag-1>
<rt-form-A> is valid and <route-tag-1> <rt-form-B> is NOT valid.

[Sue-2 on] 
Why is the grammar not explicit? Let's put the type back in for each 

<match_form = DST> <match_type = IPv4> <ip-v4-prefix>    (addresses are just
a specific type of prefix) 
<match_form=SRC> <match_type = IPv4> <ipv4-prefix>        (addresses are
just a specific type of prefix) 
<match_form=DST-SRC> <match_type = ipv4> <ipv4-prefix> <ipv4-prefix> 

This is TLV where (form-type) implies a specific length (in example, 8,8,
16). 
If you want to go with the traditional TLV form, consider the (form-type) as
a Type field, 
And put in a length field.    

The same is true of the nh-form and nh-type fields 
<rt-form = NH-Name>> <NH-name> - this is the only valid 
<rt-form = NH-Address> <NH-type = v4> <ip-v4-prefix>  (note address is just
a specific type of prefix)
<rt-form=NH-address><NH-type=v6> <ip-v6-prefix> (note that prefix is just a
specific type of prefix)

I did change these directly to TLV forms - so there would be a stepping
stone to the 

>[Sue]: yes, it could.  With the rt-form and the rib-family type, 
>perhaps we can remove the rt-type.
>[snip]

[Sue-2-off] 

[snip]
>>5) Why did you specify differently?
[Nitin]::  Unicast multiple next hops are covered in Section 7.2.3.
<snip> 
[Nitin] LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to
indicate ECMP/load-balancing 
> and multicast replication next hops.
[Nintin] Section 7.3 talks about multicast replication (and refers to
Section 7.2.2).

[Sue]: You are stating that: 

<nexthop-list> ::= (<nexthop> <LOAD_BALANCE_WEIGHT>) [(<nexthop>
<LOAD_BALANCE_WEIGHT>)... ]
Is the flag for NH ECMP 

<nexthop-list> ::=  (<nexthop> <PROTECTION_PREFERENCE>)  
                                [(<nexthop> <PROTECTION_PREFERENCE>)... ]

Sets primary/backup, and mixed with LOAD_BALANCE_WEIGHT - you groupings of
next-hops that are used for multicast (as default).  

  <nexthop-list> ::= <nexthop> [ <nexthop> ... ] 

This makes it specific, but requires you specify the LOAD_BALANCE_WEIGHT
with each next hoip.
Were you intended your LOAD_BALANCE_WEIGHT to be a integer, and the
LOAD_PROTECTION_PREFERENCE to be a number. 

Thanks
Nitin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 29 Apr 2014 10:19:54 -0400

Remember that an information model is not a grammar.  It is perfectly 
okay in an IM to have two branches that are just different things. 
Discriminators are added in when one goes from teh information model to 
the data model.

Yours,
Joel

On 4/29/14, 2:36 AM, Nitin Bahadur wrote:
>> stack

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 29 Apr 2014 14:55:56 -0700

>From the draft:

  o PROTECTION_PREFERENCE: This provides a primary/backup like
      preference.  The preference is an integer value that should be set
      to 1 (primary) or 2 (backup).  Only when all the primary nexthops
      fail is the traffic re-routed through the backup nexthops.  This
      attribute must be specified for all the members of a list or none
      of them.

   o  LOAD_BALANCE_WEIGHT: This is used for load-balancing.  Each list
      member MUST be assigned a weight between 1 and 99.  The weight
      determines the proportion of traffic to be sent over a nexthop
      used for forwarding as a ratio of the weight of this nexthop
      divided by the weights of all the nexthops of this route that are
      used for forwarding.  To perform equal load-balancing, one MAY
      specify a weight of "0" for all the member nexthops.  The value
      "0" is reserved for equal load-balancing and if applied, MUST be
      applied to all member next hops.

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 29 Apr 2014 15:09:15 -0700

>And put in a length field.

Unfortunately this is not our typical TLV, sub-TLV definitions specified
in IANA registryŠusing which one can easily see what is valid and what is
not. In fact we don¹t want anyone to refer to a registry, since all the
code is going to be auto-generated (using the data-model toolŠtbd).

I think I¹m just not clear on your proposal. Here is the grammar I have.

<match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
                          <mac-route> | <interface-route>)
<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>

<ipv4-route> ::= <ip-route-type> (<destination-ipv4-address> |
<source-ipv4-address> |
                                  (<destination-ipv4-address>
<source-ipv4-address>))
<ipv6-route> ::= <ip-route-type> (<destination-ipv6-address> |
<source-ipv6-address> |
                   (<destination-ipv6-address> <source-ipv6-address>))
<ip-route-type> ::= <SRC> | <DEST> | <DEST_SRC>
<mpls-route> ::= <MPLS_LABEL>
<mac-route> ::= <MAC_ADDRESS>
<interface-route> ::= <INTERFACE_IDENTIFIER>

If you could express what you are saying in the same-way, maybe I¹ll get
more clarity.

Thanks
Nitin

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 07:26:55 -0400

Joel:

Great!  This is the answer I hoped to get.  Just to make sure,  We are
defining a role as:  identity + rib tree + access (read or write or
read-write).
If I define a tree portion that is read-only does that align with our role
definitions. 

If this is a common definition, then I'm good to release the next version of
the draft with read/write for the RIB-info. 

Sue  

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Tuesday, April 29, 2014 10:20 AM
To: Nitin Bahadur; Susan Hares; 'Mach Chen'; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

Remember that an information model is not a grammar.  It is perfectly okay
in an IM to have two branches that are just different things. 
Discriminators are added in when one goes from teh information model to the
data model.

Yours,
Joel

On 4/29/14, 2:36 AM, Nitin Bahadur wrote:
>> [Nitin] The <rt-form> is not needed for mpls and mac routesŠ.since 
>> MPLS has no concept of SRC or DEST. So that simplification will 
>> actually not help :(
>>
>> may be a part of matching some routes.  By using rt-form, we are 
>> using the TLV format to set-up these multiple formats.  Each format, 
>> would have the appropriate expectations for the appropriate address 
>> families.
>>
> words, one needs a way to specify that <route-tag-1> <rt-form-A> is 
> valid and <route-tag-1> <rt-form-B> is NOT valid.
>
>
>>
> Rib-family-type and route-type are kind of the same thing. I need to 
> think if there is a case where they can be different...
>
>
>>
>>> Where you trying to express some checking that the node should have 
>>> on these address?
>>
>> Thanks for catching this. They have no reference in the -02 version. 
>> They are a remnant of -00 of the draft. After the grammar was 
>> modified in -01, they should have been deleted.
>>
>> Here's the next question - how were you planning to handle the 
>> multiple next-hops for the multicast.  Did you have a plan?
>>
> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to 
> indicate ECMP/load-balancing.
>
>
>
> Thanks
> Nitin
>
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 07:54:26 -0400

Nitin: 

Let me start with my perception of the problem:  

Problem: Your grammar does not handle source-destination form choice as a
generic form used by all of the interfaces. 
Solution:  Specify form as specific variable for all forms. 
Confusion:  I am suggesting two tags <form-tag><route-type> and you want see
one tag for compilation.  

See the two tags: [form-type] as two parts to one tag:  

[high order tag form] [low order form - address form] 

At this point, all I have done is reduce your complex forms to 1 tag  
<route-type> =  <form-tag><type-tag> 

Then your grammar is as follows: 

<route-type> =  <form-tag><type-tag>
<form-tag> = <SRC-FORM><DST-FORM><SRC-DST FORM> 
Routing protocols would have:  [rrr ff ttt]  r = reserved/0  ff = 0/1 (for
src/dst), ttt = type]  

<type-tag> ::=<IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE> 

Each of these forms for matches could use the SRC and destination in the
filter. 

I'm sure that IPv4, IPv6, and IEEE_MAC are obvious from your emails.
Interfaces can be viewed as the same for flows: <SRC-INTERFACE>
<DST-INTERFACE>.  This can be that the traffic flow comes in on interface1
and goes out on interface 2 for all interfaces.  MPLS could but it can be
ingress/egress label as source/destination. 

Do you agree/disagree have a potential of having source-destination for most
of these types? 

Your grammar could then be restated: 
================================
<match> ::= <route-type> (<ipv4-route> | <ipv6-route> | <mpls-route> |
                          <mac-route> | <interface-route>) 

<route-type> ::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
<form-type> ::= <SRC> | <DEST> | <DEST_SRC>

<ipv4-route> ::= (<destination-ipv4-address> | <source-ipv4-address> |
                                  (<destination-ipv4-address>
<source-ipv4-address>))

<ipv6-route> ::=   (<destination-ipv6-address> | <source-ipv6-address> |
                   (<destination-ipv6-address> <source-ipv6-address>)) 
<form-type> ::= <SRC> | <DEST> | <DEST_SRC> 

<mpls-route> :: =  ( (egress-MPLS-label) | (Ingress-MPLS_LABEL>) |
(<egress-mpls-label><ingress-MPLS_LABEL>))  
<mac-route> ::= > (<DST-MAC_ADDRESS> |  [<SRC-MAC-ADDRESS>] |
(<DST_MAC_ADDRESS><SRC-MAC-ADDRESS>))
<interface-route> ::=   (<DST-INTERFACE_IDENTIFIER> |
<SRC-INTERFACE-IDENTIFIER> | (<DST-INTERFACE-IDENTIFIER>
<SRC-INTERFACE-IDENTIFIER>) )

If you need context on the interfaces, pleases consider multicast and flows.
The rest hopefully is QED based the above grammar.  If we can start with
this, I hopefully, you can see the extension to other forms n-tuple and
next-hops. 

Sue

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 30 Apr 2014 09:39:17 -0400

I do not think that matches the definition of role we are using.
An identity has a role.  Several identities may have the same role.
And a role is defined by a collections if <im-tree-portion, access 
permission> pairs.

This is not specific to the RIB model, and should not be in the rib 
model at all as far as I can tell.

Separate from the definition of role, and again applicable across all 
information models, an agent may itself have access restrictions.  A 
client using an agent is restricted to the access set which is permitted 
both by its role and by what the agent has permission to do.

Again, if we want to model that, we should model it outside of any 
specific IM.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 09:53:56 -0400

Joel:

Thank you for the clarification, I should have been clearer.   Identity is
uniquely defined by a security entity. 

Role = pairs of (im-tree-portion, access-permission) pairs

If the IM model wants to  have 
   (im-tree-portion = rib-rw section, read-write) pair  
   (im-tree-portion = rib-ro-section, read-only) pair 

Then this is the role of the client-agent pair.  This assumes that agent can
grant both the RIB structure has both r-w for configuration (as in the
current document), and a read-only section (dynamic statistics).  

Therefore, If I understand correctly - I can utilize Yang-tree model as
poor-man's Info-Model since it can both represent the r-w tree
(configuration) and the rib-ro tree for dynamics status.  For the
notifications sequence (it may config state (turn on/off reporting) and
ro-state.

Sue 

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 9:39 AM
To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

This is not specific to the RIB model, and should not be in the rib model at
all as far as I can tell.

Separate from the definition of role, and again applicable across all
information models, an agent may itself have access restrictions.  A client
using an agent is restricted to the access set which is permitted both by
its role and by what the agent has permission to do.

Again, if we want to model that, we should model it outside of any specific
IM.

Yours,
Joel

On 4/30/14, 7:26 AM, Susan Hares wrote:
> If I define a tree portion that is read-only does that align with our 
> role definitions.
>
> If this is a common definition, then I'm good to release the next 
> version of the draft with read/write for the RIB-info.
>
> Sue
>
> Discriminators are added in when one goes from teh information model 
> to the data model.
>
> Yours,
> Joel
>
>>> [Sue]: Yes, not all forms would benefit.  However, MPLS does have 
>>> the stack tags that we may want to save and match on.  Also: the 
>>> 5-tuples may be a part of matching some routes.  By using rt-form, 
>>> we are using the TLV format to set-up these multiple formats.  Each 
>>> format, would have the appropriate expectations for the appropriate 
>>> address families.
>>>
>> The main issue is that the grammar will not be deterministic. In 
>> other words, one needs a way to specify that <route-tag-1> 
>>>> multicast-source-ipv4-address ::=<IPv4-Address> 
>>>> <IPV4_PREFIX_LENGTH> multicast-source-ipv6-address 
>>>> ::=<IPv6-Address><IPV6_PREFIX_LENGTH>
>>>>

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 30 Apr 2014 10:01:54 -0400

As an Information model, treating the YANG tree as an info model has the 
problem that the information model is probably not a tree.  There will 
be a well-defined tree if the data model is YANG.  But there is not such 
a restriction at the info model level.

But I still don't understand why you even need to mention this in the 
rib information model.

Just for clarity, I would have written the permissions paradigm as:
(im-tree = portion definition 1, read-write) *
(im-tree = portion definition 2, read-only) *

Where the "*" indicates that each of those can occur 0 or more times.
There is not a well defined information model notion of the rib-rw section.

Yours,
Joel

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Apr 2014 07:02:19 -0700

On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern <[email-masked]>wrote:

> This is not specific to the RIB model, and should not be in the rib model
> at all as far as I can tell.
>
NETCONF and RESTCONF already have a standard Role-Based Access Control
Model,
called NACM (RFC 6536).  Does the I2RS WG plan to create its own ACM, leave
it
to vendors, or something else?

> Joel

Andy

>> the

---

From: Joel Halpern Direct <[email-masked]>
Date: Wed, 30 Apr 2014 10:13:56 -0400

There are at least two reasons why I at least find the reasonable 
quesiton you have asked to be difficult to answer.

First, it is not at all obvious that manipulation of the access control 
is within scope for I2RS.  The permissions may not even be defined and 
manipulated on the same device where the I2RS agent resides.

Second, we are working on an information model.  RFC 6536 is a data 
model, and specific to the NetConf/YANG data model.

Personally, as I have said repeatedly, I do not see any reason for us to 
have an information model for this until we conclude that there is some 
manipulation of it which is within scope.

Yours,
Joel

On 4/30/14, 10:02 AM, Andy Bierman wrote:
>
>
>
> On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Separate from the definition of role, and again applicable across
>     all information models, an agent may itself have access
>     restrictions.  A client using an agent is restricted to the access
>     set which is permitted both by its role and by what the agent has
>     permission to do.
>
> called NACM (RFC 6536).  Does the I2RS WG plan to create its own ACM,
> leave it
>         From: Joel M. Halpern [mailto:[email-masked]
>         <mailto:[email-masked]>]
>         <mailto:[email-masked]>
>         Cc: [email-masked]
>         <mailto:[email-masked]>
>         Subject: Re: [i2rs] Some comments on
>         draft-ietf-i2rs-rib-info-__model-01
>
>                     <match>:: = <route-tag> <rt-form> [ipv4-route |
>                     ipv6-route |
>                     mpls-route
>                     | mac-route]
>
>
>                     ::=<IPv6-Address><IPV6_PREFIX___LENGTH>
>
>             _________________________________________________
>             i2rs mailing list
>             [email-masked] <mailto:[email-masked]>
>             https://www.ietf.org/mailman/__listinfo/i2rs
>             <https://www.ietf.org/mailman/listinfo/i2rs>
>
>
>
>     _________________________________________________
>     i2rs mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/i2rs
>     <https://www.ietf.org/mailman/listinfo/i2rs>
>
>

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 30 Apr 2014 10:19:59 -0400

On Apr 30, 2014:10:02 AM, at 10:02 AM, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Wed, Apr 30, 2014 at 6:39 AM, Joel M. Halpern <[email-masked]> wrote:
> And a role is defined by a collections if <im-tree-portion, access permission> pairs.
> 
> This is not specific to the RIB model, and should not be in the rib model at all as far as I can tell.
> 
> Separate from the definition of role, and again applicable across all information models, an agent may itself have access restrictions.  A client using an agent is restricted to the access set which is permitted both by its role and by what the agent has permission to do.
> 
> Again, if we want to model that, we should model it outside of any specific IM.
> 
> 
> NETCONF and RESTCONF already have a standard Role-Based Access Control Model,
> called NACM (RFC 6536).  Does the I2RS WG plan to create its own ACM, leave it

	It was very much my understanding/intention to use RFC6536.
	
	--Tom

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Apr 2014 07:43:15 -0700

On Wed, Apr 30, 2014 at 7:13 AM, Joel Halpern Direct <
[email-masked]> wrote:

> There are at least two reasons why I at least find the reasonable quesiton
> you have asked to be difficult to answer.
>
> First, it is not at all obvious that manipulation of the access control is
> within scope for I2RS.  The permissions may not even be defined and
Agreed.  Vendors and operators would prefer a single ACM that applies
to all protocols. (Even though NACM says it is only for NETCONF, nobody
implements it that way. CLI, WEBui, RESTCONF, etc. all use the same
authorization rules.

Second, we are working on an information model.  RFC 6536 is a data model,
> and specific to the NetConf/YANG data model.
>
>
Most of it is YANG-specific, not NETCONF-specific.
The access rules are based on YANG statements.
But only the behavior for the NETCONF protocol is defined in detail.
I doubt NACM could be used without additional text in some I2RS RFC.

> manipulation of it which is within scope.
Agreed.
The info model and the data model are written (mostly) independent
of access control.

Yours,

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 10:49:21 -0400

Joel:

Ok - so I've got to get something to describe this: 

(im-tree = portion definition 1, read-write) * (im-tree = portion definition
2, read-only) *

I'm trying to get a workable alternative to RBNF to discuss the actual
im-tree.  UML is best, but I'm not sure If I can it in the documents.  5
pages of UML covers all the RIB models.  UML tools can create yang data
models and forces (In my understanding).    However, some human beings seem
to need the yang tree models to see the tree and links to yang. 

I'm working through RIB-info so I can have a meaningful discussion on the
rest of the RIB models with precise language.  And I need to know that I've
gotten a precise definition in order to finalize the security. 

Help - online or offline would be useful.  If you or anyone else sends
offline help, I will summarizes to list.  

Sue 

-----Original Message-----
From: Joel Halpern Direct [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 10:02 AM
To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

As an Information model, treating the YANG tree as an info model has the
problem that the information model is probably not a tree.  There will be a
well-defined tree if the data model is YANG.  But there is not such a
restriction at the info model level.

But I still don't understand why you even need to mention this in the rib
information model.

Just for clarity, I would have written the permissions paradigm as:
(im-tree = portion definition 1, read-write) * (im-tree = portion definition
2, read-only) *

Yours,
Joel

On 4/30/14, 9:53 AM, Susan Hares wrote:
> Then this is the role of the client-agent pair.  This assumes that 
> agent can grant both the RIB structure has both r-w for configuration 
> (as in the current document), and a read-only section (dynamic
statistics).
>
> Therefore, If I understand correctly - I can utilize Yang-tree model 
> as poor-man's Info-Model since it can both represent the r-w tree
> notifications sequence (it may config state (turn on/off reporting) 
> and ro-state.
>
> Sue
>
>
> client using an agent is restricted to the access set which is 
> permitted both by its role and by what the agent has permission to do.
>
>> Great!  This is the answer I hoped to get.  Just to make sure,  We 
>> are defining a role as:  identity + rib tree + access (read or write 
>> or read-write).
>> draft-ietf-i2rs-rib-info-model-01
>>
>>>>> Where you trying to express some checking that the node should 
>>>>> have on these address?
>>>>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 10:56:36 -0400

Andy:

My goal is not to invent something new, so as an expert in  netconf/restconf role-based access control model could you: 

1 – comment if this can be handle by netconf/restconf

Identity + role  <im-tree-portion, access permission> pairs

2 – provide me with references to these RFCs that I should pull out to reference to identify how this could be expressed? 

<snip> 

<snip> 

Sue

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Apr 2014 08:36:31 -0700

On Wed, Apr 30, 2014 at 7:56 AM, Susan Hares <[email-masked]> wrote:

> Andy:
>
>
>
> My goal is not to invent something new, so as an expert in
>  netconf/restconf role-based access control model could you:
>
>
>
> 1 - comment if this can be handle by netconf/restconf
>
>
>

yes.
NACM assigns users to admin-configured groups.
Groups are used to represent roles. Rule-lists are
used to specify policy for various groups. There are several
wildcards and defaults to make rule specification simple.
Rules are processed in order (first match == process and exit)

http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#rule-list.310

>
> 2 - provide me with references to these RFCs that I should pull out to
> reference to identify how this could be expressed?
>
>
>

The access control model is in RFC 6536.

A 'data rule' would be configured to achieve the policy above:

 -  'admin' group has full access the /foo/rib-data subtree
 -  'monitor' group has read access the /foo/rib-data subtree
 -  all others have no access

  <rule-list>
    <name>admin-can-write-rib-data</name>
     <group>admin</group>
     <rule>
        <name>foo-rib-data</name>
        <path>/acme:foo/acme:rib-data</path>
        <access-operations>create read update delete</access-operations>
        <action>permit</action>
     </rule>
  <rule-list>
  <rule-list>
    <name>monitor-can-read-rib-data</name>
     <group>monitor</group>
     <rule>
        <name>foo-rib-data</name>
        <path>/acme:foo/acme:rib-data</path>
        <access-operations>read</access-operations>
        <action>permit</action>
     </rule>
  <rule-list>
  <rule-list>
    <name>no-access-to-rib-data</name>
     <rule>
        <name>foo-rib-data</name>
        <path>/acme:foo/acme:rib-data</path>
        <action>deny</action>
     </rule>
  <rule-list>

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 12:10:26 -0400

Andy:

Thanks.  The pointer are helpful!

Sue 

From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 11:37 AM
To: Susan Hares
Cc: Joel M. Halpern; Nitin Bahadur; [email-masked]; Mach Chen;
[email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

Andy:

My goal is not to invent something new, so as an expert in  netconf/restconf
role-based access control model could you: 

 

yes.

http://www.netconfcentral.org/modules/ietf-netconf-acm/2012-02-22#rule-list.
310

 

 

  <rule-list>

     <group>admin</group>

     <rule>

        <action>permit</action>

     </rule>

  <rule-list>

  <rule-list>

     <group>monitor</group>

     <rule>

        <action>permit</action>

     </rule>

  <rule-list>

  <rule-list>

     <rule>

        <action>deny</action>

     </rule>

  <rule-list>

<snip> 

<snip> 

Sue 

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Apr 2014 19:48:54 +0200

> to need the yang tree models to see the tree and links to yang. 

I assume people mean UML class diagrams when they say UML. That said,
yes tools can turn UML into other stuff. However, whether the result
is 'nice' or 'implementable are reasonable pain' is a different
question (and I understand that 'nice' and 'pain' have no clear
definition). UML class diagrams allow the representation of arbitrary
relationships between classes. If you have to turn this into a
hierarchy for a protocol using a hierarchical namespace, then tools
most likely only create _a_ solution not a _good_ solution.

If you believe tools do a good job translating IMs to DMs, you will
likely soon find that this is generally not the case and in order to
make it work better you will start to augment you IM with lots of
additional detail for the translator to do a reasonably good job, in
which case your IM deteriorates to some extend into a DM.

/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: Nitin Bahadur <[email-masked]>
Date: Wed, 30 Apr 2014 11:10:28 -0700

Hi Sue,

   Thanks for putting this down in detail. Now it¹s easier to explain what
I was trying to convey.

-----Original Message-----
From: Susan Hares <[email-masked]>

>generic form used by all of the interfaces.

YesŠit is by design. See more below.

><type-tag> ::=<IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>

What the above grammar does is that it allows one to construct a match
that looks like:

<match> ::= <SRC-DST FORM> <MPLS> <mpls-in-label>

This is obviously incorrect. That¹s the part I have been trying to convey.
In the world of routing protocols, we have IANA registries that specify
what combination is legal. In the world of data-models, we can¹t depend on
that. So with the grammar above, how do you prevent a badly-written
controller from sending a match condition that looks like above (not that
the data-model will successfully compile this match conditionŠsince the
rules allow it)?

><DST-INTERFACE>. 

Match is always on an incoming packet. A packet does not have embedded in
it the dst-interface. So you cannot have a
dst-interface as part of the match condition.

>This can be that the traffic flow comes in on interface1

I disagree that there is a potential of having a src-dst for most types.
Src-dst is only possible ³in a match condition²
for a route-type that has src and dest information embedded in the packet.
IPv4/IPv6 & IEEE-MAC are the only possibilities.
For IEEE-MAC, there has been no use-case (requirement yet) to have SRC-DST
based routingŠ.so it wasn¹t included so far.

> If you need context on the interfaces, pleases consider multicast and

Multicast and flows have a next-hop that points to multiple interfaces.
The incoming packet does not contain the list of outgoing interfaces.
Mcast has RPF which is done based on incoming interface (which the network
device knows for a given packet). So you match on mcast-address (S,G) +
incoming-interface and then decide (as part of nexthop) where all and how
(load-balance, multiple copies, etc) you want to send the packet.

Thanks
Nitin

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 15:22:00 -0400

Juergen:

Thanks for the high quality and pragmatic response.  Yes, I did mean UML
Class diagrams.  As the teens say "my bad".  

As to the tools and code generation:
During my days of writing protocol software or managing protocol software
writers, I found it often took 3+ rewrites to get efficient code after
working good.   If tools create inefficient code but working code - at least
a prototype to test against comes up quickly.  If tools improve the
prototype may get closer and the re-writes less. 

As to descending into detail with UML:  that's actually a plus for me.  The
purpose behind UML is to quicken the pace of the process from high level
agreement to DM.  We can standardize the high level and then use the UML to
provide quicken layers of agreement.  

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, April 30, 2014 1:49 PM
To: Susan Hares
Cc: 'Nitin Bahadur'; 'Joel Halpern Direct'; 'Mach Chen';
[email-masked]; [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

On Wed, Apr 30, 2014 at 10:49:21AM -0400, Susan Hares wrote:
 
> im-tree.  UML is best, but I'm not sure If I can it in the documents.  
> 5 pages of UML covers all the RIB models.  UML tools can create yang data

I assume people mean UML class diagrams when they say UML. That said, yes
tools can turn UML into other stuff. However, whether the result is 'nice'
or 'implementable are reasonable pain' is a different question (and I
understand that 'nice' and 'pain' have no clear definition). UML class
diagrams allow the representation of arbitrary relationships between
classes. If you have to turn this into a hierarchy for a protocol using a
hierarchical namespace, then tools most likely only create _a_ solution not
a _good_ solution.

If you believe tools do a good job translating IMs to DMs, you will likely
soon find that this is generally not the case and in order to make it work
better you will start to augment you IM with lots of additional detail for
the translator to do a reasonably good job, in which case your IM
deteriorates to some extend into a DM.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Apr 2014 21:40:08 +0200

> prototype may get closer and the re-writes less. 

But we are talking about standardizing data models we want to
interoperate. You can't apply iterative code development to this.
 
> provide quicken layers of agreement.  

As usual, the hard is finding agreement, not so much the format. A
format that people do not read carefully may help in the sense that
you get less reviews and thus you believe you were faster (but you
might have just moved the difficult parts of the agreement finding
process to a later stage). As such, a format that increases the
chances of getting a fair number of substantial reviews of key parties
should be the target.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 15:50:47 -0400

Nitin: 

I'm glad we are getting to the detail. I think our first disconnect is not
at the grammar level, but at the functional level. 

IMHO your RIB functionality is insufficient as it stands because it doesn't
contain the SRC-DST lookup using the packet + Meta data.  RIBs should be
able to match on the SRC-DST for all types of routes. 

I see we have a different view on the functions of look-ups.  This is a
terrific discussion on the RIB-Info functionality.  Let's try to decide on
this point, and then go back to grammar second.  Will that work for you? 

Thanks for your patience in clearly up where our assumptions were different.

Sue 

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 2:10 PM
To: Susan Hares; 'Mach Chen'; [email-masked]
Cc: [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

Hi Sue,

   Thanks for putting this down in detail. Now it¹s easier to explain what I
was trying to convey.

-----Original Message-----

>Problem: Your grammar does not handle source-destination form choice as 
>a generic form used by all of the interfaces.

>Confusion:  I am suggesting two tags <form-tag><route-type> and you 
>want see one tag for compilation.
>
>                          <mac-route> | <interface-route>) <route-type> 
>::= <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>
>
><form-tag> = <SRC-FORM><DST-FORM><SRC-DST FORM> Routing protocols would 
>have:  [rrr ff ttt]  r = reserved/0  ff = 0/1 (for src/dst), ttt = 
>type]
>

What the above grammar does is that it allows one to construct a match that
looks like:

[Nitin} This is obviously incorrect. That¹s the part I have been trying to
convey.
In the world of routing protocols, we have IANA registries that specify what
combination is legal. In the world of data-models, we can¹t depend on that.
So with the grammar above, how do you prevent a badly-written controller
from sending a match condition that looks like above (not that the
data-model will successfully compile this match conditionŠsince the rules
allow it)?

[Sue]:  What is obviously incorrect? 
I'm stating you can have source-destination possibilities on all of the
functions.  I think you are disagreeing on this point. 

>
>Each of these forms for matches could use the SRC and destination in 
>the filter.
>

[nitin] Match is always on an incoming packet. A packet does not have
embedded in it the dst-interface. So you cannot have a dst-interface as part
of the match condition.
 
[Sue]: Here is out disconnect.  Match is not just on packet, but a route
look-up with Meta Data with the meta data.  Even Commodity chips allow meta
data to be associated with the packet flows.  I see a RIB look-up as
including Meta data (incoming interface) and route contain outgoing
interface (even if it is *(any) interface). 

>This can be that the traffic flow comes in on interface1 and goes out 
>on interface 2 for all interfaces.  MPLS could but it can be 
>Do you agree/disagree have a potential of having source-destination for 
>most of these types?

[Nitin] I disagree that there is a potential of having a src-dst for most
types.
Src-dst is only possible ³in a match condition² for a route-type that has
src and dest information embedded in the packet.
IPv4/IPv6 & IEEE-MAC are the only possibilities.
For IEEE-MAC, there has been no use-case (requirement yet) to have SRC-DST
based routingŠ.so it wasn¹t included so far.

[Sue]:  For the MPLS and L2VPN MAC related work, the set of MPLS use cases I
co-authored had this in mind.  It is not an accepted use case, but it is a
published use case.  I suspect what I am really stating, is that SRC-DST is
useful for all nodes. Thank you for being patient while we wind through the
disconnect. 

> If you need context on the interfaces, pleases consider multicast and 

[Nitin]: Multicast and flows have a next-hop that points to multiple
interfaces.
[Sue]: It is possible to create routes where the interfaces are the key
information and the IP next hop is (*).  

[Nitin] The incoming packet does not contain the list of outgoing
interfaces.
[Sue]: This is correct, but as I have noted above I am allowing for META
data that would allow certain interfaces to be specified. For example, as a
security measure for a VPN, it would allow only routes coming in interfaces
1-3 and going out 2-5. The meta data would contain this information as part
of the routing match.   Did you have this restriction in mind?  Please see
the white-use-case draft for this. 

[Nitin]: Mcast has RPF which is done based on incoming interface (which the
network device knows for a given packet). So you match on mcast-address
(S,G) + incoming-interface and then decide (as part of nexthop) where all
and how (load-balance, multiple copies, etc) you want to send the packet.
[Sue]: yes, interface(meta data) + packet in multicast as I indicated up.
To nexthop (meta data + interfaces) on outgoing. 

Great response!  I see we are arguing about functionality.  Let's debate
this. 

My UML class drawings are very short, and they helped me understand what I
was missing in the functionality.

---

From: Nitin Bahadur <[email-masked]>
Date: Wed, 30 Apr 2014 13:28:00 -0700

>this point, and then go back to grammar second.  Will that work for you?

YupŠwe have a different view. Looking forward to see what views the rest
of WG has.

Thanks
Nitin

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 16:32:54 -0400

Juergen: 

I suggest the UML as an Informational model is quick and easy to read.  Most
generated prototypes can enforce interoperability you wish for.  If not, the
UML to code tool is just broken.  The steps are: 

UML--> Data Model (yang/forces) --> code    

I think the UML is readable. Please comment on my UML drawings that I sent
at the beginning of this post.  If you wish a power point of the UML so you
can edit it, I'll send one.  At the Yang step, Andy assures me it is
readable so debugging the tool should be useful.  I was answering the
performance issue question with the iterative code.  I think this does
provide what you require. 

Can you tell me where your experience states this is a misstep?

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, April 30, 2014 3:40 PM
To: Susan Hares
Cc: 'Nitin Bahadur'; 'Joel Halpern Direct'; 'Mach Chen';

On Wed, Apr 30, 2014 at 03:22:00PM -0400, Susan Hares wrote:
> Juergen:
> 
> Thanks for the high quality and pragmatic response.  Yes, I did mean 
> UML Class diagrams.  As the teens say "my bad".
> 
> During my days of writing protocol software or managing protocol 
> software writers, I found it often took 3+ rewrites to get efficient code
after
> prototype may get closer and the re-writes less.

But we are talking about standardizing data models we want to interoperate.
You can't apply iterative code development to this.
 
> As to descending into detail with UML:  that's actually a plus for me.  
> The purpose behind UML is to quicken the pace of the process from high 
> level agreement to DM.  We can standardize the high level and then use 
> the UML to provide quicken layers of agreement.

As usual, the hard is finding agreement, not so much the format. A format
that people do not read carefully may help in the sense that you get less
reviews and thus you believe you were faster (but you might have just moved
the difficult parts of the agreement finding process to a later stage). As
such, a format that increases the chances of getting a fair number of
substantial reviews of key parties should be the target.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 16:49:01 -0400

Nitin: 

To make the discussion it easier, can you release a new version of the
clean-up RBNF grammar?  Even a post of  your clean-up would help me not miss
something in our discussions. 

Sue 

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Wednesday, April 30, 2014 4:28 PM
To: Susan Hares; [email-masked]
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01

>
>IMHO your RIB functionality is insufficient as it stands because it 
>doesn't contain the SRC-DST lookup using the packet + Meta data.  RIBs 
>should be able to match on the SRC-DST for all types of routes.
>
>terrific discussion on the RIB-Info functionality.  Let's try to decide 
>on this point, and then go back to grammar second.  Will that work for you?

YupŠwe have a different view. Looking forward to see what views the rest of
WG has.

Thanks
Nitin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Apr 2014 23:32:32 +0200

> UML--> Data Model (yang/forces) --> code    

I believe that a tool that generates a meaningful YANG data model out
of a UML information model requires so many details in the UML model
that the UML model stops being an information model. A data model has
to be very clear about naming. If you use YANG, you need to transfer
an arbitrary graph of classes and their relationships into a tree.
The answer to the question what becomes a reference between branches
in a tree and what can be captured through nesting does not naturally
fall out of a UML class diagram. Perhaps I am overly pessimistic.

A key point of an information model is that it focusses on fundamental
concepts and that it on purpose leaves out details that are needed in
data models. So either your tool transforming UML class diagrams into
YANG has a second information source or you have to overload your UML
diagrams with details that turn your UML diagrams into a data model.
 
> provide what you require. 

I like to see the UML input and the YANG output or even better the
tool. I am happy to see the text I wrote above proven wrong.

> Can you tell me where your experience states this is a misstep?

See above. I have seen people who added lots of details to their UML
class diagrams in order to drive automation until the UML diagrams
filled walls and essentially lost their value of summarizing key
concepts.

/js

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 30 Apr 2014 19:50:30 -0400

Juergen:

<snip> 
I believe that a tool that generates a meaningful YANG data model out of a
UML information model requires so many details in the UML model that the UML
model stops being an information model. A data model has to be very clear
about naming. If you use YANG, you need to transfer an arbitrary graph of
classes and their relationships into a tree.
The answer to the question what becomes a reference between branches in a
tree and what can be captured through nesting does not naturally fall out of
a UML class diagram. Perhaps I am overly pessimistic.

A key point of an information model is that it focusses on fundamental
concepts and that it on purpose leaves out details that are needed in data
models. So either your tool transforming UML class diagrams into YANG has a
second information source or you have to overload your UML diagrams with
details that turn your UML diagrams into a data model.

[Sue-on]: Yes, I am focused on the depth of description.  Thank you for
mentioning it.  I am using the concept library of information models.  I'm
hoping you can just state this links to this UML diagram in the library, and
that details for a particular modular can be specified in that diagram.  If
there is 

 I thought that this was reasonable - to use one level of detail in one
diagram (so all could read), and a more detailed reference to the diagram.
I'm read and re-reading my tutorial book to see if there is any problem with
this in UML.  I'm not sure the official way to call this. If there isn't,
I'll have to invent it. 
[Sue-off] 
 
> I think the UML is readable. Please comment on my UML drawings that I 
> sent at the beginning of this post.  If you wish a power point of the 
> UML so you can edit it, I'll send one.
> At the Yang step, Andy assures me it is readable so debugging the tool 
> should be useful.  I was answering the performance issue question with 
> the iterative code.  I think this does provide what you require.

[Sue] I like to see the UML input and the YANG output or even better the
tool. I am happy to see the text I wrote above proven wrong.

> Can you tell me where your experience states this is a misstep?

See above. I have seen people who added lots of details to their UML class
diagrams in order to drive automation until the UML diagrams filled walls
and essentially lost their value of summarizing key concepts.
[Sue]:  Without levels of hierarchy or scoping, the tool is unworkable.  The
CAD/CAM guys learned to use scoping with diagrams - so would thing UML
should do the same thing. 

Thank you for your kind and very knowledge hints to help me. 

/js

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 30 Apr 2014 20:49:16 -0400

> to vendors, or something else?

Regardless of the data model and protocol, I believe we'll need something
like this for I2RS.  Section 3.2.1 of RFC 6536 covers properties that I
would suspect would be requirements for any such system.  While Joel is
correct that we're not to the point of worrying about the details yet until
we choose, I suspect that it's not too hard to read the remaining content of
section 3 in the context of somewhat more abstract protocol operations and
derive impacts on requirements.

-- Jeff