I think we can just state that the model only intends to use tunnels. As the name suggests, "encap nexthop" only put on the encapsulation for transmitting the packets, just like putting on an Ethernet header.
Jeffrey > -----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. 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 > > > > _______________________________________________ > > i2rs mailing list > > [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 _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
