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

From: Alia Atlas <[email-masked]>
Date: Mon, 7 Oct 2013 01:05:11 -0400

I really really like how the discussion and explanation has shaped up in
this draft.

I'd love to see a bit more detail fleshing out the events/notification
section and some thought given to what different mechanisms make sense for
the information collection stream.  For instance, what types of filtering
or thresholding can be done by a client who wants to learn the RIB
information.

For the reading or notifications - is it possible to learn which protocol
has installed a particular route?  What types of filters beyond routing
instance, RIB, and match can be used for reading routes?

It would be useful to capture on the Installed flag whether that means a
fully confirmed route installed into all the relevant FIBs or whether it
means that the RIB manager has passed it down to the FIB manager for
installation?   I can see this being an event rather than being returned on
the write - but am happy to hear other ideas.

I understand completely the concerns about access for the I2RS client as
far as reading or writing RIBs.  I don't think that the solution is likely
to be access-lists configured on each network device - but rather something
tied into the authentication and authorization and associated scope of the
role that is verified by (I hope) an existing protocol.  One thing we do
have to decide as a WG is what level of detail the scope will have.  In the
context of this draft, pulling out essential the information model of the
permissions that would make sense would help clarify this and provide the
data needed for the read/write scope resolution.

Nit:  The multicast match is missing from the <match> in the BNF and from
Figure 2.  (Some of the later figures aren't labeled either).

For those who have read this far, I'd really like to get strong focus and
comments on this draft.  We have tight milestones and I still cling to some
hope of coming close to them.

Has anyone done compare/contrasts on what features are needed in a
data-modeling language for this info model?  Could we have a useful
conversation about how well different data-modeling languages work for this?

Regards,
Alia

---

From: Nitin Bahadur <[email-masked]>
Date: Thu, 10 Oct 2013 18:46:33 +0000

Hi Alia,

> I'd love to see a bit more detail fleshing out the events/notification section and some thought given to what different mechanisms make sense for the information collection stream.  For instance, what types of filtering or thresholding can be done by a client who wants to learn the RIB information.

I think a variety of filtering is possible. I can start creating an exhaustive list...but need more input from WG (esp from those who intend on using the RIB model from a RIB client) on what would be useful to them. Here are a few possibilities.

  *   Filter routes adds/deletes/updates based on:
     *   Route address family
     *   Route prefix (for IP)
     *   Unicast vs Multicast (IP)
  *   Filter lists of type "allow" and "exclude"

Thresholding is tricky, esp if the rib agent has to implement it. If someone wants to slow down the number of updates sent/recd per sec, the simplest way would be to set a small socket-buffer size on the TCP connection....
Adding logic in the rib agent to send only N updates per M seconds would complicate things.

> For the reading or notifications - is it possible to learn which protocol has installed a particular route?
> What types of filters beyond routing instance, RIB, and match can be used for reading routes?

Yes...there can be filter on protocol-type (yet to be defined). So you could filter routes on installed only by ISIS.
Learning who has installed a route in a particular RIB should be doable as well.

> Nit:  The multicast match is missing from the <match> in the BNF and from Figure 2.  (Some of the later figures aren't labeled either).

Fixed.

Thanks
Nitin

---

From: Lucy yong <[email-masked]>
Date: Thu, 10 Oct 2013 20:40:29 +0000

Here are my comments.

*         Why is the draft as informational not as a standard track? The text body defines RIB data and grammar, and related actions. Do they need to be standardized?

*         Regarding Rpf-check-interface, it only describes IP route and MPLS route cases. How about MAC routes, etc?  does it need to specifies each type route case or just give an example.

*         Text: The outermost IP header is decided by the network device whereas the MPLS header and GRE header are specified by the controller.  -end   IMO: outer IP source address is decided by network devices. outer destination address is decided by controller as well.

*         The description in Section 2.4.2. is for a specific solution. We should keep it in a general. There are different ways to do load distribution.

*         Regarding tunnel-encap, we should mention UDP encapsulation.  Nexthop chains may be in mpls-in-udp, gre-in-udp, etc.

*         Edit:  s/a inner/ an inner/, s/a MPLS/an MPLS/, s/a IP/an IP/

Lucy

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
Sent: Thursday, October 10, 2013 1:47 PM
To: Alia Atlas; [email-masked]
Subject: Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00

Hi Alia,

Fixed.

Thanks
Nitin

---

From: "Russ White" <[email-masked]>
Date: Fri, 11 Oct 2013 12:01:10 -0400

> I think a variety of filtering is possible. I can start creating an
exhaustive
> list.but need more input from WG (esp from those who intend on using the
> RIB model from a RIB client) on what would be useful to them. Here are a
> few possibilities.

Rather than trying to come up with every possible filter, though, why don't
we build an extensible infrastructure, and let use cases drive the filters
actually specified? We would need a base set, but making an exhaustive list
would, IMHO, be, well, err... exhausting.

:-)

Russ

---

From: Joe Marcus Clarke <[email-masked]>
Date: Fri, 11 Oct 2013 12:12:37 -0400

On 10/10/13 2:46 PM, Nitin Bahadur wrote:
> Hi Alia,
>
>  > I'd love to see a bit more detail fleshing out the
> events/notification section and some thought given to what different
> mechanisms make sense for the information collection stream.  For
> instance, what types of filtering or thresholding can be done by a
> client who wants to learn the RIB information.
>
> exhaustive list…but need more input from WG (esp from those who intend
> on using the RIB model from a RIB client) on what would be useful to
> them. Here are a few possibilities.
>
>       o Route address family
>       o Route prefix (for IP)
>       o Unicast vs Multicast (IP)
> Thresholding is tricky, esp if the rib agent has to implement it. If
> someone wants to slow down the number of updates sent/recd per sec, the
> simplest way would be to set a small socket-buffer size on the TCP
> connection….
> Yes…there can be filter on protocol-type (yet to be defined). So you
> could filter routes on installed only by ISIS.

I think this is a good base set of filter criteria.  I would also add 
VRF (or maybe VRF is assumed based on the RIB instance delivering the 
event).  To summarize:

* Address family
* Prefix/prefix len
* Unicast/multicast
* Protocol
* VRF

And filter based on add/remove/update and include/exclude.  Should we 
discuss what kind of route attributes an event would carry to the 
consumer?  At a minimum, I think events should contain everything above 
(including event type) as well as:

* Next hop interface
* Next hop gateway
* Time of route add/remove/update
* Metric
* Tag

And to Russ' point, make things extensible for adding custom, per-vendor 
or per-protocol attributes as well.

Joe

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

-- 
Joe Marcus Clarke, CCIE #5384,         |          |
SCJP, SCSA, SCNA, SCSECA, VCP        |||||      |||||
Distinguished Services Engineer ..:|||||||||::|||||||||:..
Phone: +1 (919) 392-2867         c i s c o  S y s t e m s
Email: [email-masked]

----------------------------------------------------------------------------

---

From: Edward Crabbe <[email-masked]>
Date: Fri, 11 Oct 2013 12:08:50 -0700

Couldn't agree more ^_^

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2013 15:17:33 -0400

I was looking for a reasonable base set to put in there.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2013 16:06:02 -0400

Sorry - to be even clearer, I think that the list that Nitin and Joe
suggested is a great start and sufficient until and unless we hear
use-cases where that isn't so.

I'd like to amplify on what "Tag" is meant - since I don't, off-hand,
recall seeing it in the RIB Info model...

Alia

On Fri, Oct 11, 2013 at 12:12 PM, Joe Marcus Clarke <[email-masked]>wrote:

>>  For the reading or notifications - is it possible to learn which
>>> protocol has installed a particular route?
>>>
> I think this is a good base set of filter criteria.  I would also add VRF
> (or maybe VRF is assumed based on the RIB instance delivering the event).
>  To summarize:
>
> * Address family
> * Prefix/prefix len
> * Unicast/multicast
> * Protocol
> * VRF
>
> discuss what kind of route attributes an event would carry to the consumer?
>  At a minimum, I think events should contain everything above (including
> event type) as well as:
>
> * Next hop interface
> * Next hop gateway
>>  Nit:  The multicast match is missing from the <match> in the BNF and
>>> from Figure 2.  (Some of the later figures aren't labeled either).
>>>
>>
>> Fixed.
>>
>> Thanks
>> Nitin
>>
>>
>> ______________________________**_________________
>> i2rs mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs>
>>
>>
>
> --
> ------------------------------**------------------------------**
> ----------------
>

---

From: "Russ White" <[email-masked]>
Date: Fri, 11 Oct 2013 17:07:27 -0400

> I was looking for a reasonable base set to put in there.

Deny or permit anything in the TCP, UDP, or IP header, is probably a good
start (?).

:-)

Russ

---

From: Alia Atlas <[email-masked]>
Date: Fri, 11 Oct 2013 17:19:03 -0400

> Deny or permit anything in the TCP, UDP, or IP header, is probably a good

In regards to the events and notifications coming from the RIB Manager???
Deny or permit anything in the TCP, UDP or IP header is much more
policy-based routing - and I agree that we need someone to write up a
reasonable and necessary set of fields to be a PBR model to extend the RIB
info model :-)

