Hi Wim, > The draft only defines procedures for SRoIP E2E, why don’t we envision SRoIP > to > Interwork with native MPLS-SR. : > You could envision certain segments to do SRoIP and other segments to have > native MPLS-SR capability.
Yes, the "mixed mode" is both interesting and useful. In fact, this comes "for free". Consider the example in Figure 3 where UDP is used to connect two SR domains. Now consider that the domains could be any size, the tunnel could be any length, and the picture could be repeated concatenating multiple instance. Furthermore, the picture need not be fully symmetrical. That is, one end of the flow could be a "domain" and the other could be a single (ingress or egress) router. > So my question is this in scope of this draft? So, yes, definitely in scope. If you feel this could be usefully described we'll add text, but I suspect it just follows and we only need to add a short note. But... > What I mean is when using the SRoIP procedures the draft uses SRoIP at every > hop which is SR capable. Not the case. As shown in Figure 4 and discussed in sections 5.3 and 5.4, there may be transit routers on the path. These may be native IP (i.e.) legacy routers, or SR-capable routers that are simply not explicitly part of the SR path. Only the nodes explicitly mentioned in the SR path become UDP end points and do the SRoIP procedures. Cheers, Adrian _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
