Hi Acee, <snipped some text>
> >> Do you intend to put all these packet headers in the JUNOS RIB? > > > >Not sure if I can comment on specific implementation plan yet, but I > >would push for allowing that (not that we'd deprecate the interface based > >method - just use whatever is the most appropriate in different > >scenarios) :-) Yes we have done that for some, and are doing more. > >It could be asked the other way as well - since we've already have the > >RIB model, why not just use it instead of introducing another model :-) > > > Well, right now the model is extremely flexible as there is nothing in it > to prevent mixing RIB entry types and next-hops types of any variety. > Clearly, this will not be implemented or deployed. The ILM is a well-known > abstraction and it should be its own programmable model. JUNOS does implement ILM as a RIB. It's not that the model is done that way just because we implemented it that way - logically ILM is no different from a RIB. The mapping between a RIB based model and an ILM based implementation should be straightforward so it makes sense to model it that way? > >While Chris' text proposes not to include other decap NHs in the base > >model, the only reason is that for those other tunnels we don't yet have > >a good match condition in a RIB (we'd need to match a lot more fields, > >not just a label or destination address). Other than that, there is no > >real difference between an mpls decap nh and a vxlan decap nh, at least > >conceptually. > > > >In the future or in a private augmentation, one may add some additional > >match conditions to a RIB and then it is all set with the same > >RIB/route/nh framework. Even if we/someone do not use RIB for that > >purpose, it allows the same NH model to be used with either RIB based > >implementation or else. > > Maybe all these encap/decap/NH-chaining features should go into a separate > augmentation in a separate draft. To me, the currently defined tunnel encaps NHs, the reduced decap NH (just mpls), and NH-chaining are integral parts of the RIB model and they address many prevailing services. The concepts are not convoluted, and there are major implementations of the tables, routes, and NHs based on the concepts. Therefore, I think it's reasonable to keep them in the base model? Thanks. Jeffrey > > Acee > > > > > >Jeffrey > > > >> > >> Thanks, > >> Acee > >> > >> > >> > > >> >Jeffrey > >> > > >> >> > >> >> 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 > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
