> On the other hand, the draft proposes the recursive approach that *prepend*s > more than one header. I'm confused of the
Only when you need to perserve an outer RLOC based header. Just like MPLS uses service-in-service through an ISP with stacked headers. But I think it would be rarely used in the LISP overlay case. > *header*. Is the header consisted of outer IP header and LISP header, or just > IP header (assuming the IP underlay network)? I want to make it clear whether > the writing of 'recursive' means utilizing the TE capabilities of underlay > network. (referring to the second example of recursion in 5.2) The recursive header means this: (1) First inner header with EIDs is constructed by the host. (2) Outer header with RLOCs is constructed by the first ITR/RTR/PITR that gets the EID packet. (3) A second outer header with RLOCs is constructed by any ITR/RTR/PITR that is on path of the RLOC packet. And (3) is only performed, if that xTR is configured to add a header. > • If yes, I would argue that Section 5.2 in RFC 9300 describes the > IPv6-in-IPv6 header format but it didn’t include the extensions of IPv6 > header. Consequently, underlay TE is not available in this case since segment > routing header(RFC 8754) requires the use of extension header. (Unless > another IP header that involves extension header is prepended) Extension headers are not used in general. If, for instance, an ITR/RTR/PITR wanted to add an SRH, a draft would need to be written to say exactly what they do when they want to use an underlay with such capability. But segment-route controls the path the ITR choose FOR THE underlay and not the encapsulation path (overlay path) which LISP-TE specs out. > • If no, it says that LISP has to prepend more headers (IP header or LISP > header, or both of them). Obviously, it could be not efficient enough. In > this case, why not make it a more elegant way, for example, enabling LISP > header to carry the RLOC record. I am not following your suggestion. The LISP header has specific features like lisp-crypto, nonce-echoing, map-versioning, vpn-identificaion which are relevant to handling the packet and not what header is prepended to the packet. That is a later step after LISP header is prepended. Note when you prepend an outer IPv4 or IPv6 header in front of a LISP header, it means that header has RLOC addresses in it. Dino _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
