Subject: [lisp] Confirm/Deny changes on draft 6830bis

From: Albert Cabellos <[email-masked]>
Date: Fri, 12 Jan 2018 17:20:39 +0100

Hi all

As editor of 6830bis I´d like to confirm or deny the following changes
which I believe have support.

Please note that I have intentionally ignored minor/editorial changes to
help sync all the participants. I hope that the list below captures the
most relevant ones.

Also note that I don´t necessarily agree with all the changes listed below,
but that´s an opinion with a different hat.

WG: Please CONFIRM or DENY:

-------

A.- Remove definitions of PA and PI

B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and
‘identifier of the underlay’ respectively.

C.- In section 5.3, change the description of the encap/decap operation
concerning how to deal with ECN and DSCP bits to (new text needs to be
validated by experts):

When doing ITR/PITR encapsulation:

o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case
of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.

o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy
the 2-bit 'ECN' field from the inner header to the outer header.
Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer
header to the new outer header.

When doing ETR/PETR decapsulation:

 o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the
case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field,
when the Time to Live value of the outer header is less than the Time to
Live value of the inner header.  Failing to perform this check can cause
the Time to Live of the inner header to increment across
encapsulation/decapsulation cycles.  This check is also performed when
doing initial encapsulation, when a packet comes to an ITR or PITR destined
for a LISP site.

o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or
the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the
outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
considering the exception listed below.

o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the
IPv6 'Traffic Class' field) requires special treatment in order to avoid
discarding indications of congestion [RFC3168]. If the 'ECN' field contains
a congestion indication codepoint (the value is '11', the Congestion
Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit
'ECN' field from the stripped outer header to the surviving inner header
that is used to forward the packet beyond the ETR.  These requirements
preserve CE indications when a packet that uses ECN traverses a LISP tunnel
and becomes marked with a CE indication due to congestion between the
tunnel endpoints.

Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate
after decapsulating, the net effect of this is that the new outer header
will carry the same Time to Live as the old outer header minus 1.

Copying the Time to Live (TTL) serves two purposes: first, it preserves the
distance the host intended the packet to travel; second, and more
importantly, it provides for suppression of looping packets in the event
there is a loop of concatenated tunnels due to misconfiguration.  See
Section 18.3 for TTL exception handling for traceroute packets.

D.- Simplify section ‘Router Locator Selection’ stating that the data-plane
MUST follow what´s stored in the map-cache (priorities and weights), the
remaining text should go to an OAM document.

E.- Rewrite Section “Routing Locator Reachability” considering the
following changes:

*    Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and
Echo-Nonce
*    Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3
(hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a
response) and RLOC probing

F.- Move Solicit-Map-Request to 6833bis

G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement
Considerations), 18 (Traceroute Consideration) to a new OAM document

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 12 Jan 2018 11:01:02 -0800

> Hi all
> 
> As editor of 6830bis I´d like to confirm or deny the following changes which I believe have support. 

Thanks a lot for doing this Albert. This is very helpful.

> Please note that I have intentionally ignored minor/editorial changes to help sync all the participants. I hope that the list below captures the most relevant ones.
> 
> Also note that I don´t necessarily agree with all the changes listed below, but that´s an opinion with a different hat.

See my brief comments below.

> WG: Please CONFIRM or DENY:

I won’t confirm or deny just yet. I want to hear from other WG members.

> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and ‘identifier of the underlay’ respectively. 

These definitions would be confusing. Because there are multiple identifiers on an overlay. And there are multiple overlays as well. And an instance-ID really defines an overlay. Also, putting the term “identifier” with the underlay would confuse many people. It has been decades where people redefine these terms. It just seems endless and doesn’t improve the situation. And note there isn’t one identifier for an underlay either. One could argue that an underlay VPN could be RLOC space that is different than another underlay VPN. But what identifies that VPN is the mechanism used to realize that VPN and not the RLOCs that use it.

> C.- In section 5.3, change the description of the encap/decap operation concerning how to deal with ECN and DSCP bits to (new text needs to be validated by experts):

These changes are reasonable. I am fine with adding them.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 15 Jan 2018 10:56:16 +0100

Should I review 09 or 08?

But please once you reply to this mail than you stick to the decision until I review the document.

L.

