Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

Thanks Dino,

I want to make sure I understand correctly. A couple of questions:


If the EID-prefix exists and there is a policy in the Map-Server to

have the requestor drop packets for the matching EID-prefix, 
then a

Drop/Policy-Denied action is returned. If the EID-prefix exists 
and

there is a authentication failure, then a Drop/Authentication-
failure action is returned. If either of these actions 
result as a
temporary state in policy or authentication then a 
Send-Map-Request
action with 1-minute TTL MAY be returned to allow the 
reqeustor to
retry the Map-Request.

Could I not do the above even if the EID-prefix DID NOT EXIST? Or are we 
restricting any application of policy only to LISP EID-prefixes, and not to 
non-LISP prefixes?

The map-replies suggested in the new text would effectively be NMRs, correct? 
i.e. Map-replies with empty locator sets and the ACT bits set.

If that is the intent, maybe we need to revise the definitions for NMR and ACT 
as I think right now there is some inconsistency/contradiction:

a) NMR definition - Issued in response to queries only for EIDs that DO NOT 
EXIST
b) ACT bits specification - for use in NMRs ONLY
c) New text describing how the ACT bits are used to specify forwarding behavior 
for EIDs that DO EXIST

So NMRs are exclusive to non-existent or non-registered EIDs (a) and ACT bits 
are exclusive to NMRs (b). Yet (c) implies that NMRs will be used for EIDs that 
DO EXIST. So (c) contradicts (a).

Text for (a)

   Negative Map-Reply:   A LISP Map-Reply that contains an empty
  Locator-Set. Returned in response to a Map-Request if the
  destination EID does not exist in the mapping database.
  Typically, this means that the "EID" being requested is an IP
  address connected to a non-LISP site.

Text for (b)

   ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
  other message type, these bits are set to 0 and ignored on
  receipt.  These bits are used only when the 'Locator Count' field
  is set to 0.  The action bits are encoded only in Map-Reply
  messages.  The actions defined are used by an ITR or PITR when a
  destination EID matches a negative Map-Cache entry.  Unassigned
  values SHOULD cause a Map-Cache entry to be created, and when
  packets match this negative cache entry, they will be dropped.


-v

On Mar 20, 2018, at 12:44 AM, Dino Farinacci 
> wrote:

On Mar 19, 2018, at 6:22 PM, Dino Farinacci 
> wrote:

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions

Thanks Victor. See new update enclosed. Let us know if you are good with the 
changes and the response below.

1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
LH, it is not spelled out anywhere. I assume this means Lisp Header.

It is a reference to the row in the diagram above:



Understood, but should we not spell out LISP Header somewhere rather than just 
using LH without spelling it out anywhere?

I can change it. See new diff.


3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
Forward action code. However the definition of the Map-reply message in section 
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG 
agrees I can suggest text that would generalize the recommended processing 
behaviors described in 8.3 to allow the inclusion and use of the specified 
actions in the case of NMRs.

Well the text below is correct and is explaining when a mapping entry DOES NOT 
exist. For all other actions, they are sent for entries that DO EXIST in the 
mapping database. And the reasons for sending the specific action type is 
documented in the Map-Reply ACT field description:

I agree that the text is correct, but I am pointing out that is not sufficient. 
If my policy is to drop traffic destined to an EID that is either not 
registered or not configured in the Mapping DB, how would I instruct the EID to 
drop the traffic? I would think I'd want to issue an NMR with action drop  (4 
or other). The spec currently doesn’t illustrate such actions. Text in 8.3 & 
8.4 prescribes that the NMR for non-configured or non-registered EIDs will 
always have an action of Native-Forward, but I need the action to be Drop (for 
example).

In the definitions section, the NMRs are defined as responses to queries for 
EIDs that DO NOT EXIST, in the text you pasted below, the ACT bits are defined 
as exclusive to the NMRs (set to 0 in any other message).  It is not clear to 
me how these actions can apply to entries that DO EXIST?

-v

Okay, I added some text.

Dino



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

Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

> On Mar 19, 2018, at 6:22 PM, Dino Farinacci  wrote:
> 
>> Dear WG,
>> 
>> I did a quick review of rfc6833bis-08. Some comments/suggestions
> 
> Thanks Victor. See new update enclosed. Let us know if you are good with the 
> changes and the response below.
> 
>> 1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
>> LH, it is not spelled out anywhere. I assume this means Lisp Header.
> 
> It is a reference to the row in the diagram above:
> 
> 

Understood, but should we not spell out LISP Header somewhere rather than just 
using LH without spelling it out anywhere?

