I wonder if part of the problem here is the difference between the
ingress and egress sides of tunnels, and the various degrees of
dynamicity that tunnels support.
On the side where a packet is injected into a tunnel (ingress), almost
the only state one needs is the encapsulation state. So there is
tendency to view the creation of this encapsulation state as equivalent
to the creation of a tunnel.
And for the sending end of a unidirectional tunnel, it is.
In that sense, I think the RIB model can (whether intended or not)
"create" a tunnel.
However, decapsulation state (on the egress side) frequently requires
more state, that is note described by such RIB entries. So this aspects
tends to lead to the conclusion that creating RIB entries does not
create tunnels.
And if one is thinking in terms of bi-directional tunnels (common for
some technologies, uncommon for others), one tends to want to configure
the two aspects together. Which does not match what we are doing with
the RIB model handling of tunnel encapsulation.
Trying to discuss all of this under the rubrik of "tunnel creation"
tends to induce confusion.
Yours,
Joel
On 12/3/15 12:42 PM, Susan Hares wrote:
Loa:
<WG chair hat on>
Thank you for your note. The rudimentary analysis was incorrect. The
I2RS RIB Information Model (RIB IM) and RIB Data Model (RIB DM) is a
pair of documents that explain the I2RS RIB. The authors of these models
will need to improve the text to indicate tunnels are not being created.
Since RIB IM has passed WG LC, anyone wishes to propose that the RIB
IM/DM create tunnels should send me an indication they wish to create
such a proposal by 10/9/2015. Otherwise, we will start the WG LC the
RIB IM and RIB DM have improved their text to indicate tunnels are not
being created, only used).
Sue
*Details: *
The RIB Info Model(IM)/RIB Data Model(DM) is a pair of documents. My
understanding of the WG Agreement (early 2015) is that we would keep the
RIM IM in sync with the for the first revision of the I2RS RIB.
(Unless the AD for I2RS (Alia) provides me with the feedback these
documents should merge).
The actions in the I2RS RIB are add/delete RIB, add/delete/update route,
and add/delete nexthop. The I2RS RIB does not provide an add/delete
tunnel.
My understanding of the WG agreement which is distilled in the
draft-ietf-i2rs-rib-info-model-08.txt, is that the I2RS data models are
not creating tunnels. The I2RS data models are referring to tunnels
which are created by other "hard" or "soft" provisioning. My
recollection is that the WG felt other WG groups (such as rtgwg and
MPLS) where charter to provision these models. This is similar to the
interface yang creation. Interface configuration is created by the
interfaces yang module.
<WG Chair hat off>
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Loa Andersson
Sent: Thursday, December 03, 2015 11:34 AM
To: Acee Lindem (acee); Alia Atlas
Cc: Jeffrey Haas; [email protected]; Susan Hares; Jeff Tantsura
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt
Folks,
On 2015-11-25 01:19, Acee Lindem (acee) wrote:
<snip>
There is a non-converged discussion going on on draft-ietf-i2rs-
rib-data-model, the key statement seems to be:
>
> I believe the intention of the model is clearly to dynamically create
> the tunnels.
>
<snip>
I think that was is going on is (something like) this:
The authors intend to create a model that can be used to add, remove and
find information about the routes in the RIB (read series of RIBs).
Acee see is that adding this type of information to the RIB may very
well be used create (add) tunnels. After all the information manipulated
in both cases are very much the same.
If this very rudimentary analysis is correct, it should not be
impossible to add text to the document explaining what the intention is.
On one had I don't think it is motivated to not allow what the model is
intended for, on the other hand it should be perfectly what the
intention is (and what is is not).
/Loa
_______________________________________________
i2rs mailing list
[email protected] <mailto:[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
