Hi Alia, Yes, I agree with what you said.
Regarding to the VxLAN or GRE decapsulation, for a VxLAN or GRE encapsulated packet, from the out header point of view, it is actually an IP packet. When the egress router received the packet, since the destination is itself, the packet will be normally forwarded to the TCP/IP stack for further processing, and till here, the tunnel decap operation should be finished IMHO. In the TCP/IP stack, the VxLAN/GRE inner header will be exposed. The further processing depends on the inner header. Best regards, Mach From: Alia Atlas [mailto:[email protected]] Sent: Tuesday, December 01, 2015 4:32 AM To: Mach Chen Cc: Jeffrey (Zhaohui) Zhang; Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; [email protected] Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03 <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]<mailto:[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]<mailto:[email protected]>] > Sent: Tuesday, November 17, 2015 6:00 AM > To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen; > [email protected]<mailto:[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]<mailto:[email protected]>] On > > Behalf Of Nitin Bahadur > > Sent: Monday, November 16, 2015 4:16 PM > > To: Manish Kumar (manishkr) > > <[email protected]<mailto:[email protected]>>; Chris Bowers > > <[email protected]<mailto:[email protected]>>; Mach Chen > > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> on behalf of > > >[email protected]<mailto:[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]<mailto:[email protected]> > > >>https://www.ietf.org/mailman/listinfo/i2rs > > > > > > > > > _______________________________________________ > > i2rs mailing list > > [email protected]<mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ 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