Alia

---

From: Joe Marcus Clarke <[email-masked]>
Date: Sat, 12 Oct 2013 13:27:02 -0400

> recall seeing it in the RIB Info model...

Sorry, you're right.  That is also an overloaded term.  I was suggesting 
a parameter for the route that might tie this back to a particular 
client or instance.  This was to address what Nitin said in his last 
sentence:

"Learning who has installed a route in a particular RIB should be doable 
as well."

If we have some kind of tag identifier, that might be one way of doing 
it.  But it would need more definition.

Joe

>
> Alia
>
>
> On Fri, Oct 11, 2013 at 12:12 PM, Joe Marcus Clarke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         Adding logic in the rib agent to send only N updates per M
>         seconds would
>         complicate things.
>
>             For the reading or notifications - is it possible to learn
>             which protocol has installed a particular route?
>
>           > What types of filters beyond routing instance, RIB, and
>         match can be
>         used for reading routes?
>
>         Learning who has installed a route in a particular RIB should be
>         doable
>         as well.
>
>
>     I think this is a good base set of filter criteria.  I would also
>     add VRF (or maybe VRF is assumed based on the RIB instance
>     delivering the event).  To summarize:
>
>     * Address family
>     * Prefix/prefix len
>     * Unicast/multicast
>     * Protocol
>     * VRF
>
>     And filter based on add/remove/update and include/exclude.  Should
>     we discuss what kind of route attributes an event would carry to the
>     consumer?  At a minimum, I think events should contain everything
>     above (including event type) as well as:
>
>     * Next hop interface
>     * Next hop gateway
>     And to Russ' point, make things extensible for adding custom,
>     per-vendor or per-protocol attributes as well.
>
>     Joe
>
>
>             Nit:  The multicast match is missing from the <match> in the
>             BNF and from Figure 2.  (Some of the later figures aren't
>             labeled either).
>
>
>         Fixed.
>
>         Thanks
>         Nitin
>
>
>         _________________________________________________
>         i2rs mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/i2rs
>         <https://www.ietf.org/mailman/listinfo/i2rs>
>
>
>
>     --
>     Phone: +1 (919) 392-2867 <tel:%2B1%20%28919%29%20392-2867>         c
>     i s c o  S y s t e m s
>     Email: [email-masked] <mailto:[email-masked]>
>
>     ------------------------------__------------------------------__----------------
>
>
>
>