> 
> 
>> 2. Section 5.8. On page 27, there is a figure/header format showing the AD 
>> Type and Authentication Data Content, which is not referenced anywhere. 
>> Looks like it needs to be removed.
> 
> Nice find. When the text was moved from RFC6830, we mis-placed it in RFC6833.

Ack, good.

> 
>> 3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
>> Forward action code. However the definition of the Map-reply message in 
>> section 5.4 allows 8 possible action codes and specifies 6 possible actions. 
>> If the WG agrees I can suggest text that would generalize the recommended 
>> processing behaviors described in 8.3 to allow the inclusion and use of the 
>> specified actions in the case of NMRs. 
> 
> Well the text below is correct and is explaining when a mapping entry DOES 
> NOT exist. For all other actions, they are sent for entries that DO EXIST in 
> the mapping database. And the reasons for sending the specific action type is 
> documented in the Map-Reply ACT field description:

I agree that the text is correct, but I am pointing out that is not sufficient. 
If my policy is to drop traffic destined to an EID that is either not 
registered or not configured in the Mapping DB, how would I instruct the EID to 
drop the traffic? I would think I'd want to issue an NMR with action drop  (4 
or other). The spec currently doesn’t illustrate such actions. Text in 8.3 & 
8.4 prescribes that the NMR for non-configured or non-registered EIDs will 
always have an action of Native-Forward, but I need the action to be Drop (for 
example).

In the definitions section, the NMRs are defined as responses to queries for 
EIDs that DO NOT EXIST, in the text you pasted below, the ACT bits are defined 
as exclusive to the NMRs (set to 0 in any other message).  It is not clear to 
me how these actions can apply to entries that DO EXIST? 

-v

> 
>  ACT:  This 3-bit field describes Negative Map-Reply actions.  In any
>  other message type, these bits are set to 0 and ignored on
>  receipt.  These bits are used only when the 'Locator Count' field
>  is set to 0.  The action bits are encoded only in Map-Reply
>  messages.  The actions defined are used by an ITR or PITR when a
>  destination EID matches a negative Map-Cache entry.  Unassigned
>  values SHOULD cause a Map-Cache entry to be created, and when
>  packets match this negative cache entry, they will be dropped.
>  The current assigned values are:
> 
>  (0) No-Action:  The Map-Cache is kept alive, and no packet
>  encapsulation occurs.
> 
>  (1) Natively-Forward:  The packet is not encapsulated or dropped
>  but natively forwarded.
> 
>  (2) Send-Map-Request:  The packet invokes sending a Map-Request.
> 
>  (3) Drop/No-Reason:  A packet that matches this Map-Cache entry is
>  dropped.  An ICMP Destination Unreachable message SHOULD be
>  sent.
> 
>  (4) Drop/Policy-Denied:  A packet that matches this Map-Cache
>  entry is dropped.  The reason for the Drop action is that a
>  Map-Request for the target-EID is being policy denied by
>  either an xTR or the mapping system.
> 
>  (5) Drop/Authentication-Failure:  A packet that matches this Map-
>  Cache entry is dropped.  The reason for the Drop action is
>  that a Map-Request for the target-EID fails an authentication
>  verification-check by either an xTR or the mapping system.
> 
> Thanks again,
> Dino
> 
> 
> 
> 

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

Re: [lisp] New name for upcoming LISP -OAM- document

[Dino Farinacci]

> The suggested name is “LISP Mobility, Deployment and Traceroute 
> considerations”.
> 
> The chairs would like to hear from the mailing list if there is any objection 
> or you have a better name to suggest.

I don’t have a name suggestion (for the 3 items included in one document) but I 
would like to support an idea that Albert provided after the meeting today. 

He suggested to put the Mobility sections in an Appendix in RFC6830bis and put 
Deployment and Traceroute considerations in a document that now can be called 
“draft-ietf-lisp-oam”.

Wonder how people would feel about that?

Dino

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

[lisp] New name for upcoming LISP -OAM- document

[Luigi Iannone]

Hi All,

during today f2f meeting concern has been expressed about the name to use for 
the document that will collect what is neither data-plane nor control-plane.

The name OAM was found not accurate because the document will not cover all of 
what is normally in a OAM document.

The suggested name is “LISP Mobility, Deployment and Traceroute considerations”.

The chairs would like to hear from the mailing list if there is any objection 
or you have a better name to suggest.

Please send an email by the end of the week.

Thanks

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

Re: [lisp] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

These comments apply to version -09 of the document without any change.

-v


