> 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
