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. > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
