Hi Jeffrey, On 12/9/15, 8:27 AM, "Jeffrey (Zhaohui) Zhang" <[email protected]> wrote:
>Hi Acee, > >> -----Original Message----- >> From: Acee Lindem (acee) [mailto:[email protected]] >> Sent: Wednesday, December 09, 2015 7:43 AM >> To: Jeffrey (Zhaohui) Zhang <[email protected]>; Chris Bowers >> <[email protected]>; [email protected]; Linda Dunbar >> <[email protected]>; Susan Hares <[email protected]>; 'Joel M. >> Halpern' <[email protected]>; 'Loa Andersson' <[email protected]>; 'Alia >>Atlas' >> <[email protected]> >> Cc: 'Jeffrey Haas' <[email protected]>; 'Jeff Tantsura' >> <[email protected]> >> Subject: Re: [i2rs] FW: I-D Action: >>draft-ietf-i2rs-rib-data-model-04.txt >> >> Hi Jeffrey, >> >> On 12/9/15, 7:26 AM, "Jeffrey (Zhaohui) Zhang" <[email protected]> >>wrote: >> >> >Hi Acee, >> > >> >> -----Original Message----- >> >> From: i2rs [mailto:[email protected]] On Behalf Of Acee Lindem >> >>(acee) >> >> Sent: Tuesday, December 08, 2015 8:42 PM >> >> To: Chris Bowers <[email protected]>; [email protected]; Linda Dunbar >> >> <[email protected]>; Susan Hares <[email protected]>; 'Joel M. >> >> Halpern' <[email protected]>; 'Loa Andersson' <[email protected]>; 'Alia >> >>Atlas' >> >> <[email protected]> >> >> Cc: 'Jeffrey Haas' <[email protected]>; 'Jeff Tantsura' >> >> <[email protected]> >> >> Subject: Re: [i2rs] FW: I-D Action: >> >>draft-ietf-i2rs-rib-data-model-04.txt >> >> >> >> 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? >> > >> >Logical tunnel interface is ONE way to do it, but it may be too much to >> >require an interface for every label stack to be imposed, e.g. in case >>of >> >SR. >> >> I agree for MPLS. I think it is fine to impose label(s) for Next-Hop >>Label >> Forwarding Entries (NHLFEs). I’m using RFC 3031 terminology. It is >> precisely programming the tunnel packet headers that I don’t feel >>belongs >> in the base RIB (especially when a very small but vocal minority is >> advocating that these constructs should be added to the base NETMOD >> ietf-routing draft). >> >> 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) :-) > >> >> >> > >> >> >> >> 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). >> > >> >ILM is essentially/actually a RIB where the match condition is just a >>/20 >> >label value, right? >> >> I guess you could view it this way but why not just use the existing ILM >> abstraction (see RFC 3031). > >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. > >> >> > >> >> >> >> 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? >> > >> >Chris text below proposes to only define mpls decap in this model. In >> >this case, the match is based on a label and the nexthop is decap, to >>pop >> >the label and send it to a routing table (e.g., a route lookup in >>another >> >table like in vpn case) or egress interface (which could be a logical >> >tunnel egress interface that is associated with a routing instance >>table). >> >> I still don’t think we should have a separate model for the ILM >>consistent >> with the model in every MPLS implementation. > >"think" of "don't think"? Yeah - this is a typo. I meant “think”. > >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. 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