> On 13 Jan 2018, at 19:30, Dino Farinacci <[email-masked]> wrote:
> 
> Here is a -09 proposal to add your requested change C below. All the other points are still open for discussion.
> 
> Dino
> 
> <rfcdiff.html>
> 
> <draft-ietf-lisp-rfc6830bis-09.txt>
> 
>> On Jan 12, 2018, at 8:20 AM, Albert Cabellos <[email-masked]> wrote:
>> 
>> Hi all
>> 
>> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
>> 
>> o  The outer-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the inner-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below.
>> 
>> o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner header to the outer header. Re-encapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the new outer header.
>> 
>> o  The inner-header 'Time to Live' field (or 'Hop Limit' field, in the case of IPv6) SHOULD be copied from the outer-header 'Time to Live' field, when the Time to Live value of the outer header is less than the Time to Live value of the inner header.  Failing to perform this check can cause the Time to Live of the inner header to increment across encapsulation/decapsulation cycles.  This check is also performed when doing initial encapsulation, when a packet comes to an ITR or PITR destined for a LISP site.
>> 
>> o  The inner-header 'Differentiated Services Code Point' (DSCP) field (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from the outer-header DSCP field ('Traffic Class' field, in the case of IPv6) considering the exception listed below.
>> 
>> o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of the IPv6 'Traffic Class' field) requires special treatment in order to avoid discarding indications of congestion [RFC3168]. If the 'ECN' field contains a congestion indication codepoint (the value is '11', the Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped outer header to the surviving inner header that is used to forward the packet beyond the ETR.  These requirements preserve CE indications when a packet that uses ECN traverses a LISP tunnel and becomes marked with a CE indication due to congestion between the tunnel endpoints.
>> 
>> Note that if an ETR/PETR is also an ITR/PITR and chooses to re-encapsulate after decapsulating, the net effect of this is that the new outer header will carry the same Time to Live as the old outer header minus 1.
>> 
>> Copying the Time to Live (TTL) serves two purposes: first, it preserves the distance the host intended the packet to travel; second, and more importantly, it provides for suppression of looping packets in the event there is a loop of concatenated tunnels due to misconfiguration.  See Section 18.3 for TTL exception handling for traceroute packets.
>> 
>> D.- Simplify section ‘Router Locator Selection’ stating that the data-plane MUST follow what´s stored in the map-cache (priorities and weights), the remaining text should go to an OAM document.
>> 
>> E.- Rewrite Section “Routing Locator Reachability” considering the following changes:
>> 
>> *    Keep bullet point 1 (examine LSB), 6 (receiving a data-packet) and Echo-Nonce
>> *    Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response) and RLOC probing
>> 
>> 
>> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement Considerations), 18 (Traceroute Consideration) to a new OAM document
>> 
>> 
>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 15 Jan 2018 11:00:41 +0100

Thanks for this Albert.

> WG: Please CONFIRM or DENY:

<chair hat on>

Folks,

Albert did a very helpful thing by writing this summary.

Pleas ALL provide feedback!

Summary is short and to the point, so it will not take you days to read it.

Thank you all for the effort.

Ciao

L.

<chair hat off>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 15 Jan 2018 09:57:36 -0800

> Should I review 09 or 08?

It would be better to do -09. If I had known comments were coming from you I would have waited to put in Albert’s text. What I did in -09 is simply cut-and-paste his text.

> But please once you reply to this mail than you stick to the decision until I review the document.

I won’t make any other changes until I see your comments.

Dino

---

From: Alberto Rodriguez-Natal <[email-masked]>
Date: Tue, 16 Jan 2018 22:25:17 +0100

Thanks for the summary Albert. I can confirm a few points but I prefer
to abstain on those I don't have a strong opinion. Answers and
comments inline.

Thanks,
Alberto

> A.- Remove definitions of PA and PI

Confirm.

I'm fine with LISP not being so focused on the original Internet use-case.

> ‘identifier of the underlay’ respectively.

Abstain.

I'd prefer to avoid using "identifier" in anything regarding the
underlay but I could be fine with the proposed text.

> concerning how to deal with ECN and DSCP bits to (new text needs to be

Confirm.

The new text looks good to me.

> remaining text should go to an OAM document.

Abstain.

I see the value of an independent OAM document but I don't see it as a
requirement to advance 6830bis.

> *    Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3 (hints
> from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response)
> and RLOC probing

Abstain.

I'd personally prefer to move those mechanisms that rely on
control-plane messages (i.e. 5 - receive a MapReply) to the
control-plane document but I'd not oppose to keep them on the
data-plane doc.

> F.- Move Solicit-Map-Request to 6833bis

Confirm.

This is one of the major results I hope to see out of this discussion.

> Considerations), 18 (Traceroute Consideration) to a new OAM document

Abstain.

Same comment as above regarding a separate OAM document.

---