On Mar 19, 2018, at 2:18 PM, Victor Moreno (vimoreno) 
> wrote:

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions



1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
LH, it is not spelled out anywhere. I assume this means Lisp Header.

2. Section 5.8. On page 27, there is a figure/header format showing the AD Type 
and Authentication Data Content, which is not referenced anywhere. Looks like 
it needs to be removed.

3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
Forward action code. However the definition of the Map-reply message in section 
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG 
agrees I can suggest text that would generalize the recommended processing 
behaviors described in 8.3 to allow the inclusion and use of the specified 
actions in the case of NMRs.

   8.3.  Map-Server Processing
   Once a Map-Server has EID-Prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.
   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map-Server first checks to see if the destination EID
   matches a configured EID-Prefix.  If there is no match, the Map-
   Server returns a Negative Map-Reply with action code "Natively-
   Forward" and a 15-minute TTL.  This MAY occur if a Map Request is
   received for a configured aggregate EID-Prefix for which no more-
   specific EID-Prefix exists; it indicates the presence of a non-LISP
   "hole" in the aggregate EID-Prefix.
   Next, the Map-Server checks to see if any ETRs have registered the
   matching EID-Prefix.  If none are found, then the Map-Server returns
   a Negative Map-Reply with action code "Natively-Forward" and a
   1-minute TTL.

   8.4 …

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
   table that covers the full EID space), it immediately returns a
   negative LISP Map-Reply, with action code "Natively-Forward" and a
   15-minute TTL.  To minimize the number of negative cache entries
   needed by an ITR, the Map-Resolver SHOULD return the least-specific
   prefix that both matches the original query and does not match any
   EID-Prefix known to exist in the LISP-capable infrastructure.


Regards,

-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] Review 6833bis-08 - General and NMR

[Victor Moreno (vimoreno)]

Dear WG,

I did a quick review of rfc6833bis-08. Some comments/suggestions



1. Section 5.8. Encapsulated Control Message Format. There is a reference to 
LH, it is not spelled out anywhere. I assume this means Lisp Header.

2. Section 5.8. On page 27, there is a figure/header format showing the AD Type 
and Authentication Data Content, which is not referenced anywhere. Looks like 
it needs to be removed.

3. Section 8.3/8.4. The text is limited to recommending exclusively a Native 
Forward action code. However the definition of the Map-reply message in section 
5.4 allows 8 possible action codes and specifies 6 possible actions. If the WG 
agrees I can suggest text that would generalize the recommended processing 
behaviors described in 8.3 to allow the inclusion and use of the specified 
actions in the case of NMRs.

   8.3.  Map-Server Processing
   Once a Map-Server has EID-Prefixes registered by its client ETRs, it
   can accept and process Map-Requests for them.
   In response to a Map-Request (received over the ALT if LISP+ALT is in
   use), the Map-Server first checks to see if the destination EID
   matches a configured EID-Prefix.  If there is no match, the Map-
   Server returns a Negative Map-Reply with action code "Natively-
   Forward" and a 15-minute TTL.  This MAY occur if a Map Request is
   received for a configured aggregate EID-Prefix for which no more-
   specific EID-Prefix exists; it indicates the presence of a non-LISP
   "hole" in the aggregate EID-Prefix.
   Next, the Map-Server checks to see if any ETRs have registered the
   matching EID-Prefix.  If none are found, then the Map-Server returns
   a Negative Map-Reply with action code "Natively-Forward" and a
   1-minute TTL.

   8.4 …

   If the Map-Resolver does not have the mapping entry and if it can
   determine that the EID is not in the mapping database (for example,
   if LISP+ALT is used, the Map-Resolver will have an ALT forwarding
   table that covers the full EID space), it immediately returns a
   negative LISP Map-Reply, with action code "Natively-Forward" and a
   15-minute TTL.  To minimize the number of negative cache entries
   needed by an ITR, the Map-Resolver SHOULD return the least-specific
   prefix that both matches the original query and does not match any
   EID-Prefix known to exist in the LISP-capable infrastructure.


Regards,

-v





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

Re: [lisp] I-D Action: draft-ietf-lisp-rfc6830bis-10.txt

[Albert Cabellos]

Hi all

I just posted -12 with the changes suggested by Luigi

Albert

On Tue, Mar 6, 2018 at 9:29 AM, Luigi Iannone  wrote:

> Hi Albert,
>
> thanks for submitting the updated document.
>
> I have have a few residual nits listed below. Fixed those we can move to
> LC IMO.
>
> Ciao
>
> L.
>
>
>
>LISP Nonce:  The LISP 'Nonce' field is a 24-bit value that is
>   randomly generated by an ITR when the N-bit is set to 1.  Nonce
>   generation algorithms are an implementation matter but are
>   required to generate different nonces when sending to different
>   destinations.
>
> [Luigi]
> As stated for -07: What is a destination? Should be different RLOCs, for
> clarity.
>
>
> The Clock Sweep mechanism is just about management should go in AOM.
>
>
> The following document are not Normative:
>
>  [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
>   "Randomness Requirements for Security", BCP 106 
> , RFC 4086 
> ,
>   DOI 10.17487/RFC4086, June 2005,
>   .
>
>
> [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
>   Support in IPv6", RFC 6275 
> , DOI 10.17487/RFC6275, July
>   2011, .
>
>
>
>
>
>
> On 5 Mar 2018, at 22:33, Albert Cabellos 
> wrote:
>
> Hi
>
> I'll post a new version without such sections shortly.
>
> I volunteer to help writing the OAM document.
>
> Albert
>
> On Mon, Mar 5, 2018 at 9:35 PM, Dino Farinacci 
> wrote:
>
>> >> On 5 Mar 2018, at 19:06, Dino Farinacci  wrote:
>> >>
>> >>> Hi all
>> >>>
>> >>> This document should address all the comments except this one:
>> >>>
>> >>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
>> Considerations), 18 (Traceroute Consideration) to a new OAM document
>> >>>
>> >>> The authors would like to have a better understanding of where this
>> text will go.
>> >>
>> >> Right, we concluded to not remove the valuable text.
>> >
>> > Nobody wants to lose valuable text.
>>
>> Glad you feel that way.
>>
>> >
>> >> A lot of time and thought went into writing it and we didn’t want to
>> lose it. There was no where that was agreed upon to put it.
>> >
>> > That is not accurate. There was clear indication to move it to a new
>> OAM document, without any change in the text.
>> > Purpose was to have just a different placeholder that make more sense.
>> > This is an half an hour task.
>>
>> But there was also concerns about slowing the process down. And the
>> co-authors (Albert and I) don’t think it should move from RFC6833.
>>
>> So there isn’t concensus. And I don’t believe it is even rough concensus.
>>
>> >
>> >>
>> >> So since we felt there was no concensus on Sections 16-18, we didn’t
>> make any change.
>> >
>> > Again not accurate, please spend half an hour to create the OAM
>> document.
>> > If you do not have time we can appoint other editors for the task.
>> Authorship will be anyway preserved.
>>
>>
>> Section 16 is “Mobility Considerations” that discusses various forms of
>> how EIDs can change RLOCs. And it sets up for different designs that are
>> already documented in various documents. But Mobility certainly shouldn’t
>> go in an OAM document.
>>
>> Section 17 discusses where xTRs (data-plane boxes) should reside in the
>> network. And sets up for a more detail discussion which is in the
>> Deployment RFC.
>>
>> Section 18 is “Traceroute Considerations”, this arguably can go into an
>> OAM document. But it would be 3 pages. And then one would argue there are
>> other OAM mechanisms spread across LISP documents that could go in an OAM
>> document.
>>
>> This will not take 1/2 hour.
>>
>> And I’m finding it hard to see the value in doing all this busy work. We
>> have already accomplished separating data-plane text from control-plane
>> text. We achieved that goal from the charter.
>>
>> Dino
>>
>>
>
>
___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

[lisp] I-D Action: draft-ietf-lisp-rfc6830bis-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Locator/ID Separation Protocol WG of the IETF.

Title   : The Locator/ID Separation Protocol (LISP)
Authors : Dino Farinacci
  Vince Fuller
  Dave Meyer
  Darrel Lewis
  Albert Cabellos
Filename: draft-ietf-lisp-rfc6830bis-12.txt
Pages   : 42
Date: 2018-03-19

Abstract:
   This document describes the Data-Plane protocol for the Locator/ID
   Separation Protocol (LISP).  LISP defines two namespaces, End-point
   Identifiers (EIDs) that identify end-hosts and Routing Locators
   (RLOCs) that identify network attachment points.  With this, LISP
   effectively separates control from data, and allows routers to create
   overlay networks.  LISP-capable routers exchange encapsulated packets
   according to EID-to-RLOC mappings stored in a local Map-Cache.

   LISP requires no change to either host protocol stacks or to underlay
   routers and offers Traffic Engineering, multihoming and mobility,
   among other features.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6830bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-12
https://datatracker.ietf.org/doc/html/draft-ietf-lisp-rfc6830bis-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc6830bis-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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