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

From: Nitin Bahadur <[email-masked]>
Date: Mon, 28 Apr 2014 17:01:57 -0700

Hi Dean,

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

The <INTERFACE> was supposed to be a reference to the route-type. I¹ve
removed that from the latest (yet to be published) revision, wherein there
is a <route-type> in the <match> and
<interface-route> ::= <INTERFACE_IDENTIFIER>

Hope that brings more clarity.

Thanks
Nitin

---

From: Sue Hares <[email-masked]>
Date: Tue, 29 Apr 2014 18:43:22 -0400

Nitin:

I'm offline for 2 hours.  If you could take a peak at the  list I have the revised grammar in section 6.1.  And the yang module in the 6.3.  Of course, I will respond later this pm.  Sue

Sue

Sent via the Samsung GALAXY S®4, an AT&T 4G LTE smartphone

-------- Original message --------
From: Nitin Bahadur <[email-masked]> 
Date:04/29/2014  6:09 PM  (GMT-05:00) 
To: Susan Hares <[email-masked]>,'Mach Chen' <[email-masked]>,[email-masked] 
Cc: [email-masked] 
Subject: Re: [i2rs] Some comments on draft-ietf-i2rs-rib-info-model-01 

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

Unfortunately this is not our typical TLV, sub-TLV definitions specified
in IANA registryusing 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 tooltbd).

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