From: Fabio Maino <[email-masked]>
Date: Thu, 18 Jan 2018 13:56:24 -0800

On 1/12/18 8:20 AM, Albert Cabellos wrote:
> Please note that I have intentionally ignored minor/editorial changes 
> to help sync all the participants. I hope that the list below captures 
> the most relevant ones.
>
> Also note that I don´t necessarily agree with all the changes listed 
> below, but that´s an opinion with a different hat.
>
confirm.

I think one of the goals of the charter was to to open up to a broad set 
of use cases where that terminology might not be meaningful.

>
> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ 
> and ‘identifier of the underlay’ respectively.

personally, I'm not keen to this change of terminology.

EID and RLOC have become of common use, and well understood, even 
outside of the LISP circles. I've often assisted to conversations in 
non-LISP groups where people use the term LISP EID/RLOC to qualify IP 
addresses in the overlay/underlay.

>
> C.- In section 5.3, change the description of the encap/decap 
> operation concerning how to deal with ECN and DSCP bits to (new text 
> needs to be validated by experts):
>
>     o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in
>     the case of IPv6) SHOULD be copied from the inner-header 'Time to
>     Live' field.
>
>     o  The outer-header 'Differentiated Services Code Point' (DSCP)
>     field (or the 'Traffic Class' field, in the case of IPv6) SHOULD
>     be copied from the inner-header DSCP field ('Traffic Class' field,
>     in the case of IPv6) considering the exception listed below.
>
>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and
>     7 of the IPv6 'Traffic Class' field) requires special treatment in
>     order to avoid discarding indications of congestion [RFC3168]. ITR
>     encapsulation MUST copy the 2-bit 'ECN' field from the inner
>     header to the outer header. Re-encapsulation MUST copy the 2-bit
>     'ECN' field from the stripped outer header to the new outer header.
>
>      o  The inner-header 'Time to Live' field (or 'Hop Limit' field,
>     in the case of IPv6) SHOULD be copied from the outer-header 'Time
>     to Live' field, when the Time to Live value of the outer header is
>     less than the Time to Live value of the inner header.  Failing to
>     perform this check can cause the Time to Live of the inner header
>     to increment across encapsulation/decapsulation cycles.  This
>     check is also performed when doing initial encapsulation, when a
>     packet comes to an ITR or PITR destined for a LISP site.
>
>     o  The inner-header 'Differentiated Services Code Point' (DSCP)
>     field (or the 'Traffic Class' field, in the case of IPv6) SHOULD
>     be copied from the outer-header DSCP field ('Traffic Class' field,
>     in the case of IPv6) considering the exception listed below.
>
>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and
>     7 of the IPv6 'Traffic Class' field) requires special treatment in
>     order to avoid discarding indications of congestion [RFC3168]. If
>     the 'ECN' field contains a congestion indication codepoint (the
>     value is '11', the Congestion Experienced (CE) codepoint), then
>     ETR decapsulation MUST copy the 2-bit 'ECN' field from the
>     stripped outer header to the surviving inner header that is used
>     to forward the packet beyond the ETR.  These requirements preserve
>     CE indications when a packet that uses ECN traverses a LISP tunnel
>     and becomes marked with a CE indication due to congestion between
>     the tunnel endpoints.
>
>     Note that if an ETR/PETR is also an ITR/PITR and chooses to
>     re-encapsulate after decapsulating, the net effect of this is that
>     the new outer header will carry the same Time to Live as the old
>     outer header minus 1.
>
>     Copying the Time to Live (TTL) serves two purposes: first, it
>     preserves the distance the host intended the packet to travel;
>     second, and more importantly, it provides for suppression of
>     looping packets in the event there is a loop of concatenated
>     tunnels due to misconfiguration.  See Section 18.3 for TTL
>     exception handling for traceroute packets.
>
>
Confirm.

> D.- Simplify section ‘Router Locator Selection’ stating that the 
> data-plane MUST follow what´s stored in the map-cache (priorities and 
> weights), the remaining text should go to an OAM document.
Confirm on the section semplification.

Wrt putting the rest in a separate OAM document, I don't have a strong 
opinion. Probably not having a new document requires less work to be 
done that makes me lean toward NOT having a new OAM document.

>     *    Move to 6833bis bullet point 2 (ICMP Network/Host
>     Unreachable),3 (hints from BGP),4 (ICMP Port Unreachable),5
>     (receive a Map-Reply as a response) and RLOC probing
>
>

Confirm.

Confirm.
> Considerations), 18 (Traceroute Consideration) to a new OAM document

