Thanks Joel, That would be ideal, could you please shed some light on what you see as “suitable indications” in a map-reply?
The two things that are compelling about the NMR are: 1. Dynamic calculation of covering prefix for the non-EID requested 2. short TTL of the mapping so that we continue requesting more specifics (the ITR implementations usually know to assign a short TTL when the map-reply is an NMR [loc-count == 0]) If I can continue to achieve those without manually configuring the PETR RLOCs at the ITRs, we have what we need. But I didn’t see a way to do this in the framework of the current spec. -v > On Aug 22, 2017, at 7:40 AM, Joel M. Halpern <j...@joelhalpern.com> wrote: > > Now speaking only as an individual: > > If you want the Proxy ETR to be in the mapping system, wouldn't it make more > sense to have it register the address block for which it is serving as a > proxy? With suitable indications so that ITRs which learn of it get back the > bits that tell them to continue askign about more specifics? That would seem > to result in existing ITRs working with these newer PETRs without any changes. > > Yours, > Joel > > On 8/22/17 2:32 AM, Victor Moreno (vimoreno) wrote: >> 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 <j...@joelhalpern.com> 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 >>>> lisp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
