Snipping a bit of text to keep the email more readable. >> >> Fixed. > > The sentence still talked about „future version of the protocol“. Is that > still necessary?
Beacuse it is still true. > >>>> The Map-Notify-Ack has been there since day-1 in implementations. This is >>>> just IETF catching up. And it took over 5 years. So we really don’t have a >>>> compatibility situation. And didn’t want to create one in the >>>> specifications. So consider it a day 1, version 1 message. It really >>>> wasn’t added later. >>> >>> This should be stated in section 18. >> >> Done. > > I would specifically state here that for that reason no interop problems are > expected. I think it is clear enough and we shouldn’t over think this. > >> >>>>> any case the chosen approach needs to be further discussed in the doc. >>>>> >>>> >>>> This is a data-plane feature so it is discussed in 6830bis and RFC6830. >>> >>> This is a different issue. The control plane protocol as specified in this >>> doc also needs to consider fragmentation and MTU. Please read RFC8085 >>> accordingly. >> >> I have added text per Colin’s comments. > > Just pointing to RFC8085 is not enough. This spec must specify that messages > MUST not exceed the MTU and fragmentation should not be used. And further > either recommend to use MTU discovery or just restrict the message size > according to the recommendations in RFC8085. I would recommend to just do the > later for simplicity. I cannot say that or else we invalidate curernt implementations. We do this and people see the implementations are different than the spec, then the spec lacks credability. >>>> >>>> We have referenced RFC8085 in the too be published -14 version of 6833bis. >>> >>> I didn’t find a reference in -14. However a reference is not enough, the >>> specified behavior is not appropriate and needs to change. If you need >>> further help, please consult the respective transport experts, e.g. Gorry >>> Fairhurst who is an author of RFC8085. >> >> I have added text. We have a smaller interval because 3 seconds is way too >> long (arguably 1 seond is too) to populate a map-cache. Note during that >> time, packets that arrive to the ITR are discarded. So this occurs if just >> one Map-Request is lost. > > As I said, just providing a pointer to RFC8085 is not sufficient. Well I think it is. >>>>> Similarly I'm not sure about the intent of this requirement in section >>>>> 5.5: >>>>> "Map-Replies SHOULD be sent for an EID-Prefix no more often than once >>>>> per second to the same requesting router. " >>>>> My understanding is that Replies are only sent when a request is >>>>> received. Why >>>>> is this additional rate limit needed? Again if used it should be 3 >>>>> seconds for >>>>> all traffic to be inline with RFC8085. Also again, why is that not a MUST? >>>>> Further recommendation are needed here. >>>> >>>> Because the source is a bad-actor and sending new Map-Requests (with a new >>>> nonce). >>> >>> Not sure if that is the right choice because it may interact badly with >>> loss detection. However, as I said the specified behavior need to be >>> refined at various places in the doc. >> >> Well there is not many choices. > > You can choose to not have this rate limiting but limit the total number of > request per requesting router per time interval. That would trigger a reply > immediately but still limit the total load in case of „bad-actors“. You have to be careful what is added or else it will not reflect implementations. We have made it a goal to keep the implementations and IETF specs in sync and didn’t want to repeat issues BGP had in the 90s (and to this day actually). >> >>>> >>>>> Respectively the following sentence in section 6.1 is also unclear: >>>>> "The remote ITR MUST rate-limit the Map-Request until it gets a Map-Reply" >>>>> Why is the rate-limit as currently proposed depend on the fact if a >>>>> Map-Reply >>>>> is received? Is the ITR supposed to retransmit the Map-Request…? >>>> >>>> If you are not getting answers to your Map-Requests because of packet loss >>>> or MITM, sending them faster is not going to get you a Map-Reply. >>> >>> If you detect loss, you should send slower not faster for congestion >>> collapse avoidance. >> >> That was my point. > > Should should instead specify a similar loss detection and retransmission > mechanism for Map-Request as now done for Map-Notify. The rate-limit alone is > not helpful. No. Because Map-Notify is just moving a single message for a particular reason. The Map-Request is used for a variety of reasons and the rate-limiting is built into the cache management algorithms. >>>> >>>> That is not rate-limiting to avoid message reduction. It is a soft-state >>>> way of keeping registration state alive in the map-server(s). >>> >>> That fine but you also need to specify normatively an upper bound. >> >> The recommended upper bound is 1 minute. If you are not getting your point >> across, please be more specific. > > Then you have to say „MUST NOT send more than one message per minutes“. The > current text just gives a recommendation what a go value might be but does > not specify an actually limit. You can’t say that because deregisters are Map-Registers with a TTL of 0 and can be triggered. I really think the text is fine. > >>> >>> That all fine. However, you don’t specify the behavior if the ack is not >>> received. How/when is the message assumed to be lost? When should it be >>> retransmitted? How often? When to give up? Should exponential backoff be >>> used? This whole part s completely missing in the spec. >> >> Have added text. > > Thanks! > > Not sure I understand the first sentence: > > „A sender of an unsolicited Map-Notify message (one that is not used > as an acknowledgment to a Map-Register message) will follow the > Congestion Control And Relability Guideline sections of [RFC8085].“ > > The rest of the text is fine and gives a good spec. I think it is okay to > mention that that spec is inline with RFC8085 but other than that I’m not > sure what this first sentence is telling me…? > > > And also the last sentence is not fully clear: > > "After this time, the Map- > Notify sender can only get the RLOC-set change by later querying the > mapping system or by RLOC-probing one of the RLOCs of the existing > cached RLOC-set to get the new RLOC-set.“ > > I don’t think there should be an attempt to later try again. Probably the > system should log or notify an error instead. However, if it makes sense to > try later again you have to specify what later means (hours, days?) and how > often it should try again before it finally gives up and logs an error. Did you read the latest version of this paragraph that Albert commented on. It reads much better. >>>> >>>>> Clarification questions: >>>>> 1) Sec 5.3.: >>>>> "For the initial case, the destination IP >>>>> address used for the Map-Request is the data packet's destination >>>>> address (i.e., the destination EID) that had a mapping cache lookup >>>>> failure." >>>>> Does that mean that the Map-Request needs to use the IPv4 or IPv6 >>>>> depending on >>>>> the IP version used by the initial message from the EID. Is that always >>>>> the >>>>> case or just for this initial message? I would assume that for all other >>>>> cases >>>>> this is actually independent...? Because otherwise there would be a >>>>> constraint >>>>> on what needs to be requested. I would like t see further clarification >>>>> about >>>>> this in the doc. >>>> >>>> No it doesn’t. It depends on the address-family of the map-resolver. And >>>> that is configured. >>> >>> Okay, if the map-resolver is IPv6 and I receive an IPv4 packet, how can I >>> copy the "the data packet's destination address“ which is IPv4 in to the >>> "destination IP address used for the Map-Request“ which is IPv6? Or even >>> worse, the other way around. >> >> Because a Map-Request going to the mapping system is “ECM’ed” “Encapsulated >> Control Message” with the header address-family as the EID being requested. > > You say that if the EID send e.g. an IPv4 message it also has to be > encapsulated in IPv4? That is stated nowhere. If that is the intention that > has to be specified. However, I don’t really see why this restriction needs > to exists…? Let me explain. If you are sending a Map-Request for an IPv4 EID, you build an IPv4 Map-Request. Before sending it it is wrapped with an ECM header and then sent to the Map-Resolver. The IP header wrapped around the ECM header is the address family of the configured Map-Resolver. All 4 combinations work and is deployed. >>>> >>>>> 6) Section 8.2 says: "Note that the Map-Notify message >>>>> is sent to UDP destination port 4342, not to the source port >>>>> specified in the original Map-Register message." >>>>> Actually why is that? >>>> >>>> cisco interperability. >>> >>> I would expect to still see more reasoning in the doc. >> >> Sorry, I was wrong in my reply. I read Map-Reply. For Map-Registers this is >> normal behavior that a request is sent to a well-known port and a reply is >> sent *from* the well known port. > > Okay, then I still don’t understand WHY this is done? The interoperability reference is a cisco implementation issue. And I won’t comment why it was done this way, lots of historical details. Dino > > Mirja _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
