Would be mainly conveying the RLOCs of the feasible PETRs dynamically. As PETRs are brought on-line in the network, they can be configured/added in the Mapping System, rather than touching a multitude of ITRs. This would also allow a more elegant definition for the support of a default exit to the Internet in the Extranet case defined in the lisp-vpn draft. In this scenario, the RLOC record would convey the RLOC of the PETR plus the IID to which the Internet connects at the PETR.
-v > On Aug 21, 2017, at 11:12 PM, Joel M. Halpern <[email protected]> wrote: > > Can you explain what information you are conveying with the RLOCs? I think > we would need a clear use case before changing the spec. > > Yours, > Joel > > On 8/22/17 2:07 AM, Victor Moreno (vimoreno) wrote: >> Dear WG, >> As we put some of our specifications to the test in deployments, we have >> found the ability to return RLOCs dynamically in an NMR to be compelling in >> a variety of deployment scenarios. Particularly in Networks with multiple >> Internet exit points. >> What are the thoughts of the group on allowing NMRs with a locator count !=0? >> One option to indicate that a map-reply is an NMR could be to assign one of >> the reserved bits as an NMR flag. >> Would like to gauge the inclination of the WG before proposing text/edits. >> -v >> _______________________________________________ >> lisp mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
