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
