<no-hat> >From my perspective, adding encap for a next-hop in the RIB makes sense. >From one perspective, this is just putting, for instance, an MPLS label on. However, the RIB supports using additional higher-level abstractions. So - the RIB might use an interface that is to a tunnel - but the RIB may also have a next-hop that indicates adding the encap associated with an LSP or a tunnel. This allows the RIB's next-hop to stay the same when the LSP or tunnel changes.
I don't see the same rationale for decap. I'm most familiar with MPLS - where the label has an operation that is popping or swapping. For VXLAN or GRE, the outer dest IP address would indicate the router and thus be decapsulated. I see the role of the RIB as specifying what packets should go out what interface with appropriate encaps. It's not creating the tunnel but merely putting packet(s) into the tunnel (or LSP or MPLS label stack) at the desired level of abstraction. The discussion about decapsulation feels much more to me like it is creating the tunnel. Obviously, I'm happy to listen to other perspectives. Regards, Alia </no-hat> On Wed, Nov 18, 2015 at 3:36 AM, Mach Chen <[email protected]> wrote: > Indeed, I agree with Jeffery here. > > I'd suggest we keep the current model as is and address the vxlan/nvgre > decap in other places. > > Best regards, > Mach > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:[email protected]] > > Sent: Tuesday, November 17, 2015 6:00 AM > > To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen; > > [email protected] > > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > Current RIB has ieee-mac RIB, which could use vxlan encap nexthops. > > > > BTW, mpls encap/decap is needed even for non-segmenting scenarios - plain > > old l3vpn, vpls, or evpn with mpls data plane. > > > > Jeffrey > > > > > -----Original Message----- > > > From: i2rs [mailto:[email protected]] On Behalf Of Nitin Bahadur > > > Sent: Monday, November 16, 2015 4:16 PM > > > To: Manish Kumar (manishkr) <[email protected]>; Chris Bowers > > > <[email protected]>; Mach Chen <[email protected]>; > > [email protected] > > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 > > > > > > > > > We need a minimal tunnel encap for MPLS.so that mpls labels can be > > > pushed and popped. So I do want to keep basic (aka mpls) tunnel > > > encap/decap in this draft. This will also enable development of > > > solutions based on Segment routing (or whatever it's called these > days). > > > > > > Nitin > > > > > > On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" <[email protected]> > > > wrote: > > > > > > >Encap/Decap belong to a different layer (actually one that ties two > > > layers > > > >together) and RIB doesn't look the right place for encap/decap to me. > > > > > > > >Thanks, > > > >Manish > > > > > > > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur" > > > ><[email protected] on behalf of [email protected]> wrote: > > > > > > > >> > > > >> > > > >>>I find it odd that the current data model provides the ability to > > > >>>configure encap, but not decap, for VXLAN. This would require the > > > >>>user of the data model to configure VXLAN tunnel-encap using one > data > > model > > > >>>and vxlan-decap using another data model. I think this is perhaps > an > > > >>>indication that VXLAN encap does not belong in the RIB data model > > > >>>either. > > > >> > > > >>I¹ll buy that argument. And I believe we can extend that argument to > > > >>GRE & NVGRE as well. > > > >> > > > >>Anyone on the list have comments related to this? > > > >> > > > >>Thanks > > > >>Nitin > > > >> > > > >> > > > >>_______________________________________________ > > > >>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
