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 <farina...@gmail.com> wrote:
> > 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
>
> >
> > L.
> >
> >
> >> On 13 Jan 2018, at 19:30, Dino Farinacci <farina...@gmail.com> 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 <
> albert.cabel...@gmail.com> wrote:
> >>>
> >>> 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
> >>>
> >>>
> >>
> >
>
> _______________________________________________
> 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
