Re: [lisp] LISP-GPE Review

[Luigi Iannone <[e-mail]>]

I am having second thoughts ;-)



>>        0                   1                   2                   3
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |N|L|E|V|I|P|K|K|        Nonce/Map-Version      | Next Protocol |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |                 Instance ID/Locator-Status-Bits               |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> 
>> 
>>                              LISP-GPE Header
>> 
>> 
>> 
>> 
>> 
>> 
>> Lewis, et al.           Expires September 6, 2018               [Page 4]
>> Internet-Draft       LISP Generic Protocol Extension          March 2018
>> 
>> 
>> 4.  Backward Compatibility
>> 
>>   LISP-GPE uses the same UDP destination port (4341) allocated to LISP.
>> 
>>   A LISP-GPE router MUST not encapsulate non-IP packets to a LISP
>>   router.  A method for determining the capabilities of a LISP router
>>   (GPE or "legacy") is out of the scope of this draft.
>> 
> 
> I think this is too restrictive IMO and will will cause problem in incremental deployments. 
> 
> Imagine deploying LISP-GPE in the beta network…  we cannot because this would mean having a flag day, which is impossible.
> 
> I think would be better to have bits N, E, V to 0 when P is 1 in this way there is compatibility.
> 

Actually may be is too extreme, echo-nonce is a nice feature would be nice to keep it in LISP-GPE.

So may be N and E we can use it as described in the document and still make legacy LISP and LISP-GPE talk to each other.

Legacy LISP can use echo none toward LISP-GPE who will reply as described in the echo nonce mechanism as described in 6830bis  (and obviously with P=0).

The other direction is more interesting. What happens if LISP-GPE sends a packet with  E=1 N=1 and P=1? Legacy LISP will interpret the shorter Nonce+Protocol as actually one single Nonce and will echo back that value. The return packet ill have N=1, E=0because is a reply, and P=0 because is legacy LISP.
LISP-GPE can still infer that it is a echo sent back and just check the 16 bits in the middle of the first long word.

Such approach will not work with versioning. 

So we should keep a sentence that states that Map-Versioning as described in this document SHALL only be used when a LISP-GPE box knows that is encapsulating toward another LISP-GPE box. How it knows it is out of the scope of the document.

Comments?

Ciao

L.




  




> A legacy LISP data-plane box will never participate in a mapping that is not IP over IP, hence LISP-GPE can send traffic with P=1 and Next protocol equal 1 or 2.
> The legacy LISP box will receive the packet, will ignore the P bit and decapsulate as IP over IP and will work without problems.
> 
> For the other direction, legacy LISP box sending to LISP-GPE box, everything depends again on the mappings. 
> Legacy LISP will talk only to xTR that locators using IP over IP, cannot do otherwise. The receiving LISP-GPE is able to handle legacy LISP traffic.
> 
> The mappings deliver the information of "what is mapped on what"  just using LCAF, but details are out of the scope of this document. 
>