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 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
