Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

From: Mach Chen <[email-masked]>
Date: Wed, 2 Dec 2015 06:31:13 +0000

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-masked]]
Sent: Tuesday, December 01, 2015 4:32 AM
To: Mach Chen
Cc: Jeffrey (Zhaohui) Zhang; Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>]
> Sent: Tuesday, November 17, 2015 6:00 AM
> To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen;
> [email-masked]<mailto:[email-masked]>
> 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-masked]<mailto:[email-masked]>] On Behalf Of Nitin Bahadur
> > Sent: Monday, November 16, 2015 4:16 PM
> > To: Manish Kumar (manishkr) <[email-masked]<mailto:[email-masked]>>; Chris Bowers
> > <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>
> > 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-masked]<mailto:[email-masked]>>
> > 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-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
> > >>https://www.ietf.org/mailman/listinfo/i2rs
> > >
> >
> >
> > _______________________________________________
> > i2rs mailing list
> > [email-masked]<mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/i2rs

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs