Re: [lisp] 6833bis - NMR with locator count !=0

["Joel M. Halpern" <[e-mail]>]

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 <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lisp
>