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 protected]] Sent: Wednesday, April 30, 2014 10:02 AM To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; [email protected] Cc: [email protected] 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) * 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 On 4/30/14, 9:53 AM, Susan Hares wrote: > 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 protected]] > Sent: Wednesday, April 30, 2014 9:39 AM > To: Susan Hares; 'Nitin Bahadur'; 'Mach Chen'; [email protected] > Cc: [email protected] > Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 > > 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 > > On 4/30/14, 7:26 AM, Susan Hares wrote: >> 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 protected]] >> Sent: Tuesday, April 29, 2014 10:20 AM >> To: Nitin Bahadur; Susan Hares; 'Mach Chen'; [email protected] >> Cc: [email protected] >> 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: >>> Hi Sue, >>> >>>> >>>> >>>> >>>>> 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] >>>> >>>> [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. >>> >>> 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. >>> >>> >>>> >>>> The <ip-route-type> will need to be associated specifically with >>>> <ipv4-route> and <ipv6-route>. >>>> >>>> [Sue]: yes, it could. With the rt-form and the rib-family type, >>>> perhaps we can remove the rt-type. >>>> [snip] >>> >>> 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... >>> >>> >>>> >>>>> 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? >>>> >>>> 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? >>>> >>>> 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. >>>> We could put this on the next hop. >>> >>> LOAD_BALANCE_WEIGHT is the flag on the next-hop that is used to >>> indicate ECMP/load-balancing. >>> >>> >>> >>> Thanks >>> Nitin >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
