Subject: [lisp] Mirja Kühlewind's Discuss on draft-ietf-lisp-rfc6833bis-13: (with DISCUSS and COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 11 Sep 2018 08:02:08 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1) Versioning and backward compatibility

Section 5.2 says: "Support for requesting multiple EIDs in a single Map-Request
      message will be specified in a future version of the protocol."
However, there is no versioning mechanism for this protocol specified. How is
versioning supposed to work?

Further given there is no new version, I wonder if the changes as outlined in
section 10 are all backward-compatible? Especially for the introduction of the
Message-Notify-Ack message, I guess there is no problem if a server sends it,
however, as the sender of the Message-Notify message might not know if the
other end supports sending of the Message-Notify-Ack it can't rely on it. This
should be further discussed in the doc! Or is there another strategy to achieve
backward compatibility?

2) Size and MTU

As outlined in the TSV-ART review (Thanks Colin!) this document does not
discuss fragmentation or Path MTU discovery. RFC8085 recommends to either
perform Path MTU discovery or limit the message to 576 bytes for IPv4 or 1280
bytes for IPv6 (minus any static header). As this seems to be an appropriate
size for LISP messages, I would recommend this approach. Relying on IP
fragmentation (as indicated in the reply to the TSV-ART review) is not
recommended by RFC8085 as this would lead to IP packet without a UDP header, in
the case of LISP, which can cause problem and loss when NATs are involved. In
any case the chosen approach needs to be further discussed in the doc.

3) Rate-limiting and congestion control

Sec 5.3: "Map-Requests MUST be rate-limited.  It is RECOMMENDED that a Map-
   Request for the same EID-Prefix be sent no more than once per second."
As already noted by the TSV-ART review (Thanks Colin!), RFC8085 actually
recommends to not send more the one packet per 3 seconds, and that is a
restriction for all traffic not on a per-receiver base, or implement congestion
control. This limit is meant to not only protect the receiver but also the
network from overloading. Why do you use a smaller interval here? Also if
(appropriate) rate limiting is used, this should either be a MUST or more
explanation when it is okay to use a smaller rate limit should be provided.
However, after all, I don't think you those the right approach here for rate
limiting. A Map-Request is always expected to be followed by some reply. For
these kind of communication pattern, RFC8085 recommends to limit the number of
outstanding requests to 1 (see sec 3.1.1 of RFC8085 recommending one packet per
RTT), also for all traffic and not only per receiver. However, this would also
require to implement some simple mechanism to detect a message as lost (see
also further below in point 4).

Similarly I'm not sure about the intent of this requirement in section 5.5:
"Map-Replies SHOULD be sent for an EID-Prefix no more often than once
   per second to the same requesting router. "
My understanding is that Replies are only sent when a request is received. Why
is this additional rate limit needed? Again if used it should be 3 seconds for
all traffic to be inline with RFC8085. Also again, why is that not a MUST?
Further recommendation are needed here.

Further section 6.1 say "Both the SMR sender and the Map-Request responder MUST
rate-limit
   these messages.  Rate-limiting can be implemented as a global rate-
   limiter or one rate-limiter per SMR destination."
This seems to be the same rate limit as mention above, or not...? It would
probably make sense to rate limit the SMR even further. Please clarify and
provide more guidance, e.g. what should the value of a potential additional
rate limit for SMR be?

Respectively the following sentence in section 6.1 is also unclear:
"The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply"
Why is the rate-limit as currently proposed depend on the fact if a Map-Reply
is received? Is the ITR supposed to retransmit the Map-Request...?

And finally the Map-Register, Map-Notify and Map-Notify-Ack messages does not
seem to have any rate-limits. Recommendations inline with RFC8085 should be
provided for the total traffic and not only for a few message types. Again,
Map-Notify and Map-Notify-Ack messages should be send only once per RTT as
there is a feedback mechanism.

For Map-Register sec 8.2 say: "Map-Register messages are sent periodically from
an ETR to a Map-
   Server with a suggested interval between messages of one minute."
However, this a rather a low bound than an upper bound. A required (MUST) rate
limit is still needed.

4) Loss detection and retransmission

As also mention by the TSV-ART review (Once more thanks to Colin!), this spec
has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it
does not specify what to do if the ACK is not received (loss detection and
retransmission scheduling). This makes the spec incomplete and needs to be
further specified in the doc (and also has a relation to the point 3 above of
course).

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Further comments:

1) The example given in 5.5 should probably used IPv6 addresses and use the IP
address space that is reserved for documentation purposes.

2) I find the security requirements in this doc very unsatisfying. Most
important the doc requires the support of authentication mechanism but not the
use of it. I would like to see more clear MUST requirements here. Further,
today and at this stage of the protocol (moving from exp to PS) I find it not
acceptable anymore to have certain security feature as optional and outsourced
into a different work-in-process draft. However, I leave further discussion to
the SEC ADs.

3) Given the following statement:
"Note that while this document assumes a LISP-ALT database mapping
   infrastructure to illustrate certain aspects of Map-Server and Map-
   Resolver operation..."
it seems that RFC6836 should be a normative reference, as it might not be
possible to understand all details explained in this doc with knowing ALT.

4) Further I would also think that I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub
should be normative references as the meaning of the respective bits it not
further specified in this doc. Or can these bits just be ignored if
I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that
should be stated.

Clarification questions:
1) Sec 5.3.:
"For the initial case, the destination IP
   address used for the Map-Request is the data packet's destination
   address (i.e., the destination EID) that had a mapping cache lookup
   failure."
Does that mean that the Map-Request needs to use the IPv4 or IPv6 depending on
the IP version used by the initial message from the EID. Is that always the
case or just for this initial message? I would assume that for all other cases
this is actually independent...? Because otherwise there would be a constraint
on what needs to be requested. I would like t see further clarification about
this in the doc.

2) In section 5.3: "The ITR MAY include all locally
   configured Locators in this list or just provide one locator address
   from each address family it supports."
Would it make sense to include a SHOULD requirement to at least the address
family that is used to send the Request is included (to increase chance to
enable a communication/get a reply)...?

3) Sec 5.4: "If all Weights for a Locator-Set are equal,
      the receiver of the Map-Reply will decide how to load-split the
      traffic. "
Shouldn't the receiver in this case split the traffic equally? Otherwise how
would you signal that the traffic should be split equally? Maybe use all zero
instead to let the receiver decide...?

4) sec 6.1: "When an ITR receives an SMR-based Map-Request for which it does not
   have a cached mapping for the EID in the SMR message, it may not send
   an SMR-invoked Map-Request."
I guess this should be normative and probably also a MUST NOT or at least
SHOULD NOT.

5) Section 7 seems to imply that if it is detected that no route is available,
the ITR should basically do nothing and just drop any incoming packets for that
ETR. Would it make sense for incremental deployability, to just forward the
packet to the IP address of the EID instead...? This way the source host would
not benefit in mobility cases but still gets connectivity otherwise. Or is that
anyway not the implication? If that is the case, that should be further
clarified in the doc.

6) Section 8.2 says: "Note that the Map-Notify message
   is sent to UDP destination port 4342, not to the source port
   specified in the original Map-Register message."
Actually why is that?

Some minor editorial comments:

1) First sentence in intro: the pointer to ietf-lisp-introduction as currently
introduced, makes this reference look very normative: "The Locator/ID
Separation Protocol [I-D.ietf-lisp-introduction] and [I-D.ietf-lisp-rfc6830bis]
specifies..." I would recommend the following wording: "The Locator/ID
Separation Protocol [I-D.ietf-lisp-rfc6830bis] (see also
[I-D.ietf-lisp-introduction]) specifies..."

2) Also in intro: Given that 6830bis is a normative reference "LISP RFC
6830bis" should be replaced with the new RFC number in the text. This should be
noted to the RFC editor; probably this is more obvious if RFCXXX is used
instead.

3) Sec 5.4: "...for another way the R-bit MAY be used."
This looks like a lower case may would be more appropriate.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 11:13:51 -0700

> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

Thanks again for your comments Mirja.

The multiple EID-record encoding is already spec’ed and is in the protocol. And since Map-Requests are triggered by packet arrival or network management tools, they tend to be sent for a single EID. What is for further study is if a ITR would want the entire map-cache, so would it request a set of aggregates and would a replier return all more specifics for the aggregates requested.

> should be further discussed in the doc! Or is there another strategy to achieve

The Map-Notify-Ack has been there since day-1 in implementations. This is just IETF catching up. And it took over 5 years. So we really don’t have a compatibility situation. And didn’t want to create one in the specifications. So consider it a day 1, version 1 message. It really wasn’t added later.

And big part of this push for standardization is to have the specs “catch up” with the implementations. The implementations are way further ahead than the specs.

> any case the chosen approach needs to be further discussed in the doc.

This is a data-plane feature so it is discussed in 6830bis and RFC6830.

> also further below in point 4).

We have referenced RFC8085 in the too be published -14 version of 6833bis.

> Further recommendation are needed here.

Because the source is a bad-actor and sending new Map-Requests (with a new nonce).

> provide more guidance, e.g. what should the value of a potential additional

Some of this machinery is left to the implementor. But we have published some map-cache management guidelines in the lisp-threat RFC.

> is received? Is the ITR supposed to retransmit the Map-Request…?

If you are not getting answers to your Map-Requests because of packet loss or MITM, sending them faster is not going to get you a Map-Reply.

> there is a feedback mechanism.

We have added that in -14.

> However, this a rather a low bound than an upper bound. A required (MUST) rate

That is not rate-limiting to avoid message reduction. It is a soft-state way of keeping registration state alive in the map-server(s).

> has an ACK mechanism for Map-Requests and now also for Map-Notify, however, it

And Map-Notify are acks to Map-Registers when requested.

> further specified in the doc (and also has a relation to the point 3 above of

We focus on why a Map-Request is being generated (to populate the map-cache) and a Map-Reply not only provides information to be put in the map-cache, but acts as an ackl now. If the Map-Request nonce is being replied with a Map-Reply with the same nonce, Map-Requests no longer need to be sent and the requestor is happy with the result (and hence it was reliable).

I disagree. I think its simpler with IPv4 addresses and shouldn’t matter. We want this complex concept to come across as clear as possible. And I believe IPv6 doesn’t do that. This is not a v4 versus v6 response. It is a notation preference.

> into a different work-in-process draft. However, I leave further discussion to

Can you cite where this is a problem. Are you saying we are not supplying enough MUST text?

> possible to understand all details explained in this doc with knowing ALT.

I would like the lisp-chairs and/or Deborah to comment on this.

> I-D.ietf-lisp-mn and I-D.ietf-lisp-pubsub are not implemented? If so that

I would like the lisp-chairs and/or Deborah to comment on this.

> on what needs to be requested. I would like t see further clarification about

No it doesn’t. It depends on the address-family of the map-resolver. And that is configured.

> enable a communication/get a reply)…?

But all address-families are used all the time. And in some ITRs, usually there is no IPv6 at the edge. 

> instead to let the receiver decide…?

It means the ITR will load-split according to hashing. Versus if the priorities are not equal, it is the ETR deciding how packets ingress the LISP site.

> I guess this should be normative and probably also a MUST NOT or at least

Yes, I changed to SHOULD NOT. Good catch. Don’t want to make it a MUST NOT because both sides could be mobile and the remote side may need to populate its map-cache. That would allow less packet loss if we keep it SHOULD NOT versus MUST NOT.

> packet to the IP address of the EID instead...? This way the source host would

Well no. Because the EID most likely doesn’t have a route in the underlying routing system. If there are PITRs out in the core, then the ITR will be configured to know that, a negative map-reply causes those PITRs to be used or PITRs are registering for coarse EID-prefixes.

> anyway not the implication? If that is the case, that should be further

The point you are bringing up is discussed in the LISP interworking document (RFC 6832), FYI.

>   specified in the original Map-Register message."

cisco interperability.

> [I-D.ietf-lisp-introduction]) specifies…"

Good recommendation. Thanks. Changed.

> noted to the RFC editor; probably this is more obvious if RFCXXX is used

What are you suggesting. A bracketed comment inline?

> This looks like a lower case may would be more appropriate.

We fixed a bunch of incorrect capitalized MAYs and SHOULDs.

Thanks again,
Dino

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 12 Sep 2018 09:30:43 +0200

Hi,

two quick comments inline.

> On 11 Sep 2018, at 20:13, Dino Farinacci <[email-masked]> wrote:
> 

IMO We can completely delete that sentence. The documents does a pretty good job to talk in general terms about the mapping system and the use of its front-end Map-Servers/Map-Resolvers.

In the few cases where something specific to ALT and DDT can be said the document actually does it.

> I would like the lisp-chairs and/or Deborah to comment on this.

Those bits can be ignored if an implementer choses not to support those mechanisms.
Hence, the documents do not really need to be normative.

Ciao

L.

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Sep 2018 12:44:36 +0200

Hi Dino,

please see below.

> Am 11.09.2018 um 20:13 schrieb Dino Farinacci <[email-masked]>:
> 

I guess this sentence should be revised then.

> The Map-Notify-Ack has been there since day-1 in implementations. This is just IETF catching up. And it took over 5 years. So we really don’t have a compatibility situation. And didn’t want to crea…

This should be stated in section 18.

> This is a data-plane feature so it is discussed in 6830bis and RFC6830.

This is a different issue. The control plane protocol as specified in this doc also needs to consider fragmentation and MTU. Please read RFC8085 accordingly.
> We have referenced RFC8085 in the too be published -14 version of 6833bis.

I didn’t find a reference in -14. However a reference is not enough, the specified behavior is not appropriate and needs to change. If you need further help, please consult the respective transport experts, e.g. Gorry Fairhurst who is an author of RFC8085.

> Because the source is a bad-actor and sending new Map-Requests (with a new nonce).

Not sure if that is the right choice because it may interact badly with loss detection. However, as I said the specified behavior need to be refined at various places in the doc.

> Some of this machinery is left to the implementor. But we have published some map-cache management guidelines in the lisp-threat RFC.

I think clear default guidance must be given in this document. My main problem is that the guidance here is not clear (in relation to other rate limits).
> If you are not getting answers to your Map-Requests because of packet loss or MITM, sending them faster is not going to get you a Map-Reply.

If you detect loss, you should send slower not faster for congestion collapse avoidance.

> That is not rate-limiting to avoid message reduction. It is a soft-state way of keeping registration state alive in the map-server(s).

That fine but you also need to specify normatively an upper bound.

> We focus on why a Map-Request is being generated (to populate the map-cache) and a Map-Reply not only provides information to be put in the map-cache, but acts as an ackl now. If the Map-Request no…

That all fine. However, you don’t specify the behavior if the ack is not received. How/when is the message assumed to be lost? When should it be retransmitted? How often? When to give up? Should exponential backoff be used? This whole part s completely missing in the spec.

> I disagree. I think its simpler with IPv4 addresses and shouldn’t matter. We want this complex concept to come across as clear as possible. And I believe IPv6 doesn’t do that. This is not a v4 vers…

I will let the INT AD to give further guidance, however, general guidance in the iETF is that IPV6 should also be provided in examples to avoid a bias towards IPv4. I disagree that an IPv6 example would be an more complicated than an IPv4 example.

> Can you cite where this is a problem. Are you saying we are not supplying enough MUST text?

In section 8.2 a few SHOULDs are used but no discussion about when it would be appropriate to not follow these SHOULDs. Further these SHOULDs mainly just say what should be implemented and provided, however there is no normative language that these endpoint SHOULD/MUST actually be authenticated or that the configured EID-Prefixes list MUST be enforced.

> No it doesn’t. It depends on the address-family of the map-resolver. And that is configured.

Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how can I copy the "the data packet's destination address“ which is IPv4 in to the "destination IP address used for the Map-Request“ which is IPv6? Or even worse, the other way around.

> But all address-families are used all the time. And in some ITRs, usually there is no IPv6 at the edge. 

What? You say all address families are used all the time but not in some ITRs…? I don’t understand what you want to say. However, if e.g. an IPv4 packet is received and processed, it probably doesn’t make sense to only include the IPv6 locator address (and not the IPv4 locator address), especially as it is unknown if the ITR support IPV6 (while it has been proven to support IPv4). Currently the spec however would allow that. I’m saying it should to make sure there is no unnecessary failure case her.

> It means the ITR will load-split according to hashing. Versus if the priorities are not equal, it is the ETR deciding how packets ingress the LISP site.

This is not what the text says. Please clarify in the doc.

>>  specified in the original Map-Register message."

I would expect to still see more reasoning in the doc.

> What are you suggesting. A bracketed comment inline?

That or Deborah can note in in the RFC editor note.

Thanks!
Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Wed, 12 Sep 2018 12:48:38 +0200

Hi Luigi,

please see below.

> Am 12.09.2018 um 09:30 schrieb Luigi Iannone <[email-masked]>:
> 
> Hi,
> 

Actually I brought this up because there were more cases where I found that ALT knowledge is needed. If you don’t want this to be a normative reference and remove the sentence above (which I’m not sure is helpful), please also double-check all other occurrences of ALT and make sure the discussed case is also understandable without ALT knowledge.

