<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 protected]> wrote:

> 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 protected]>
> wrote:
>
> >>>
> >>>>
> >>>> 3. Section 6
> >>>> <route> ::= <match> <nexthop-list>
> >>>>              [<route-attributes>]
> >>>>              [<route-vendor-attributes>]
> >>>
> >
> >>> 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
> >
> >
> > _______________________________________________
> > i2rs mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/i2rs
> >
> >
>
>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to