Since the logical tunnel interface provides the tunnel capabilities in the traditional manner, I don’t see the need for the tunnel encap specification by precise specification of the packet headers. I know it is a feature, but does anyone plan to support it?
I'd keep the ILM (Incoming Label Map) as a separate model rather than attempting to model it as a RIB. An label to be imposed on unlabeled traffic can be specified in the RIB (See RFC 3031 for details). I don’t even understand how the tunnel decap is done? Are you trying to match on a packet based on dest or source and then decap? Is anyone going to implement anything like this? On 12/4/15, 5:52 PM, "Chris Bowers" <[email protected]> wrote: >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
