I2RS-WG and draft authors, I'd like to suggest the following text as a starting point to explain what the RIB data model does and does not cover with respect to tunnel encap and decap and some rationale for those choices.
---------------------- The current model allows one to program several types of tunnel encapsulation as nexthop-chains in the RIB. The current model supports encapsulation for MPLS, IP-in-IP, GRE, NVGRE, and VXLAN. One will note however that for tunnel decapsulation, only MPLS is supported. The rationale for this disparity is described below. Programming tunnel encapsulations in the RIB can be modeled well using nexthop-chains. In general, programming arbitrary forms of tunnel decapsulation in the RIB requires additional constructs beyond what is in the current model. The current data model does include one form of tunnel decapsulation, which is popping a single MPLS label. Popping a single MPLS label can be handled using an mpls-route match with an mpls tunnel-decap-nexthop and a nexthop-chain entry. Making this exception allows the model to cover important additional use cases, without increasing the complexity of this model. This data model also supports the use of logical tunnel interfaces as both egress and ingress interfaces. An egress logical tunnel interface can be used as a next-hop using egress-interface-nexthop in nexthop-base. Specific forwarding behavior for a particular ingress logical tunnel interface can be specified using an interface-route route match condition. This data model does not attempt to model the creation or deletion of logical tunnel interfaces. This model only uses logical tunnel interfaces that have been created by other mechanisms. Logical tunnel interface creation could involve a different YANG model, or it could involve some other mechanism unrelated to NETCONF, but that is not covered in this draft. ----------------------- Thanks, Chris -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Linda Dunbar Sent: Friday, December 04, 2015 10:51 AM To: Susan Hares <[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 IMHO, All a-c should be included. But it is better to have different names for a) and b). Linda -----Original Message----- From: Susan Hares [mailto:[email protected]] Sent: Thursday, December 03, 2015 7:31 PM 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
