The sentence has been removed. I am going to submit -06 today and we can still discuss the remaining issue and make a -07 update when needed.
Dino > On Oct 30, 2017, at 3:44 AM, Luigi Iannone <[email protected]> wrote: > > > >> On 28 Oct 2017, at 18:15, Rene 'Renne' Bartsch, B.Sc. Informatics >> <[email protected]> wrote: >> >> >> >> Am 27.10.2017 um 06:30 schrieb Dino Farinacci: >>>> I'm not that happy with >>>> >>>> "As the architecture is realized, if a given bit string is both an RLOC >>>> and an EID, it must refer to the same entity in both cases". >>>> >>>> In a MESH-architecture the EID of a mobile-node can be the RLOC of a >>>> neighbour mobile-node. >>> I too would like to understand your comment. >>> >>> What the sentence is trying to achieve is that in some cases an EID and >>> RLOC may be the same value for a given end-node. Like when when an EID is >>> behind a NAT and the xTR is on the public side of the NAT, where the local >>> private EID will be translated to a global EID and to reach the xTR the >>> RLOC is also the same translated address. >>> >>> Dino >> >> Sorry, I missed the context and thought it is generally valid. >> >> The basic idea for a MESH-network is a LISP-node which acts as a xTR for >> itself and a RTR for the neighbour-nodes. In that case the string is a LEID >> for the MESH-node and a RLOC for the neighbour MESH-nodes. As the phrasing >> does not apply in this case, I'm happy with the removed "EIDs MUST NOT be >> used as LISP RLOCs". ;-) > > I think I’ve got it now. > > In my personal opinion I agree with you. EID and RLOCs are relative to the > deployment model and such a strong requirement is not really useful/needed. > > Luigi > >> >> >> Renne >> >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
