Subject: [i2rs] RIB Model draft

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 13 Sep 2013 08:19:11 -0400

I support adoption of this draft.

I do have some questions, brought to my attention when some of my folks 
read the draft.

Given that metrics are not comparable between routing protocols, or even 
between distinct instances of routing protocols, why are the metrics in 
the general RIB model instead of the protocol specific models?
Similarly, why is AS Path in this model, rather than in the BGP model? 
Whether the decision is implemented in BGP or a common RIB model would 
seem implementation specific, but from a model perspective it seems to 
be a BGP-specific property rather than a generic RIB property.

The load balancing attributes seem to reflect a particular 
implementation strategy.  While a not unreasonable strategy, the 
modeling seems pretty implementation specific.  This applies to both the 
specifics of load balance weight and the interaction of that weight with 
protection preference.

Having nodecrementTTL has a general nexthop attribute seems a mistake. 
In fact, having a next hop with no decrement seems very dangerous, since 
one could have a looping tunnel chain with no decrementing.  Is this 
really something we want in the model?  (I can't stop someone from doing 
it in an implementation.)

While the model should permit handling the TTL propagation into and out 
of tunnels, it should not mandate support for specific modes.  How do we 
indicate that support for things like the NO_PROPAGATE_TTL flag is 
optional, or conversely always set?

Minor: I presume that the cardinality of 0 is allowed in the 
relationship between route and nexthop-list to reflect incomplete route 
entries?  If so, shouldn't the text say so?

Nit: figure 2 should include multicast.

Yours,
Joel

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 13 Sep 2013 14:34:48 -0400

Nitin: 

Like Joel, I support the adoption of the draft.  It is a better starting
place than the previous draft. 

I would like suggest you need to consider Joel's comments and Russ'
comments. 

Here's a few things that can hit problems in the draft:

1) Why is the BGP route distinguisher specified on page 7? Why AS Path? 
    This is BGP specific.   A virtual private VPN ID - may be Ok, but
linking it to the BGP identifier may bring problematic results. I ack Joel's
comment below on the need to make it generic instead of protocol specific. 

2) What happens if you want to change nexthop [10] for prefix 10.2.0/16 as
part of the RIB change?  Seems to be something you'd want to be able do., 
Can you? 

3) I agree with Joel's comment below on load balancing.  You either need to
make it generic or include all variants of load balancing. 

4) I agree with Joel your TTL specification to/from tunnel needs tightening.
If you want to support it, I think it should be a "may" support not MUST. 

5) Can you tie security values as an attribute to being able to set/clear
FIB entries? 
Your note "reason - not authorized begs this question p. 16. Your protection
list on p. 21 suggest there is a preference. Is the preference a value or is
it a reference.  

6) Some Forwarding Engines could allow your next-hop list to be an index id
#. 
Can you provide an ID number for reference for your next hop lists?

Editorial / Information 
1) Would you look at the form and syntax that the netmod yang modules are
using to specify information trees?  If you think you are using the same
structure, please tell me why.  If you are not using the same structure, why
not? 
 
2) Is security a tree structure or a value?  Your protection list seems to
be a value.  Is this meant to be a value or reference (p. 21) 

3) Does netmod/yang models do a better job of nexhop list presentation? 

This is a good start.  I hope will see more revisions soon. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel
M. Halpern
Sent: Friday, September 13, 2013 8:19 AM
To: [email-masked]
Subject: [i2rs] RIB Model draft

I do have some questions, brought to my attention when some of my folks read
the draft.

Given that metrics are not comparable between routing protocols, or even
between distinct instances of routing protocols, why are the metrics in the
general RIB model instead of the protocol specific models?
Similarly, why is AS Path in this model, rather than in the BGP model? 
Whether the decision is implemented in BGP or a common RIB model would seem
implementation specific, but from a model perspective it seems to be a
BGP-specific property rather than a generic RIB property.

The load balancing attributes seem to reflect a particular implementation
strategy.  While a not unreasonable strategy, the modeling seems pretty
implementation specific.  This applies to both the specifics of load balance
weight and the interaction of that weight with protection preference.

Having nodecrementTTL has a general nexthop attribute seems a mistake. 
In fact, having a next hop with no decrement seems very dangerous, since one
could have a looping tunnel chain with no decrementing.  Is this really
something we want in the model?  (I can't stop someone from doing it in an
implementation.)

While the model should permit handling the TTL propagation into and out of
tunnels, it should not mandate support for specific modes.  How do we
indicate that support for things like the NO_PROPAGATE_TTL flag is optional,
or conversely always set?

Minor: I presume that the cardinality of 0 is allowed in the relationship
between route and nexthop-list to reflect incomplete route entries?  If so,
shouldn't the text say so?

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