I'm fine with both options. Probably not having a new document requires 
less work to be done that makes me lean toward NOT having a new OAM 
document.

Thanks,
Fabio

>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 23 Jan 2018 12:21:19 +0100

Hi Albert ,

you find my comments inline.

Thanks again for your work.

Ciao

L.

> A.- Remove definitions of PA and PI

Agree.

> B.- Change definitions of EID and RLOC as ‘identifier of the overlay’ and ‘identifier of the underlay’ respectively. 

For the RLOC I would put modify the definition as follows:

Routing Locator (RLOC):   An RLOC is an IPv4 [RFC0791] or IPv6
      [RFC8200] address of an Egress Tunnel Router (ETR).  An RLOC is
      the output of an EID-to-RLOC mapping lookup.  An EID maps to one
      or more RLOCs.  Typically, RLOCs are numbered from address blocks 
     assigned to a site at each point to which it attaches to the underlay 
     network, as such they represent the identifiers of the underlay.
      Multiple RLOCs can be assigned to the same ETR device or to 
      multiple ETR devices at a site.

> C.- In section 5.3, change the description of the encap/decap operation concerning how to deal with ECN and DSCP bits to (new text needs to be validated by experts):

Agree. 

> D.- Simplify section ‘Router Locator Selection’ stating that the data-plane MUST follow what´s stored in the map-cache (priorities and weights), the remaining text should go to an OAM document.

Agree

> *    Move to 6833bis bullet point 2 (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port Unreachable),5 (receive a Map-Reply as a response) and RLOC probing

Agree

> F.- Move Solicit-Map-Request to 6833bis

Agree

> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement Considerations), 18 (Traceroute Consideration) to a new OAM document

Agree

I would like to add a _personal_ opinion about the OAM document.
Looks like OAM is a good idea but concern has been expressed on whether adding a document would slow down the progress.

I do not think this will happen. OAM is just a cut&paste of existing text on which no technical comments on the content itself has been made.
As such creating OAM is a one hour job and since the content is stable text that has been reviewed extensively I do not see any issue in adopting the document right away (ideally in parallel with last call of 6830bis).
After such step we check consistency with 6833bis and we last call both 6833bis and AOM in parallel.

So no additional time.

Again, this is my personal view but I believe that is definitively doable.

Ciao

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Jan 2018 07:11:55 -0800

>       multiple ETR devices at a site.

Adding “identifier of the underlay” does not improve or simplify the definition. It makes it more confusing IMO. People will interpret LISP has IDs in the underlay. Note in dozens of conversations I've had with people on LISP who are new to the concepts refer to RLOCs as “routing IDs”. And then when I ask them to clarify if they mean “EIDs” or “RLOCs”, they say “oh EIDs”.

The definition above will not help with this confusion.

I would like to keep the definition as is with your edits from your lastest commentary review.

Thanks,
Dino

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 24 Jan 2018 14:12:38 +0100

> On 23 Jan 2018, at 16:11, Dino Farinacci <[email-masked]> wrote:
> 

I don’t have a strong opinion on this point. You can keep the original text if you wish.

L.

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 25 Jan 2018 15:10:54 +0100

Dear Dino and Albert

The doc reads well.
Please find thereafter some comments on the version- 09 you posted on the
list

Page 4
*"Client-side:  Client-side is a term used in this document to indicate a
connection initiation attempt by an EID."*

PPE 1: Strictly speaking the EID is just an identifier and does not
initiate anything. Suggest something like this.

*"Client-side:  Client-side is a term used in this document to indicate a
connection initiation attempt by the end system (represented by an EID)"*

Page 6
*The source EID is obtained via existing mechanisms used to set a host's
"local" IP address.  An EID used on the public Internet must have the same
properties as any other IP address used in that manner; this means, among
other things, that it must be globally unique.*

PPE 2: Shouldn't these two be MUST rather than must? Suggestion below
*The source EID is obtained via existing mechanisms used to set a host's
"local" IP address.  An EID used on the public Internet MUST have the same
properties as any other IP address used in that manner; this means, among
other things, that it MUST be globally unique.*

Page 8
*An EID maps to one or more RLOCs.*

PPE 3: Seems to contradict earlier explanation on negative mapping entry
where it is possible that an EID has NO RLOC.

*Page 8 *
*When using multiple mapping database systems, care must be taken to not
create re-encapsulation loops through misconfiguration.*

PPE 4: Suggest to add "re-encapsulation" in the list in Security
Considerations section as this is an exploit possibility.

Page 13
*"gleaned" mapping*

PPE 5: Suggest adding “glean mapping” in the definition section.

