> On 12 Jan 2018, at 18:38, Dino Farinacci <[email protected]> wrote: > > Let me put it even simpler for you Luigi. Say someone wants to write a client > program that uses the LISP control-plane documented in 6833bis. A perfect > example of this is a lig client (RFC 6835). > > If SMRs and RLOC-Probing were to be documented in 6833bis, the lig client > implementor would be wondering if it needs to implement SMRs and RLOC-probes. > A lig client simply looks up an EID and prints out the RLOC-records. > > Conclusion, SMRs and RLOC-probes are used by xTRs to be able to run the > data-plane.
SMRs and RLOC-probes are control-plane features used by xTRs to be able to run the data-plane. As such they go in 6833bis. L. > xTRs are data-plane components. Therefore SMRs and RLOC-probes should stay in > 6830bis, the data-plane specification. > > Dino > >> On Jan 12, 2018, at 3:01 AM, Luigi Iannone <[email protected]> wrote: >> >> >> >>> On 11 Jan 2018, at 18:50, Dino Farinacci <[email protected]> wrote: >>> >>> Thanks Alberto for your comments. Here is how I break up items in the >>> control-plane and the data-plane. >>> >>> Control-Plane (6833bis document): >>> >>> (1) The definition of control-plane messages. These are already documented >>> in 6833bis. >>> (2) What components make up the control-plane that are not also in the >>> data-plane. That is Map-Servers, Map-Resovers, LISP-ALT nodes, LISP-DDT >>> nodes. These are already documented in 6833bis. >>> >>> Data-Plane (6830bis document): >>> >>> (1) What is required to move packets. Which includes the encapsulation >>> format and the database-mappings and map-cache xTRs use. These are already >>> documented in RFC6830bis. >>> (2) The components that make up the data-plane. That is ITRs, ETRs, PxTRs, >>> and RTRs. >>> (3) And the elements of operation that the components in (2) use. So >>> RLOC-probing and SMRs are explained in RFC6830bis because the components in >>> (2) use. They are using control-plane messages obviously but those messages >>> are defined in 6833bis. >>> >>> Note that ETRs send SMRs, note ITRs and PITR send RLOC-probes. These >>> messages are not sent by any control-plane components. Another data-plane >>> can be defined to do its own OAM or map version updating and use the >>> messages defined in 6833bis to do that. But they could also might “let me >>> try to use the same map-cache mechanisms as LISP but use a different >>> encapsulation format”. In this case, an implementor or deployer would read >>> 6830bis. >>> >>> Having said that, people don’t create walls between getting information so >>> if they want to do their own data-plane they can still read 6830bis. >>> >>> Another point about SMRs, the entire section talks about what ITRs and ETRs >>> do. And these devices are data-plane components. Putting this section in >>> 6833bis would possibly surprise a reader implementing another data-plane. >>> For instance, a VXLAN data-plane reader would say “what is an ITR and ETR? >>> I have VTEPs”. >> >> This reasoning does not hold. >> >> [dhcp164-133] ~/Desktop # grep -c ITR draft-ietf-lisp-rfc6833bis-07.txt >> 65 >> [dhcp164-133] ~/Desktop # grep -c ETR draft-ietf-lisp-rfc6833bis-07.txt >> 83 >> [dhcp164-133] ~/Desktop # grep -c xTR draft-ietf-lisp-rfc6833bis-07.txt >> 20 >> [dhcp164-133] ~/Desktop # >> >> >> >> >> Whoever reads 6833bis has to know what an ITR and an ETR is and what it does. >> >> L. >> >> >>> Another point about SMRs, they can be data driven. This happens when an ITR >>> encapsulates to an ETR where the EID is no longer residing. That ETR, could >>> respond with a SMR to the ITR to inform it that it has out of date >>> mappings. This is all data-plane driven. Wouldn’t make logical sense to put >>> it in 6833bis. >>> >>> Anyways, that is the way I look at it, >>> Dino >>> >>>> On Jan 11, 2018, at 6:21 AM, Alberto Rodriguez-Natal >>>> <[email protected]> wrote: >>>> >>>> Adding my two cents to this discussion, in the hope that it helps with >>>> the convergence. >>>> >>>> My original hope with the reorganization of the RFCs was to be able to >>>> use the LISP control-plane with a non-LISP data-plane. Putting aside >>>> the discussion of what goes where, and with some pragmatism in mind, I >>>> think we're close to that with the current 6833bis. The major >>>> roadblock for me is the lack of SMR in that document, and I think this >>>> aligns with the view of others in the list. >>>> >>>> I believe that with the addition of SMR, 6833bis will have all the >>>> required pieces to put together a viable LISP deployment (using a >>>> non-LISP data-plane) without having to look into 6830bis. Sure, there >>>> would be some mechanisms (e.g. RLOC probing) that would not be >>>> available using only 6833bis, but I could live without those. In >>>> addition, we could work on adding some extra explanation to the >>>> introduction of 6833bis so a non-familiar reader could make use of >>>> LISP without looking into 6830bis. >>>> >>>> I think these two things (i.e. move SMR and extend 6833bis intro) >>>> would minimize the changes required on the current documents and would >>>> allow us to reach some rough consensus to make progress with the docs. >>>> What do you guys think? >>>> >>>> Alberto >>>> >>>> On Wed, Jan 10, 2018 at 6:26 PM, Dino Farinacci <[email protected]> >>>> wrote: >>>>> 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 <[email protected]> wrote: >>>>>> >>>>>> Dino, >>>>>> >>>>>>> On 9 Jan 2018, at 18:54, Dino Farinacci <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> lisp mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/lisp >>> >> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
