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