Page 17
*"The KK-bits are a 2-bit field used when encapsualted packets
are encrypted."*

PPE 6: Nit - Typo "*encapsualted" -> "**encapsulated"*

Page 20
*"When the lookup succeeds, the locator-set  retrieved from the map-cache
is used to send the packet to the EID's topological location."*

PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency
with rest of document.

Page 23
"*The server-side sets a Weight of 0..."*

PPE 8: Nit - For consistency in text change to "Weight of zero".
Page 23
"*Control is shared by the server- side determining the list and the client
determining load  distribution." *

PPE 9: Suggest use of "Client-side"

*"Control is shared by the server- side determining the list and the
client-side determining load distribution."*

Page 24
*When a verified Map-Cache entry is stored, data gleaning no longer occurs
for subsequent packets that have a source EID that matches*
*the EID-Prefix of the verified entry.[PE1]   This "gleaning" mechanism is
OPTIONAL.*

PPE 10: In section 16.2 later gleaning is used as a solution.  Changes in
the gleaned info could be an interesting way to update the cache fast
…however this text make it sound that this is not an option after first
packet.

Page 25
"Note that trusting ICMP messages may  not be desirable, but neither is
ignoring them completely. Implementations are encouraged to follow current
best practices in treating these conditions."

PPE 11: A reference would be useful if possible.

Page 25

*"An ITR that participates in the global routing system can determine that
an RLOC is down if no BGP Routing Information Base (RIB) route exists that
matches the RLOC IP address."*

PPE 12: Isn't this true for any protocol entry not just a BGP entry? We are
really trying to determine if there is no route whatever the protocol.

Page 38
*"For a more detailed networkd design deployment recommendation, refer to
[RFC7215]."*

PPE 13: Nit typo "netword"-> "network"
Page 40
*"By having the PE be the first router on the path to encapsulate, it can
choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for
a new encapsuluation path to the destination end site."*

PPE 14: Nit Typo "*encapsuluation" -> "encapsulation"*

Page 43
"*If the attacker spoofs the source RLOC, it can mount a DoS attack by
redirecting traffic to the spoofed victim;s RLOC, potentially overloading
it."*

PPE 15: Nit  typo "*victim;s" -> "**victim's"*

Thanks
Padma

On Mon, Jan 15, 2018 at 6:57 PM, Dino Farinacci <[email-masked]> wrote:

> It would be better to do -09. If I had known comments were coming from you
> I would have waited to put in Albert’s text. What I did in -09 is simply
> cut-and-paste his text.
>
> >> Here is a -09 proposal to add your requested change C below. All the
> other points are still open for discussion.
> >>
> >> Dino
> >>
> >> <rfcdiff.html>
> >>
> to help sync all the participants. I hope that the list below captures the
> most relevant ones.
> >>>
> operation concerning how to deal with ECN and DSCP bits to (new text needs
> to be validated by experts):
> >>>
> >>> o  The outer-header 'Time to Live' field (or 'Hop Limit' field, in the
> case of IPv6) SHOULD be copied from the inner-header 'Time to Live' field.
> >>>
> >>> o  The outer-header 'Differentiated Services Code Point' (DSCP) field
> (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from
> the inner-header DSCP field ('Traffic Class' field, in the case of IPv6)
> >>> o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of
> the IPv6 'Traffic Class' field) requires special treatment in order to
> avoid discarding indications of congestion [RFC3168]. ITR encapsulation
> MUST copy the 2-bit 'ECN' field from the inner header to the outer header.
> >>> o  The inner-header 'Differentiated Services Code Point' (DSCP) field
> (or the 'Traffic Class' field, in the case of IPv6) SHOULD be copied from
> the outer-header DSCP field ('Traffic Class' field, in the case of IPv6)
> >>> o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 of
> the IPv6 'Traffic Class' field) requires special treatment in order to
> avoid discarding indications of congestion [RFC3168]. If the 'ECN' field
> contains a congestion indication codepoint (the value is '11', the
> Congestion Experienced (CE) codepoint), then ETR decapsulation MUST copy
> the 2-bit 'ECN' field from the stripped outer header to the surviving inner
> header that is used to forward the packet beyond the ETR.  These
> requirements preserve CE indications when a packet that uses ECN traverses
> a LISP tunnel and becomes marked with a CE indication due to congestion
> between the tunnel endpoints.
> >>>
> re-encapsulate after decapsulating, the net effect of this is that the new
> outer header will carry the same Time to Live as the old outer header minus
> 1.
> >>>
> preserves the distance the host intended the packet to travel; second, and
> more importantly, it provides for suppression of looping packets in the
> event there is a loop of concatenated tunnels due to misconfiguration.  See

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Thu, 25 Jan 2018 15:20:32 +0100

