Re: [lisp] Comments to draft-ietf-lisp-te-12

[Dino Farinacci <[e-mail]>]

> Hi Dino,
> 
> I further have some questions. See below.

Trimmed some extra text but keeping your respones.

> 
>> 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? 

Yes, you can segment route between overlay routers/nodes. Like, for instance, if supported in a satellite network, an ITR could decide what orbits a packet takes to reach an RTR on the ground. This is just a very rough example.

> I have suggestion that these terms and the process need more clarification in the document.

Sure, please send specific comments.

> 
>> 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?

That is right because it is specific to an underlay feature. But if LISP puts either an IPv4 or IPv6 outer header on, the packet will get delivered further downstream on a MPLS or SR network. Designing the architecture this way makes the functionality general for more use-cases.

>>>   • 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

We do. See enclosed service chaining slide as an example.

> 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?

If you want to describe an encapsulation path, you need to describe/identify the path somewhere. Either in the data-plane with various source-routing ideas over the decades or in the control-plane as the LISP mapping system supports with ELP encodings (LISP-TE Explicit Locator Path).

For a given EID, the ELP RLOC-record is registered and the mapping system holds the state so each xTR along the path caches the state, when they need it and know which is the next RLOC after itself to encap to.

Dino