<wg chair hat off> If we just state, "Just use" - I'm happy with this as well. Sue
-----Original Message----- From: Mach Chen [mailto:[email protected]] Sent: Friday, December 04, 2015 1:14 AM To: Jeffrey (Zhaohui) Zhang; 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 It makes sense to me. Best regards, Mach > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:[email protected]] > Sent: Friday, December 04, 2015 11:52 AM > To: Susan Hares; Mach Chen; 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 > > 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