Hi Albert

Please find below my comments PPE

> A.- Remove definitions of PA and PI

<PPE> Confirm

> ‘identifier of the underlay’ respectively.

<PPE> Deny - Agree with some others on the list that this does not add much
for clarification.

> Copying the Time to Live (TTL) serves two purposes: first, it preserves
> the distance the host intended the packet to travel; second, and more
> <PPE>  Abstain for now

> <PPE> Confirm

> <PPE> Confirm see some of my comments on this on the thread.

> <PPE> Confirm

> Considerations), 18 (Traceroute Consideration) to a new OAM document
<PPE> Confirm

Thanks
Padma

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 26 Jan 2018 11:20:27 -0800

Thanks for the detail review Padma. A new update to -09 is enclosed with a diff file. I will wait until next week to post.

I have reflected all of your comments and most of Luigi’s comments. The only issues open are:

(1) Section movement from RFC6830 to RFC6833.

(2) If an OAM document is needed.

Waiting for more working group concensus on this.

> Dear Dino and Albert 
> 
> The doc reads well.
> Please find thereafter some comments on the version- 09 you posted on the list 
> 
> Page 4
> "Client-side:  Client-side is a term used in this document to indicate a connection initiation attempt by an EID."
> PPE 1: Strictly speaking the EID is just an identifier and does not initiate anything. Suggest something like this.
> 
> "Client-side:  Client-side is a term used in this document to indicate a connection initiation attempt by the end system (represented by an EID)”

Fixed. Put in your suggestion.

> Page 6
> The source EID is obtained via existing mechanisms used to set a host's "local" IP address.  An EID used on the public Internet must have the same properties as any other IP address used in that manner; this means, among other things, that it must be globally unique.
> 
> The source EID is obtained via existing mechanisms used to set a host's "local" IP address.  An EID used on the public Internet MUST have the same properties as any other IP address used in that manner; this means, among other things, that it MUST be globally unique.

Changed.

> Page 8
> An EID maps to one or more RLOCs.
> PPE 3: Seems to contradict earlier explanation on negative mapping entry where it is possible that an EID has NO RLOC.

I changed to “zero or more RLOCs.”.

> Page 8 
> When using multiple mapping database systems, care must be taken to not create re-encapsulation loops through misconfiguration.
> 
> PPE 4: Suggest to add "re-encapsulation" in the list in Security Considerations section as this is an exploit possibility.

I have removed the sentence. Because it actually is not true. If you use different mapping systems and circuitious forwarding occurs. The packet travels only until its TTL reaches 0. Using the rules for copy inner to outer and outer to inner during RTR re-encapsulation applies.

> "gleaned" mapping

Changed.

> Page 17
> "The KK-bits are a 2-bit field used when encapsualted packets are encrypted."
> 
> PPE 6: Nit - Typo "encapsualted" -> “encapsulated"

Fixed.

> 
> Page 20
> "When the lookup succeeds, the locator-set  retrieved from the map-cache is used to send the packet to the EID's topological location."
> 
> PPE 7: Nit - Suggest capitalize L and S of "locator-set" for consistency with rest of document.

Thanks. Done.

> 
> Page 23
> "The server-side sets a Weight of 0..."
> PPE 8: Nit - For consistency in text change to "Weight of zero”.

Changed.

> Page 23 
> "Control is shared by the server- side determining the list and the client determining load  distribution." 
> 
> "Control is shared by the server- side determining the list and the client-side determining load distribution.”

Done.

> Page 24
> When a verified Map-Cache entry is stored, data gleaning no longer occurs for subsequent packets that have a source EID that matches
> the EID-Prefix of the verified entry.[PE1]   This "gleaning" mechanism is OPTIONAL.
> 
> PPE 10: In section 16.2 later gleaning is used as a solution.  Changes in the gleaned info could be an interesting way to update the cache fast …however this text make it sound that this is not an option after first packet.

It is an option when the ETR has no mapping to return packets. Once a mapping is cache, there is no point to glean since the mapping system verified the information the same as in the map-cache.

>   
> Page 25
> "Note that trusting ICMP messages may  not be desirable, but neither is ignoring them completely. Implementations are encouraged to follow current best practices in treating these conditions."
> 

Added draft-ietf-opsec-icmp-filtering.

