Hello Dino,
Thanks for the efforts.
The propositions in -08 are fine but are addressing only minor
details. As long as the structure of the document is not
fundamentally re-worked the document will remain poor and
barely readable for who doesn’t know LISP yet.
I already clearly gave my comments about all this, I don’t need
to repeat myself.
Regards,
Damien Saucez
> On 9 Jan 2018, at 18:54, Dino Farinacci <farina...@gmail.com> wrote:
>
> Guys, please look at the latest changes instead of hashing the same
> arguments.
>
> This is what I am going to do. I am going to submit the myriad of changes
> already agreed to and then we can open up comments again for -08. I have been
> holding these diffs for a few weeks now and have received little commentary
> on the latest changes. So if your points have not been addressed, state them
> again AFTER reading the changes to -08.
>
> The diff of the changes are included yet again.
>
> Dino
>
> <rfcdiff-rfc6830bis.html>
>
>> On Jan 9, 2018, at 7:04 AM, Luigi Iannone <g...@gigix.net> wrote:
>>
>>
>> HI Albert,
>>
>> thanks for your reply.
>>
>> My comments inline. (trimming what is OK for me)
>>
>> Luigi
>>
>>> On 27 Dec 2017, at 02:48, Albert Cabellos <albert.cabel...@gmail.com> wrote:
>>>
>>
>> [snip]
>>>>
>>>>
>>>> Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for
>>>> IPv6) value used in the source and destination address fields of
>>>> the first (most inner) LISP header of a packet. The host obtains
>>>> a destination EID the same way it obtains a destination address
>>>> today, for example, through a Domain Name System (DNS) [RFC1034]
>>>> lookup or Session Initiation Protocol (SIP) [RFC3261] exchange.
>>>> 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. An EID is allocated to a host from an EID-Prefix block
>>>> associated with the site where the host is located. An EID can be
>>>> used by a host to refer to other hosts. Note that EID blocks MAY
>>>> be assigned in a hierarchical manner, independent of the network
>>>> topology, to facilitate scaling of the mapping database. In
>>>> addition, an EID block assigned to a site may have site-local
>>>> structure (subnetting) for routing within the site; this structure
>>>> is not visible to the global routing system. In theory, the bit
>>>> string that represents an EID for one device can represent an RLOC
>>>> for a different device. As the architecture is realized, if a
>>>> given bit string is both an RLOC and an EID, it must refer to the
>>>> same entity in both cases.
>>>>
>>>>
>>>> Is the above sentence really necessary?
>>>>
>>>
>>> Agreed, why not simplify the definitions. They are written from the
>>> ‘Internet scalability mindset’, why not say that an EID is an address of
>>> the overlay and an RLOC an address of the overlay. This change may require
>>> further changes on the document so I am not 100% sure if this is a good
>>> idea.
>>
>> For clarification I was just referring to the sentence:
>>
>> " As the architecture is realized, if a given bit string is both an RLOC and
>> an EID, it must refer to the same entity in both cases.”
>>
>> I am wondering if such constrain is really necessary. If namespaces are well
>> scoped there is no need for this.
>>
>> [snip]
>>
>> About the following:
>>
>>>
>>>>
>>>> o EIDs are typically IP addresses assigned to hosts.
>>>>
>>>> o Other types of EID are supported by LISP, see [RFC8060] for
>>>> further information.
>>>>
>>>> I would put the last two bullets in the definition of EID. It simplifies
>>>> the story here.
>>>>
>>>>
>>>
>>> I suggest to leave them here, I don´t think that readers start from the
>>> ‘Definition of terms’, these are relevant concepts to understand LISP.
>>
>> Good point about de definition of terms. What really bothers me is the
>> bullet organisation. What can be done is to merge these two bullets with the
>> previous one.
>>
>>>
>>>>
>>>> The description of the encap/decap operation lacks of clarity concerning
>>>> how to deal with
>>>> ECN bits and DSCP .
>>>>
>>>> 1. I think that the text should make explicitly the difference between
>>>> DSCP and ECN fields.
>>>>
>>>> 2. How to deal with ECN should be part of the description of the
>>>> encap/decap not a paragraph apart.
>>>> This basically means that half of the last paragraph should be a bullet
>>>> of the ITR/PITR encapsulation
>>>> and the other half in the ETR/PETR operation.
>>>
>>>
>>> Agreed, what about this (please comment):
>>>
>>> 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.
>>>
>>
>> Text looks very good to me.
>>
>>
>>>
>>>>
>>>> Large part of this section is about control plane issues and as such
>>>> should be put in 6833bis.
>>>>
>>>> What this section should state is that priority and weight are used to
>>>> select the RLOC to use.
>>>> Only exception is gleaning where we have one single RLOC and we do not
>>>> know neither priority nor weight.
>>>>
>>>> All the other operational discussion goes elsewhere, but not in this
>>>> document.
>>>>
>>>
>>> Agree, I suggest moving it to 6833bis. What to leave in 6830bis is less
>>> obvious, maybe something like (not final, just a couple of ideas):
>>>
>>> The data-plane must follow the state stored in the map-cache to encapsulate
>>> and decapsulate packets. The map-cache is populated using a control-plane,
>>> such as [6833bis]. ETRs encapsulate packets following the Priorities and
>>> Weights stored in the map-cache.
>>>
>>
>> Yes, this is what I meant.
>>
>>
>>> Actually we should merge this section with 'Routing Locator Hashing'
>>>
>>>
>>
>> I think is a good idea.
>>
>> [snip]
>>>> 13. Changing the Contents of EID-to-RLOC Mappings
>>>>
>>>>
>>>> This is a control plane issue, as such it has to go in 6833bis, with two
>>>> exception:
>>>> The very first paragraph stetting the problem, and the versioning
>>>> subsection, because it is a data-plane mechanism.
>>>>
>>>> All of the rest 6833bis
>>>>
>>>> Actually I remember a suggestion about putting operations issues like this
>>>> in an OAM document which would be a good idea.
>>>>
>>>>
>>>
>>> So you are suggesting that the LISP control-plane does not define any
>>> mechanism to update EID-to-RLOC mappings?
>>>
>>
>> Not exactly. Control-plane should discuss how to change the mappings, but
>> things like clock sweep is just management not a control plane mechanism, as
>> such it does not really needs to be standardised because there are no
>> interoperability issues, hence it make really sense to put it elsewhere.
>>
>> Thanks
>>
>> Luigi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
