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? > >> >> 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). > >> >> 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. 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
