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 <[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
