Hi Dino, I further have some questions. See below.
Hongyi > -----Original Message----- > From: Dino Farinacci <[email protected]> > Sent: Thursday, April 20, 2023 11:18 AM > To: Huanghongyi(Hongyi) <[email protected]> > Cc: [email protected]; [email protected] list <[email protected]> > Subject: Re: [lisp] Comments to draft-ietf-lisp-te-12 > > > 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. > Can xTR in (2) and (3) be the same one? That is, when an ITR wants to apply overlay segment routing (for example, ITR->X(RTR)->Y(RTR)->ETR), it will add outer headers containing ETR, Y, X respectively, one by one, and only one LISP header exists in each packet. Right? I have suggestion that these terms and the process need more clarification in the document. > > • 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. > May I summarize that current encapsulation method in RFC 9300 doesn't support underlay segment routing, despite how rare SRH is used? And whenever the underlay TE with segment routing grows widely used, there may be a new document updating RFC 9300? > > • 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. > IMHO, TE could be another feature in addition to security and others, when we want to realize LISP TE in the overlay. The outer header with RLOC in it is for specifying a single destination. However, TE requires more RLOCs that are for specifying xTRs along the way. So where to accommodate these RLOCs? > 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 [email protected] https://www.ietf.org/mailman/listinfo/lisp
