Sue, I think it is fine - a bit on the underspecified side, but will wo9rk.
/Loa On 2015-12-04 20:49, Susan Hares wrote:
WG: Does anyone disagree with just "use"? Sue -----Original Message----- From: Loa Andersson [mailto:[email protected]] Sent: Friday, December 04, 2015 4:00 AM To: Mach Chen; Jeffrey (Zhaohui) Zhang; Susan Hares; Linda Dunbar; 'Joel M. Halpern'; '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 Folks, Yes agree - maybe "use existing tunnels" ? /Loa On 2015-12-04 14:13, Mach Chen wrote: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 gothroughthe 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 thanin 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 equivalentto 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 doesnot 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 beingcreated.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.Myunderstanding of the WG Agreement (early 2015) is that we would keep the RIM IM in sync with the for the first revision of the I2RSRIB.(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 totheinterface 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 ofRIBs).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 intentionis.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
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
