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. 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
