From my perspective on the situation:
(1) I made changes exactly to text that was requested.
(2) I sometimes modify what the text that was requested.
(3) I disgree with some text so don’t include it.
(4) I have made many sub-revisions of -08.
(5) Comments are coming in throughout the review period and I don’t know what
revision you have read and what you have not read. I don’t know if your
comments are old or based on one of the revisions. Because I see comments that
I addressed but its not clear to me you know that (or at least you have not
told me).
(6) The changes in (1) and (2) have not been confirmed or denied by commenters.
So I don’t know if what I changed has been accepted.
(7) Adding text to something that has changed won’t go in properly. So
referencing some offered text in a previous email can’t be just inserted.
So -08 has been submitted. I don’t know what are the outstanding issues at this
point. So I need commenters to be specific. This is what I suggest:
(1) List the open issues by commenting on the latest submitted -08.
(2) Include text from the -08 draft and your comments follow with suggested
text.
Let’s use that as a base to comment and discuss further. I can’t read your
minds so I need more of your help. So please put more effort into it.
Thanks in advance for your support,
Dino
> On Jan 10, 2018, at 2:03 AM, Luigi Iannone <g...@gigix.net> wrote:
>
> Dino,
>
>> 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.
>>
>
> I find this request unfair.
> I spent quite a bit of time reviewing and discussing this document, now you
> just try to wash all out by requesting comments on -08.
>
> Please let's continue discussing on the open issues so to find a solution.
>
> Thanks
>
> Luigi
>
>
>
>> 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
