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 protected]
https://www.ietf.org/mailman/listinfo/i2rs
