> As far as mapping plane I already pointed out in my Vector Routing proposal > that we have one already it is called BGP. One needs to also observe that we > as industry worked number of years of protocol suite called LISP allowing not > only very good mapping plane, but also data plane integration. CC-ing lisp > authors for their comments. Note also work for integrating SRv6 with LISP > which is already is published.
The main motivationn to have EID-to-SRH mappings in the LISP mapping system is so you can run a LISP overlay on top of an underlay that supports SR. If you want the paths between LISP RLOCs to be “underlay engineered”, then the elements of the SRH header can be part of the RLOCs LISP selects. And when you do underlay path optimization, the new SRHs can be registered dynamically to the mapping system. > Since you correctly observed that now SID can be 32 bit and that is similar > to the size of IPv4 my fundamental question is why not use something which > already exists instead of defining some sort of new from scratch ? > > It will be perfectly fine to have full proper SRv6 with SRH and LISP or > Vector Routing as an alternative options. I really do not see a room or need > for yet one more mapping plane. What problem does it solve which would not be > already solved elsewhere ? In the LISP mapping system I run, I was able to simulate (did not implement referenced draft above), an EID-to-SRH mapping by simply having an IPv6 EID map to an RLOC-set that used ELPs (Explicit Locator Paths - where if the ELP is (A,B,C) it means A encaps to B, B encaps to C), but rather than doing the encapsulation we take the (A,B,C) inserted into one packet as an SRH. The point of the exercise was to show the SR authors that the LISP mapping system was a control-plane they could use and depend on (and ready to go). Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