> Page 25
> "An ITR that participates in the global routing system can determine that an RLOC is down if no BGP Routing Information Base (RIB) route exists that matches the RLOC IP address."
> 
> PPE 12: Isn't this true for any protocol entry not just a BGP entry? We are really trying to determine if there is no route whatever the protocol.

Yes, we can generalize this. I changed text.

> Page 38
> "For a more detailed networkd design deployment recommendation, refer to [RFC7215]."
> 
> PPE 13: Nit typo "netword"-> “network"

Changed.

> Page 40
> "By having the PE be the first router on the path to encapsulate, it can choose a TE path first, and the ETR can decapsulate and Re-Encapsulate for a new encapsuluation path to the destination end site."
> 
> PPE 14: Nit Typo "encapsuluation" -> “encapsulation"

Changed.

> Page 43
> "If the attacker spoofs the source RLOC, it can mount a DoS attack by redirecting traffic to the spoofed victim;s RLOC, potentially overloading it."
> 

> PPE 15: Nit  typo "victim;s" -> “victim’s”

Changed.

Dino

---

From: Albert Cabellos <[email-masked]>
Date: Mon, 29 Jan 2018 02:57:01 +0100

Hi all

Thanks for all the comments, from my understanding of this thread the
following list of items *seem* to have rough consensus (all except B -
change definitions for EID and RLOC).

Joel, Luigi->How should we proceed now?

Albert

---

On Fri, Jan 26, 2018 at 8:20 PM, Dino Farinacci <[email-masked]> wrote:

> Thanks for the detail review Padma. A new update to -09 is enclosed with a
> diff file. I will wait until next week to post.
>
> > "Client-side:  Client-side is a term used in this document to indicate a
> connection initiation attempt by an EID."
> > "Client-side:  Client-side is a term used in this document to indicate a
> connection initiation attempt by the end system (represented by an EID)”
>
> > The source EID is obtained via existing mechanisms used to set a host's
> other things, that it must be globally unique.
> >
> > The source EID is obtained via existing mechanisms used to set a host's
> other things, that it MUST be globally unique.
>
> Changed.
>
> > Page 8
> > When using multiple mapping database systems, care must be taken to not
> create re-encapsulation loops through misconfiguration.
> >
> I have removed the sentence. Because it actually is not true. If you use
> different mapping systems and circuitious forwarding occurs. The packet
> travels only until its TTL reaches 0. Using the rules for copy inner to
> outer and outer to inner during RTR re-encapsulation applies.
>
> > Page 13
> > "gleaned" mapping
> >
> > "When the lookup succeeds, the locator-set  retrieved from the map-cache
> is used to send the packet to the EID's topological location."
> >
> > "Control is shared by the server- side determining the list and the
> client-side determining load distribution.”
>
> Done.
>
> > Page 24
> > When a verified Map-Cache entry is stored, data gleaning no longer
> occurs for subsequent packets that have a source EID that matches
> > PPE 10: In section 16.2 later gleaning is used as a solution.  Changes
> in the gleaned info could be an interesting way to update the cache fast
> It is an option when the ETR has no mapping to return packets. Once a
> mapping is cache, there is no point to glean since the mapping system
> verified the information the same as in the map-cache.
>
> >
> > Page 25
> > "An ITR that participates in the global routing system can determine
> that an RLOC is down if no BGP Routing Information Base (RIB) route exists
> that matches the RLOC IP address."
> >
> > PPE 12: Isn't this true for any protocol entry not just a BGP entry? We
> are really trying to determine if there is no route whatever the protocol.
>
> > "By having the PE be the first router on the path to encapsulate, it can
> a new encapsuluation path to the destination end site."
> >
> > "If the attacker spoofs the source RLOC, it can mount a DoS attack by
> it."

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 28 Jan 2018 19:07:59 -0800

Note A and C are addressed in the -09 revision I sent out in Friday. 

Dino

> On Jan 28, 2018, at 5:57 PM, Albert Cabellos <[email-masked]> wrote:
> 
> Hi all
> 
> Thanks for all the comments, from my understanding of this thread the following list of items *seem* to have rough consensus (all except B - change definitions for EID and RLOC).
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 28 Jan 2018 22:17:21 -0500

Assuming Luigi agrees, there should be a version of this dcoument 
submitted that incorporates what Dino did for A and C, and addresses D - G.

Yours,
Joel