> Hence, the documents do not really need to be normative.

Okay, that these bits can be ignored should be stated in the doc!

Mirja

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 12 Sep 2018 15:03:57 -0700

Hi Luigi,
> Actually I brought this up because there were more cases where I found that ALT knowledge is needed. If you don’t want this to be a normative reference and remove the sentence above (which I’m not…

I think it should left in and we should add LISP-DDT to the paragraph. Since the two mapping transport systems that have moved forward to RFC are ALT and DDT. And I believe they should both be Normative References.

> Okay, that these bits can be ignored should be stated in the doc!

I will add text for this.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 13 Sep 2018 09:58:47 +0200

Hi Dino,

> On 13 Sep 2018, at 00:03, Dino Farinacci <[email-masked]> wrote:
> 
>> 

I disagree on the approach. IMO it makes more sense to me that this document describes just the Map-Server/Map-Resolver front end. 
How the front-end works with the actual mapping system is a matter of the specific mapping system.
In other words, how Map-Server/Map-Resolver works with LISP-DDT should be in the LISP-DDT document. Ditto for LISP+ALT.

> I think it should left in and we should add LISP-DDT to the paragraph. Since the two mapping transport systems that have moved forward to RFC are ALT and DDT. And I believe they should both be Norm…

This  means two downrefs. We will need to move them to PS.
I really do not see the need for this but YMMV.

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Sep 2018 08:17:02 -0700

> On Sep 13, 2018, at 12:58 AM, Luigi Iannone <[email-masked]> wrote:
> 
> Hi Dino,
> 

I can go along with this. I have wordsmithed that paragraph to not mention LISP-ALT.

> I really do not see the need for this but YMMV.

I will keep then as Informative references. And to address Mirja’s comment about believing that a reader would need to know more about ALT and DDT, I would respond to say, that the documentation is saying that a map-server and map-resolver are last-hops/first-hops to ANY mapping database transport system. So you can treat it as a black box. The operation of these nodes are discussed in the approprorate mapping database transport systems (such as LISP-ALT and LISP-DDT).

There are also refernces to LISP-ALT (and LISP-DDT) when we have the option for xTRs to be directlry part of the mapping system. This may be a choice for LISP deployers when they want a less centralized mapping system. Again, there are just references that in this case, the xTRs are “first-hop/last-hop” nodes of these mapping database systems.

How does that sound Mirja?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Sep 2018 08:29:47 -0700

Okay, I will do that. I’m working through your other comments today, as well as Colin’s. I’ll send a diff before submitting so we don’t churn too much. Thanks again!

Dino

> On Sep 13, 2018, at 8:28 AM, Mirja Kuehlewind (IETF) <[email-masked]> wrote:
> 
> This sounds all fine to me. Please just make sure that the text reflects that accordingly everywhere where ALT is mentioned at the moment and respectively make it more generic if needed. I trust you, you will edit this correctly!
> 
>> Am 13.09.2018 um 17:17 schrieb Dino Farinacci <[email-masked]>:
>> 
>> 
>>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 13 Sep 2018 17:28:50 +0200

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Sep 2018 14:46:03 -0700

I have a new diff file for -15 of 6833bis. I have included changes from your emails and from Colin’s. See my responses inline. I have trimmed a bit of text to hopefully make it more readable for others.

I will only submit the new revision if you agree with the changes and there are no objections from 	the LISP working group. Thanks in advance.

> I guess this sentence should be revised then.

Fixed.

> This should be stated in section 18.

Done.

> This is a different issue. The control plane protocol as specified in this doc also needs to consider fragmentation and MTU. Please read RFC8085 accordingly.

I have added text per Colin’s comments.

> I didn’t find a reference in -14. However a reference is not enough, the specified behavior is not appropriate and needs to change. If you need further help, please consult the respective transport…

I have added text. We have a smaller interval because 3 seconds is way too long (arguably 1 seond is too) to populate a map-cache. Note during that time, packets that arrive to the ITR are discarded. So this occurs if just one Map-Request is lost.

> Not sure if that is the right choice because it may interact badly with loss detection. However, as I said the specified behavior need to be refined at various places in the doc.

Well there is not many choices.

> I think clear default guidance must be given in this document. My main problem is that the guidance here is not clear (in relation to other rate limits).

I have tightened it up.

> If you detect loss, you should send slower not faster for congestion collapse avoidance.

That was my point.

> That fine but you also need to specify normatively an upper bound.

The recommended upper bound is 1 minute. If you are not getting your point across, please be more specific.

> That all fine. However, you don’t specify the behavior if the ack is not received. How/when is the message assumed to be lost? When should it be retransmitted? How often? When to give up? Should ex…

Have added text.

> Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how can I copy the "the data packet's destination address“ which is IPv4 in to the "destination IP address used for the Map-Request“…

Because a Map-Request going to the mapping system is “ECM’ed” “Encapsulated Control Message” with the header address-family as the EID being requested.

> What? You say all address families are used all the time but not in some ITRs…? I don’t understand what you want to say. However, if e.g. an IPv4 packet is received and processed, it probably doesn…

RLOCs for an xTR can be a collection of IPv4 and IPv6 addresses. They are tested by remote ITRs to see if they are reachable. When they are, they may be used. When they are not, no packets get encapsulated to those RLOCs.

The Routing Locator Reachability section explains this.

> This is not what the text says. Please clarify in the doc.

It says it in RFC6830bis since this decision is done by the data-plane.

>> Yes, I changed to SHOULD NOT. Good catch. Don’t want to make it a MUST NOT because both sides could be mobile and the remote side may need to populate its map-cache. That would allow less packet l…

While trying to change it, I noticed its already there:

	<t>When an ITR receives an SMR-based Map-Request for                           
         which it does not have a cached mapping for the EID in                         
>>>>     the SMR message, it SHOULD NOT send an SMR-invoked                             
         Map-Request. This scenario can occur when an ETR sends                         
         SMR messages to all Locators in the Locator-Set it has                         
         stored in its Map-Cache but the remote ITRs that receive the                   
         SMR may not be sending packets to the site. There is no                        
         point in updating the ITRs until they need to send, in                         
         which case they will send Map-Requests to obtain a                             
         Map-Cache entry.</t>

> I would expect to still see more reasoning in the doc.

Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers this is normal behavior that a request is sent to a well-known port and a reply is sent *from* the well known port.

Thanks again for all the effort,
Dino

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 14 Sep 2018 09:47:14 -0500

> I will let the INT AD to give further guidance, however, general guidance in the iETF is that IPV6 should also be provided in examples to avoid a bias towards IPv4. I disagree that an IPv6 example…

There is an IAB statement that is relevant here
(https://www.iab.org/2016/11/07/iab-statement-on-ipv6/):

[...]
We recommend that all networking standards assume the use of IPv6, and be
written so they do not require IPv4. We recommend that existing standards
be reviewed to ensure they will work with IPv6, and use IPv6 examples.
[...]

-Benjamin

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 14 Sep 2018 09:50:42 -0700

Changed. See diff enclosed. Uses prefix 2001:db8::/16 for the example.

Dino

> On Sep 14, 2018, at 7:47 AM, Benjamin Kaduk <[email-masked]> wrote:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 18 Sep 2018 13:05:49 +0200

Hi Dino,

please see below.

> Am 13.09.2018 um 23:46 schrieb Dino Farinacci <[email-masked]>:
> 

The sentence still talked about „future version of the protocol“. Is that still necessary? 

>> This should be stated in section 18.

I would specifically state here that for that reason no interop problems are expected.

> I have added text per Colin’s comments.

Just pointing to RFC8085 is not enough. This spec must specify that messages MUST not exceed the MTU and fragmentation should not be used. And further either recommend to use MTU discovery or just restrict the message size according to the recommendations in RFC8085. I would recommend to just do the later for simplicity.

> I have added text. We have a smaller interval because 3 seconds is way too long (arguably 1 seond is too) to populate a map-cache. Note during that time, packets that arrive to the ITR are discarde…

As I said, just providing a pointer to RFC8085 is not sufficient. 

> Well there is not many choices.

You can choose to not have this rate limiting but limit the total number of request per requesting router per time interval. That would trigger a reply immediately but still limit the total load in case of „bad-actors“.

>> I think clear default guidance must be given in this document. My main problem is that the guidance here is not clear (in relation to other rate limits).

I don’t think I saw any change in the diff you’ve attached. Please explain what you did.

>> If you detect loss, you should send slower not faster for congestion collapse avoidance.

Should should instead specify a similar loss detection and retransmission mechanism for Map-Request as now done for Map-Notify. The rate-limit alone is not helpful.

> The recommended upper bound is 1 minute. If you are not getting your point across, please be more specific.

Then you have to say „MUST NOT send more than one message per minutes“. The current text just gives a recommendation what a go value might be but does not specify an actually limit.

Thanks!

Not sure I understand the first sentence:

„A sender of an unsolicited Map-Notify message (one that is not used	
 	   as an acknowledgment to a Map-Register message) will follow the	
 	   Congestion Control And Relability Guideline sections of [RFC8085].“

The rest of the text is fine and gives a good spec. I think it is okay to mention that that spec is inline with RFC8085 but other than that I’m not sure what this first sentence is telling me…?

And also the last sentence is not fully clear:

"After this time, the Map-	
 	   Notify sender can only get the RLOC-set change by later querying the	
 	   mapping system or by RLOC-probing one of the RLOCs of the existing	
 	   cached RLOC-set to get the new RLOC-set.“

I don’t think there should be an attempt to later try again. Probably the system should log or notify an error instead. However, if it makes sense to try later again you have to specify what later means (hours, days?) and how often it should try again before it finally gives up and logs an error.

> Because a Map-Request going to the mapping system is “ECM’ed” “Encapsulated Control Message” with the header address-family as the EID being requested.

You say that if the EID send e.g. an IPv4 message it also has to be encapsulated in IPv4? That is stated nowhere. If that is the intention that has to be specified. However, I don’t really see why this restriction needs to exists…?

> The Routing Locator Reachability section explains this.

This is all understood. I’m still wondering if there should be more normative recommendations which locator addresses should be included. 

> It says it in RFC6830bis since this decision is done by the data-plane.

I still think the text in this doc is not correct.

>         which case they will send Map-Requests to obtain a                             

Good. Thanks! I guess that was changed based on someone else comment already.

> Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers this is normal behavior that a request is sent to a well-known port and a reply is sent *from* the well known port.

Okay, then I still don’t understand WHY this is done?

Mirja

> <rfcdiff-6833bis.html>

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 18 Sep 2018 09:24:06 -0700

Snipping a bit of text to keep the email more readable.

> The sentence still talked about „future version of the protocol“. Is that still necessary? 

Beacuse it is still true.

> I would specifically state here that for that reason no interop problems are expected.

I think it is clear enough and we shouldn’t over think this.

> Just pointing to RFC8085 is not enough. This spec must specify that messages MUST not exceed the MTU and fragmentation should not be used. And further either recommend to use MTU discovery or just…

I cannot say that or else we invalidate curernt implementations. We do this and people see the implementations are different than the spec, then the spec lacks credability.

> As I said, just providing a pointer to RFC8085 is not sufficient. 

Well I think it is.

> You can choose to not have this rate limiting but limit the total number of request per requesting router per time interval. That would trigger a reply immediately but still limit the total load in…

You have to be careful what is added or else it will not reflect implementations. We have made it a goal to keep the implementations and IETF specs in sync and didn’t want to repeat issues BGP had in the 90s (and to this day actually).

> Should should instead specify a similar loss detection and retransmission mechanism for Map-Request as now done for Map-Notify. The rate-limit alone is not helpful.

No. Because Map-Notify is just moving a single message for a particular reason. The Map-Request is used for a variety of reasons and the rate-limiting is built into the cache management algorithms.

> Then you have to say „MUST NOT send more than one message per minutes“. The current text just gives a recommendation what a go value might be but does not specify an actually limit.

You can’t say that because deregisters are Map-Registers with a TTL of 0 and can be triggered. I really think the text is fine.

> I don’t think there should be an attempt to later try again. Probably the system should log or notify an error instead. However, if it makes sense to try later again you have to specify what later…

Did you read the latest version of this paragraph that Albert commented on. It reads much better.

> You say that if the EID send e.g. an IPv4 message it also has to be encapsulated in IPv4? That is stated nowhere. If that is the intention that has to be specified. However, I don’t really see why…

Let me explain. If you are sending a Map-Request for an IPv4 EID, you build an IPv4 Map-Request. Before sending it it is wrapped with an ECM header and then sent to the Map-Resolver. The IP header wrapped around the ECM header is the address family of the configured Map-Resolver. All 4 combinations work and is deployed.

> Okay, then I still don’t understand WHY this is done?

The interoperability reference is a cisco implementation issue. And I won’t comment why it was done this way, lots of historical details.

Dino