Hi all,
After reading the draft, I believe it is a really good idea, but I think
that the document needs more work to be done.
Some comments and questions that I have when reading the document are
the following ones:
In section 6, the structure of a "Nexgon packet" is introduced with the
Nexgon header but no description is provided of the fields of this
header. After reading the document you can deduce the use of some of
these fields but not all of them.
"/EdgeRTRs then re-encapsulates annotation packets either to remote
EdgeRTR (option 1) or to homed H3ServiceEID ServerXTR (option 2)/" but I
think no more information is provided about option1 and option2. The
scenario is clear for me when we have one EdgeRTR between client-XTR and
server-XTR but when we have to reencapsulate packets from EdgeRTR to
another EdgeRTR I don't understand when to use it and the process to
implement it. Is it using ELPs?
"/EdgeRTRs do not register MobilityClients’ EIDs at the mapping service
as these are temporary-renewed while using the mobility network./": Does
the Client-XTR send Map Registers to the EdgeRTR? If not, how does it
know the Client-xTR's RLOCs and its changes?. Otherwise, If it sends
Map-Register, can we consider the EdgeRTR as the MS of the Client-xTR?
Is there any mechanism contemplated for the MobilityClient to change the
associated EdgeRTRs? for instance repeating the procedure explained in
section 4 when changing to a new H3.9 section?
I think that more references need to be added to the document like the
DIAMETER RFC.
I hope these comments could help to improve the document.
Best regards
Albert López
On 3/2/21 16:25, Luigi Iannone wrote:
Hi All,
The authors of draft-ietf-lisp-nexagon submitted the current version
back in October solving issues raised during SECDIR review.
No further comments have been raised and the authors consider the
document stable and ready for WG Last Call.
This email open the usual two weeks Working Group Last Call, to end
February 17th, 2021.
Please review this WG document and let the WG know if you agree that
it is ready to be handed over to the AD.
If you have objections, please state your reasons why, and explain
what it would take to address your concerns.
NOTE: silence IS NOT consensus!
Thanks
Luigi & Joel
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
