Alia Atlas <[email protected]> writes:
> I have a few belated comments on the proposed charter, from what is today
> at https://datatracker.ietf.org/doc/charter-ietf-i2rs/, - as follows:
> " A routing system is all or part of a routing network. A part of a
> routing network may be a single router or a collection of
> routers. The routing system may be further divided to be an
> interface over which data traffic is forwarded, or a collection of
> such interfaces. The routing system also includes the control plane
> protocols that operate the routers."
I also find the above text unclear/confusing. Alia and I had an
offline exchange, which resulted in the following suggestion:
In a network, the routing system is the collection of entities,
protocols and processes that collectively build the forwarding
tables that are exported into the entities that constitute the
network's fowarding plane.
This attempts to say what the "routing system" in general terms while
also being clear about the separation of the data/forwarding plane
from the routing system. I2RS is presumably focussed on the latter.
I also don't think its helpful to talk about "The routing system may
be further divided to be an interface over which data traffic is
forwarded". That doesn't seem accurate, as network interfaces
typically just process packets, and I have a hard time seeing a single
interface being considered a "routing system".
> The second paragraph starts with:
> "I2RS facilitates real-time or event driven interaction with the
> routing system through a collection of control or management
> interfaces."
> While the type of interface is, I think, clear and beaten to death,
> I'd like to jump further on it by suggesting adding "protocol-based"
> to the list of possible descriptors. That would make it:
> "I2RS facilitates real-time or event driven interaction with the
> routing system through a collection of control or management
> protocol-based interfaces."
I'm OK with this change, but the bigger question I have when reading
the charter (at a general level), is how this "management interface"
differs from what we already have today. E.g., config files. I suspect
one answer is "you can't do what we want to do through the existing
config file mechanisms", but that's only partly helpful and begs the
question of just what is something this effort is intended to do that
can't already be done today. The charter itself doesn't say anything
like that. It's just silent about why what I2RS is trying to do can't
be done today. Indeed, there is no hint at all about how this might be
done (and the BOF had lots of questions along the lines of "why can't
you use <insert favorite protocol> to do this today?"
I'm not sure what to suggest here, but my own sense is that an outside
reader looking at this charter will have a hard time understanding
just what the scope of this effort is and what problem it is trying to
solve.
Thomas
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
