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

[Dino Farinacci]

> Correct, what is of interest is to have some sense of the likelihood of the 
> mapping received changing and allow the ITR to check again. We are looking at 
> the NMR as one way to indicate back to the ITR the nature 

Sounds like one way is using draft-rodrigueznatal-lisp-pubsub-00. Then the ITR 
doesn’t have to poll.

> of the mapping. Because the ITR can differentiate clearly between an NMR and 
> a Positive MR, it can choose 

I am not convinced it needs to treat the mappings differently. You probably 
want the logic simple in the ITRs. That is, lookup a destination in the 
map-cache and encapsulate (and nothting more). 

> to treat the mappings differently. For example (maybe this is implementation 
> specific) the cache-TTL assigned to the mapping received in an NMR may be in 
> the order of minutes, vs. a mapping from a positive MR having a TTL in the 
> order of hours..

That is something that the replier can control. Maybe you have a third-party 
that ligs non-EIDs, and when the length of the negative prefix changes, then a 
new mapping is registered, or you change the RLOC set of the existing mapping. 
In either case, pubsub will cause a map-server to Map-Notify the ITRs that are 
interested.

>> I would not call these negative map-replies though. By definition, from the 
>> spec, a negative map-reply is a map-reply with an RLOC-count of 0. 
> 
> What I am after is a map reply with the characteristics of an NMR (short TTL, 
> dynamically calculated covering prefix for non-EID destination), but an 
> RLOC-count > 0. If there is a way to encode this with a Positive MR, then we 
> are covered. 

ODL  ;-) Like I referneced above.

> 
>> What many implemenationsn do is when they get a map-reply with an RLOC set 
>> of 0, they then decide, via configuration to encapsulate to a list of xTRs. 
>> Those xTRs are PETRs (by definition of the implementation).
> 
> We are trying to avoid the “decide, via configuration, to encapsulate to a 
> list of xTRs”, but still have the ITR give the map-cache a short TTL. 

Completely understand. A good goal to go after.

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Victor Moreno (vimoreno)]

> On Aug 22, 2017, at 10:22 AM, Dino Farinacci  wrote:
> 
> Here are some of my comments Victor.
> 
>> Would be mainly conveying the RLOCs of the feasible PETRs dynamically.
> 
> Anything or anyone can register mapping entries to the mapping database as 
> long as they are authenticated with the map-server. So I believe you can 
> achieve what you want with NO spec changes or additions to the protocol.

That would be great, we’ve been trying and haven’t had luck.

> 
>> 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.
> 
> Meaning you do not want ITRs to have to configure PETRs. That makes a ton of 
> sense for scale and management reasons.

Correct, we are looking at 1000s of ITRs in some of these networks.
> 
>> 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.
> 
> An ITR has no idea where a packet really ends up. So if its encapsulating to 
> an ETR at the destination site or a PETR that decaps and sends the packet 
> many “native” hops to a non-EID destination, then so be it.

Correct, what is of interest is to have some sense of the likelihood of the 
mapping received changing and allow the ITR to check again. We are looking at 
the NMR as one way to indicate back to the ITR the nature of the mapping. 
Because the ITR can differentiate clearly between an NMR and a Positive MR, it 
can choose to treat the mappings differently. For example (maybe this is 
implementation specific) the cache-TTL assigned to the mapping received in an 
NMR may be in the order of minutes, vs. a mapping from a positive MR having a 
TTL in the order of hours..

> 
> I would not call these negative map-replies though. By definition, from the 
> spec, a negative map-reply is a map-reply with an RLOC-count of 0. 

What I am after is a map reply with the characteristics of an NMR (short TTL, 
dynamically calculated covering prefix for non-EID destination), but an 
RLOC-count > 0. If there is a way to encode this with a Positive MR, then we 
are covered. 

> 
> What many implemenationsn do is when they get a map-reply with an RLOC set of 
> 0, they then decide, via configuration to encapsulate to a list of xTRs. 
> Those xTRs are PETRs (by definition of the implementation).

We are trying to avoid the “decide, via configuration, to encapsulate to a list 
of xTRs”, but still have the ITR give the map-cache a short TTL. 

> 
> It could be useful to write up a very short draft indicating a “dynamic 
> use-case for PETRs”. But check the Interworking RFC to make sure we didn’t 
> cover this, in some form (even brief) in that spec.

I can do that if it helps. It would be very very brief.

-v

> 
> Cheers,
> Dino
> 
>> 
>> -v
>> 
>>> On Aug 21, 2017, at 11:12 PM, Joel M. Halpern  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
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

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

[Victor Moreno (vimoreno)]

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

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

[Joel M. Halpern]

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

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

[Victor Moreno (vimoreno)]

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

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

[Joel M. Halpern]

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

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

[Victor Moreno (vimoreno)]

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