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

From: Mach Chen <[email-masked]>
Date: Fri, 14 Feb 2014 03:12:16 +0000

Dear Authors,

I read the draft, here are some comments, hope it help.

The comments are mainly based on 01, but most of them apply to 02.

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. 

1.2 What's the <MPLS> and <IEEE_MAC> stands for here? The 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>

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>.

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?

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. 

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.

Best regards,
Mach

---

From: Nitin Bahadur <[email-masked]>
Date: Fri, 14 Feb 2014 13:54:31 -0800

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

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.

><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>

>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.

>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:

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).

>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

---

From: Mach Chen <[email-masked]>
Date: Sat, 15 Feb 2014 01:05:52 +0000

Hi Nitin,

Thanks for your prompt response!

I removed parts that we agree.

> >
> >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
> <ipv4-route> ::= <IPv4> (<destination-ipv4-address> | <source-ipv4-address> |
>                           <mac-route> | <interface-route>) <route-type> ::=
> <IPV4> | <IPV6> | <MPLS> | <IEEE_MAC> | <INTERFACE>

I am OK with either way.

> >               <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>
> 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).
> 
> 

OK.

> >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).

At present, protocol-type is the straightforward one, I am not sure the protocol peer address is needed in the rib, there needs a use case to justify it. Another attribute may be needed is the I2RS client identifier, since there will be multiple clients that may install route into the rib.

> >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.

OK.

> 
> 
> >
> >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.
> 

OK.

Thanks
Mach

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 18 Feb 2014 12:13:41 -0800

>> Another attribute may be needed is the I2RS client identifier, since
>>there will be multiple clients that may install route into the rib.

The client identifier should be a part of the I2RS data protocol, rather
than RIB model. Since the same client-id will be reusable across many
other things (not just RIB). I guess we will closely monitor the status of
the data protocol and can later figure out where to put the client-id. I
agree that the client-id needs to go somewhere.

Thanks
Nitin

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 25 Feb 2014 04:21:09 +0000

Have a question about RIB grammar

Based on the description
interface-list: This represents the list of interfaces associated
      with this routing instance.  The interface list helps constrain
      the boundaries of packet forwarding.  Packets coming on these
      interfaces are directly associated with the given routing
      instance.  The interface list contains a list of identifiers, with
      each identifier uniquely identifying an interface.
So based on this description, example grammar for Interface list is clear
   <interface-list> ::= (<INTERFACE_IDENTIFIER> ...)

but then  interface route has interface and interface identifier
   <interface-route> ::= <INTERFACE> <INTERFACE_IDENTIFIER>
Could you please explain the difference between <INTERFACE> and <INTERFACE_IDENTIFIER>?  In section 2.3, there is an ingress interface match condition, but from the document would presume that <INTERFACE_IDENTIFIER> would be enough to identify the ingress interface for match condition?

Thanks

Dean

On Feb 18, 2014, at 3:13 PM, Nitin Bahadur <[email-masked]> wrote:

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

---

From: Sriganesh Kini <[email-masked]>
Date: Wed, 26 Feb 2014 10:12:38 -0800

<INTERFACE> is just a type identifier for the route (similar to <MPLS>,
...).

Since the name <interface-route> should be self-explanatory for the purpose
of designing the data model, such type identifiers can be excluded from the
grammar without affecting its readability.

Sri

On Mon, Feb 24, 2014 at 8:21 PM, Dean Bogdanovic <[email-masked]> wrote:

> Could you please explain the difference between <INTERFACE> and
> <INTERFACE_IDENTIFIER>?  In section 2.3, there is an ingress interface
> match condition, but from the document would presume that
> <INTERFACE_IDENTIFIER> would be enough to identify the ingress interface
> for match condition?
>
> Thanks
>
> Dean
>