-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Susan Hares
Sent: Thursday, December 03, 2015 10:02 PM
To: 'Mach Chen' <[email protected]>; 'Linda Dunbar'
<[email protected]>; 'Joel M. Halpern' <[email protected]>;
'Loa Andersson' <[email protected]>; 'Acee Lindem (acee)' <[email protected]>;
'Alia Atlas' <[email protected]>
Cc: 'Jeffrey Haas' <[email protected]>; [email protected]; 'Jeff Tantsura'
<[email protected]>
Subject: Re: [i2rs] FW: I-D Action:
draft-ietf-i2rs-rib-data-model-04.txt
Mach:
I agree that the IM model did a great job of focusing on the use cases
and motivation. However, it appears we have two cases:
1) some people think the tunnel encap creates the tunnel if not
established,
2) some people (like me) thought we were only using pre-established
tunnels.
3) some people thought (like me) encap/decapsulation created a tunnel
Since there is a debate among knowledgeable people, we need to go through
the use cases and clearly state what is happening per use cases. And
then
go through this and make it clear at each step.
Perhaps you and other IM/DM can send me offline your view on each of
the use cases? We can come back to the mail list with a proposal.
Sue
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Mach Chen
Sent: Thursday, December 03, 2015 9:13 PM
To: Susan Hares; Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson';
'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email protected]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action:
draft-ietf-i2rs-rib-data-model-04.txt
Hi Sue,
Regarding a, for those non-pre-established tunnels, as Joel said, it
could be considered that the tunnel-encap "creates" the tunnels. But
someone can also thinks that we just use those tunnels although they
are not created in advance (and actually no need to be created at
all). For those pre-established tunnels, the tunnel-encap/decap really
does not create the tunnels.
So, I think the key point should not be about whether the tunnel-
encap/decap creates a tunnel, we should focus on the use cases. I
think that the IM model did a great job on describing the use cases
that are the motivations of the design of the model.
Best regards,
Mach
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Susan Hares
Sent: Friday, December 04, 2015 9:31 AM
To: Linda Dunbar; 'Joel M. Halpern'; 'Loa Andersson'; 'Acee Lindem
(acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email protected]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action:
draft-ietf-i2rs-rib-data-model-04.txt
Joel, Linda, Loa, and Acee:
<wg chair hat off>
You are right - the I2RS initial work considered the encapsulation
differently than the decapsulation.
Do you think I2RS RIB needs to:
a) create the tunnel if it is not there,
b) specification the encapsulation (currently specified) linked to a
tunnel interface,
c) specify the decapsulation (somewhat specified) linked to a tunnel
interface,
d) some of the above (a-c),
e) all of a-c?
<wg chair hat on>
Acee - if this is the whole issue you were pointing to rather than
just want the I2RS RIB to link to specific tunnel creations, then I
really misunderstood your post. For that, I apologize I
misunderstood your post. I want to thank you for raising the issue
now - rather than
in
the next step of the approval process.
<wg chair hat off>
Sue
-----Original Message-----
From: Linda Dunbar [mailto:[email protected]]
Sent: Thursday, December 03, 2015 5:21 PM
To: Joel M. Halpern; Susan Hares; 'Loa Andersson'; 'Acee Lindem
(acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email protected]; 'Jeff Tantsura'
Subject: RE: [i2rs] FW: I-D Action:
draft-ietf-i2rs-rib-data-model-04.txt
I tend to agree with what Joel said.
It worth noting that
1. there is "Pre-established Tunnel" as in LSPs or PW and 2. there
is "Ingress node encapsulating outer address for overlay
environment" as in TRILL or NVO3.
Do we call both "tunnels"? or only the first one?
Linda
-----Original Message-----
From: i2rs [mailto:[email protected]] On Behalf Of Joel M.
Halpern
Sent: Thursday, December 03, 2015 12:13 PM
To: Susan Hares; 'Loa Andersson'; 'Acee Lindem (acee)'; 'Alia Atlas'
Cc: 'Jeffrey Haas'; [email protected]; 'Jeff Tantsura'
Subject: Re: [i2rs] FW: I-D Action:
draft-ietf-i2rs-rib-data-model-04.txt
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.