On 1/28/18 10:07 PM, Dino Farinacci wrote:
> On Jan 28, 2018, at 5:57 PM, Albert Cabellos <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> Hi all
>>
>>     operation concerning how to deal with ECN and DSCP bits to (new
>>     text needs to be validated by experts):
>>
>>         o  The outer-header 'Time to Live' field (or 'Hop Limit'
>>         field, in the case of IPv6) SHOULD be copied from the
>>         inner-header 'Time to Live' field.
>>
>>
>>         o  The outer-header 'Differentiated Services Code Point'
>>         (DSCP) field (or the 'Traffic Class' field, in the case of
>>         IPv6) SHOULD be copied from the inner-header DSCP field
>>         ('Traffic Class' field, in the case of IPv6) considering the
>>         exception listed below.
>>
>>
>>         o  The 'Explicit Congestion Notification' (ECN) field (bits 6
>>         and 7 of the IPv6 'Traffic Class' field) requires special
>>         treatment in order to avoid discarding indications of
>>         congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit
>>         'ECN' field from the inner header to the outer header.
>>         Re-encapsulation MUST copy the 2-bit 'ECN' field from the
>>         stripped outer header to the new outer header.
>>
>>
>>          o  The inner-header 'Time to Live' field (or 'Hop Limit'
>>         field, in the case of IPv6) SHOULD be copied from the
>>         outer-header 'Time to Live' field, when the Time to Live value
>>         of the outer header is less than the Time to Live value of the
>>         inner header.  Failing to perform this check can cause the
>>         Time to Live of the inner header to increment across
>>         encapsulation/decapsulation cycles.  This check is also
>>         performed when doing initial encapsulation, when a packet
>>         comes to an ITR or PITR destined for a LISP site.
>>
>>
>>         o  The inner-header 'Differentiated Services Code Point'
>>         (DSCP) field (or the 'Traffic Class' field, in the case of
>>         IPv6) SHOULD be copied from the outer-header DSCP field
>>         ('Traffic Class' field, in the case of IPv6) considering the
>>         exception listed below.
>>
>>
>>         o  The 'Explicit Congestion Notification' (ECN) field (bits 6
>>         and 7 of the IPv6 'Traffic Class' field) requires special
>>         treatment in order to avoid discarding indications of
>>         congestion [RFC3168]. If the 'ECN' field contains a congestion
>>         indication codepoint (the value is '11', the Congestion
>>         Experienced (CE) codepoint), then ETR decapsulation MUST copy
>>         the 2-bit 'ECN' field from the stripped outer header to the
>>         surviving inner header that is used to forward the packet
>>         beyond the ETR.  These requirements preserve CE indications
>>         when a packet that uses ECN traverses a LISP tunnel and
>>         becomes marked with a CE indication due to congestion between
>>         the tunnel endpoints.
>>
>>
>>         re-encapsulate after decapsulating, the net effect of this is
>>         that the new outer header will carry the same Time to Live as
>>         the old outer header minus 1.
>>
>>
>>     data-plane MUST follow what´s stored in the map-cache (priorities
>>     and weights), the remaining text should go to an OAM document.
>>
>> On Fri, Jan 26, 2018 at 8:20 PM, Dino Farinacci <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     Thanks for the detail review Padma. A new update to -09 is
>>     enclosed with a diff file. I will wait until next week to post.
>>
>>     > "Client-side:  Client-side is a term used in this document to
>>     indicate a connection initiation attempt by the end system
>>     (represented by an EID)”
>>
>>     I have removed the sentence. Because it actually is not true. If
>>     you use different mapping systems and circuitious forwarding
>>     occurs. The packet travels only until its TTL reaches 0. Using the
>>     rules for copy inner to outer and outer to inner during RTR
>>     re-encapsulation applies.
>>
>>     > Page 13
>>     > "gleaned" mapping
>>     >
>>     > "Control is shared by the server- side determining the list and
>>     the client-side determining load distribution.”
>>
>>     Done.
>>
>>     > Page 24
>>     It is an option when the ETR has no mapping to return packets.
>>     Once a mapping is cache, there is no point to glean since the
>>     mapping system verified the information the same as in the map-cache.
>>
>>     >
>>     > Page 25

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 28 Jan 2018 19:17:40 -0800

> G.- Move sections 16 (Mobility Considerations), 17 (xTR Placement Considerations), 18 (Traceroute Consideration) to a new OAM document

For the record I don’t support this. It will slow down the process while the benefit won’t be worth the cost of an additional document IMO. 

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 29 Jan 2018 13:21:15 +0100

> On 29 Jan 2018, at 04:17, Joel M. Halpern <[email-masked]> wrote:
> 
> Assuming Luigi agrees, there should be a version of this dcoument submitted that incorporates what Dino did for A and C, and addresses D - G.

Yes, that works for me.

Thanks

Ciao

L.