On Thu, Jun 4, 2015 at 11:46 AM, Robert Shearman <rshea...@brocade.com> wrote: > On 03/06/15 19:43, Vivek Venkatraman wrote: >> >> On Tue, Jun 2, 2015 at 2:06 PM, Robert Shearman <rshea...@brocade.com> >> wrote: >>> >>> On 02/06/15 19:57, roopa wrote: >>>> >>>> >>>> On 6/2/15, 9:33 AM, Robert Shearman wrote: >>>>> >>>>> >>>>> On 02/06/15 17:15, roopa wrote: >>>>>> >>>>>> >>>>>> On 6/1/15, 9:46 AM, Robert Shearman wrote: >>>>>>> >>>>>>> >>>>>>> Allow creating an mpls device for the purposes of encapsulating IP >>>>>>> packets with: >>>>>>> >>>>>>> ip link add type ipmpls >>>>>>> >>>>>>> This device defines its per-nexthop encapsulation data as a stack of >>>>>>> labels, in the same format as for RTA_NEWST. It uses the encap data >>>>>>> which will have been stored in the IP route to encapsulate the packet >>>>>>> with that stack of labels, with the last label corresponding to a >>>>>>> local label that defines how the packet will be sent out. The device >>>>>>> sends packets over loopback to the local MPLS forwarding logic which >>>>>>> performs all of the work. >>>>>>> >>>>>>> >>>>>> Maybe a silly question, but when you loop the packet back, what does >>>>>> the >>>>>> local MPLS forwarding logic >>>>>> lookup with ? It probably assumes there is a mpls route with that >>>>>> label >>>>>> and nexthop. >>>>>> Will this need any internal labels (thinking same label stack >>>>>> different >>>>>> tunnel device etc) ? >>>>> >>>>> >>>>> >>>>> Yes, it requires that local/internal labels have been allocated and >>>>> label routes installed in the label table for them. >>>> >>>> >>>> This is our only concern. >>>>> >>>>> >>>>> >>>>> It is entirely possible to put the outgoing interface into the encap >>>>> data to avoid having to allocate extra labels, but I did it this way >>>>> in order to support PIC Core for MPLS-VPN routes. >>>> >>>> >>>> >>>> hmm..., is a netdevice must in this case.., can you please elaborate on >>>> this ?. >>> >>> >>> >>> Yes, the ipmpls device would still be used to perform the encapsulation, >>> transitioning from the IP forwarding path to the MPLS forwarding path. >>> >> >> Transitioning from IP forwarding to MPLS forwarding as you have here >> will certainly facilitate PIC core when another path exists to the >> edge. But it cannot deal with PIC edge, right? > > > Right, it won't allow to PIC edge to work as is, but it could be a step > towards implementing PIC edge. > >> Additionally, this >> approach would mean that the user's (iproute2) view would be rather >> strange - while the actual forwarding requires labels L1 and L2 >> (bottom) to be pushed when forwarding to a destination, it would look >> as if labels L3 and L2 are pushed and then L3 is swapped with L1. > > > Right, but a level of indirection is required somehow. The natural level of > indirection is the L3 nexthop, but that is more complicated and I don't know > if that sort of change would be welcome. > >> A different way to achieve PIC (core and edge) without transitioning >> from IP forwarding to MPLS forwarding may be to introduce the concept >> of an alternate nexthop with something (e.g., link status) determining >> which nexthop is used. > > > I'm not sure I understand. Could you elaborate on this?
Indirection on the L3 nexthop is what I meant. I agree that it would be more complicated. The thought was to model it like ECMP, so there would be a set of nexthops (2 for main and alternate), but it would be a protection group instead of a shared group. > > Thanks, > Rob -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
