Re: [lisp] Review of RFC6833bis
Ack on the new version. Thanks Dino. Alberto On Fri, Dec 15, 2017 at 12:12 PM, Dino Farinacci wrote: > Enclosed is the latest revision of RFC6833bis-07. Thanks for closing the loop > Alberto. If you can ack the new changes, I’ll submit -07 this weekend. > >> On Dec 7, 2017, at 11:06 PM, Alberto Rodriguez-Natal >> wrote: >> >> Hey Dino, >> >> Sorry for the delay on this. Mostly agree with your responses, thanks >> for the edits! >> >> There a few points that I would like to clarify. See below. > > No prob. See my responses. > >> For definitions of other terms -- notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. • [AR] I think that the definitions for Map-Request and Map-Reply should be moved here, and probably we should include the definition for Map-Notify-Ack as well. 6830bis should reference 6833bis for control-plane messages, not the other way around. >>> >>> They did. But the text you identified above was not changed. Changed now. >> >> I meant that Map-Request and Map-Reply are not defined here (or >> anywhere else that I can find) and they should. The closest things are >> Encapsulated Map-Request and Negative Map Reply. > > I added a brief definitions of each to be consistent with Map-Register and > Map-Notify definitions that are already there. > >> The RLOCs in the Map-Reply are globally routable IP addresses of all ETRs for the LISP site. • [AR] We should remove "globally" here. Maybe also add a "Generally" at the beginning since we might have LCAFs with AFI = 0 (LISP-VPN encoding of Home-IID for instance). >>> >>> Removed “globally”. I don’t understand your other “Generally” comment. >> >> My point was that in the LISP-VPN draft the Home-IID is encoded as an >> RLOC that it is not a routable address for the ETR. > > I removed all occurrences of “globally routable” to “routable”. > >> For example, a requester with two cached EID-Prefixes that are covered by a Map-Reply containing one less-specific prefix replaces the entry with the less-specific EID-Prefix. • [AR] Not sure if I follow here. Does this mean that a less-specific received in a Map-Reply will erase from the map-cache previously cached more-specifics that are covered by the less-specific? >>> >>> Yes, because if the Map-Reply returned a more-specific with the >>> less-specific, then it would be replaced so the less-specific replaces the >>> more-specifics that ARE NOT in the Map-Reply. >> >> I think that I would rephrase this behavior to make it optional then. >> There are implementations which just return the entry that the >> requested EID hits and don't return by default any more-specifics >> below. > > It is not optional. And this section of the draft defines the details. And > the section includes a MUST. > >> >> When more than one EID-Prefix is returned, all SHOULD use the same Time to Live value so they can all time out at the same time. When a more-specific EID-Prefix is received later, its Time to Live value in the Map-Reply record can be stored even when other less-specific entries exist. • [AR] We should explain in which cases a more-specific can be received later. >>> >>> I don’t follow. Each EID-record will contain a TTL for the length prefix >>> that is encoded. So the new Map-Reply TTL will be used for any length entry >>> (and in this case the more-specific). >> >> My concern was that we should provide some context on when an ITR may >> receive a more-specific prefix that overlaps with an existing >> less-specific prefix already in its map-cache. One example is the EID >> mobility draft, we can reference it here. > > I added a few sentences. > > Thanks, > Dino > > > > > > > ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Review of RFC6833bis
Hey Dino, Sorry for the delay on this. Mostly agree with your responses, thanks for the edits! There a few points that I would like to clarify. See below. >> For definitions of other terms -- notably Map-Request, Map-Reply, >> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >> >>• [AR] I think that the definitions for Map-Request and Map-Reply >> should be moved here, and probably we should include the definition >> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >> control-plane messages, not the other way around. > > They did. But the text you identified above was not changed. Changed now. I meant that Map-Request and Map-Reply are not defined here (or anywhere else that I can find) and they should. The closest things are Encapsulated Map-Request and Negative Map Reply. >> The RLOCs in the Map-Reply are globally routable IP addresses of all >> ETRs for the LISP site. >> >>• [AR] We should remove "globally" here. Maybe also add a >> "Generally" at the beginning since we might have LCAFs with AFI = 0 >> (LISP-VPN encoding of Home-IID for instance). > > Removed “globally”. I don’t understand your other “Generally” comment. My point was that in the LISP-VPN draft the Home-IID is encoded as an RLOC that it is not a routable address for the ETR. >> For example, a requester with two cached EID-Prefixes that are covered >> by a Map-Reply containing one less-specific prefix replaces the entry >> with the less-specific EID-Prefix. >> >>• [AR] Not sure if I follow here. Does this mean that a >> less-specific received in a Map-Reply will erase from the map-cache >> previously cached more-specifics that are covered by the >> less-specific? > > Yes, because if the Map-Reply returned a more-specific with the > less-specific, then it would be replaced so the less-specific replaces the > more-specifics that ARE NOT in the Map-Reply. I think that I would rephrase this behavior to make it optional then. There are implementations which just return the entry that the requested EID hits and don't return by default any more-specifics below. >> When more than one EID-Prefix is returned, all SHOULD use the same >> Time to Live value so they can all time out at the same time. When a >> more-specific EID-Prefix is received later, its Time to Live value in >> the Map-Reply record can be stored even when other less-specific >> entries exist. >> >>• [AR] We should explain in which cases a more-specific can be >> received later. > > I don’t follow. Each EID-record will contain a TTL for the length prefix that > is encoded. So the new Map-Reply TTL will be used for any length entry (and > in this case the more-specific). My concern was that we should provide some context on when an ITR may receive a more-specific prefix that overlaps with an existing less-specific prefix already in its map-cache. One example is the EID mobility draft, we can reference it here. Thanks! Alberto ___ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
Re: [lisp] Review of RFC6833bis
> On Nov 29, 2017, at 11:09 AM, Victor Moreno (vimoreno) > wrote: > > In addition to the comments provided by Alberto and Dino, I have some > comments on the text in section 5 of the RFC. > > 1. The text in section 5 currently prescribes that in response to a > map-request for a non-registered or non-existent EID, an ITR should expect an > NMR from the Map-Server (or Resolver) with action code “Natively-Forward” > (this is stated in section 5.1 and re-stated in 5.3 and 5.4). Prescribing > that this is to always be an NMR with a Native-Forward action is limiting. I can go along with this Victor. I would like to hear what the working group says about this. See technical details below. I have also asked myself the question many times if we need or should distinguish between not-registered or not-assigned. We did this in DDT with Map-Referrals but not in negative Map-Replies. The problem with “not-assigned” is that a big EID-prefix block may be configured in a map-server with “accept-more-specifics” semantics. Which means you don’t know if the more specifics are assigned or not. So what would always be returned is a “not-registered” action. So I think we could introduce this, I think in practice it could never be used. And as you say a negative prefix that is built for a hole that needs to point to a PETR, is that a EID-prefix or not? So it would be hard to distinguish between not-assigned here versus not-registered unless the EID-record had a flag that said what is being registered. > After trying to address a few use cases, it would be very useful if the > specification allowed: > > a. As an alternative to responding with an NMR, an implementation may respond > to a Map-Request for a non-registered or non-existent EID with a “positive" > map-reply inclusive of an RLOC-set that can be configured in the > Mapping-System. The immediate use case this would address is that of not > having to configure a PETR statically at every ITR, but have the map-replies > include the PETR's RLOC information. This Map-Reply should have short TTLs > and include covering/hole EID prefixes just as specified for the current > NMRs, hence this differs from a map-reply for registered 0/0 EIDs. Why configure a map-server with something it may not have control over. An mapping system provider may not be associaed with data-plane provider, so it unilaterally (or even if agreed upon) should register *to itself*. There is no reason why the data-plane provider register any length EID-prefix with any RLOC-set it determines. Then a LISP site just encapsulates. The architecture already supports this. > b. The use of all action codes possible with the ACT bits (as defined in > section 4.4) when Map-Replying with an NMR to a Map-Request for a > non-registered or non-existent EID. As I read the text in section 5, it isn’t > clear that other action codes are allowed, the text is focused solely on > Natively-Forward, there are strong requirements to leverage the Drop action > and particularly Drop/Policy-Denied. As well as Auth-Failure. I can make this more clear in the section describing the ACT bits. > 2. There are multiple references to LISP-ALT in the text. Do we want to keep > those references moving forward? Or can these be removed? The implementations > I work with do not use ALT, but maybe there are others that do? Since LISP-ALT and LISP-DDT are the only RFC’ed mapping database transport systems, we should include both IMO. What do you think? We have done this for other areas as well. > 3. Section 5.3. Paragraph 2 is describing the behavior for the MS when there > is a match on an EID “hole”. Section 5.3. suggests a 15 minute TTL, meanwhile > section 5.1. suggests a 1 minute TTL for the same EID. I think it should be 1 > minute in both cases. Will fix. > I can contribute with text suggestions once we discuss the above on the list. Thanks for that. If you want to take a crack at (b) above that would be great. Dino > > -v > > >> On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal >> wrote: >> >> Thanks for the responses Dino. I'll get back to you later this week. >> >> Alberto >> >> On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci wrote: Hi all, Wanted to send this before the meeting on Friday. I just completed a review of 6833bis, you can find my comments below. Like last time, extracts from the draft are copied and followed by my comments. Thanks, Alberto >>> >>> Thanks again Alberto for your comments. See my responses inline and a -07 >>> diff file. >>> Map-Resolver: A network infrastructure component that accepts LISP Encapsulated Map-Requests, • [AR] We could remove "Encapsulated" and just use "Map-Requests". A Map-Resolver may accept non-encapsulated Map-Requests as well. >>> >>> No, they are “control-plane” encapsulated. I’ll make that more clear. >>> Map-Register message: A
Re: [lisp] Review of RFC6833bis
In addition to the comments provided by Alberto and Dino, I have some comments on the text in section 5 of the RFC. 1. The text in section 5 currently prescribes that in response to a map-request for a non-registered or non-existent EID, an ITR should expect an NMR from the Map-Server (or Resolver) with action code “Natively-Forward” (this is stated in section 5.1 and re-stated in 5.3 and 5.4). Prescribing that this is to always be an NMR with a Native-Forward action is limiting. After trying to address a few use cases, it would be very useful if the specification allowed: a. As an alternative to responding with an NMR, an implementation may respond to a Map-Request for a non-registered or non-existent EID with a “positive" map-reply inclusive of an RLOC-set that can be configured in the Mapping-System. The immediate use case this would address is that of not having to configure a PETR statically at every ITR, but have the map-replies include the PETR's RLOC information. This Map-Reply should have short TTLs and include covering/hole EID prefixes just as specified for the current NMRs, hence this differs from a map-reply for registered 0/0 EIDs. b. The use of all action codes possible with the ACT bits (as defined in section 4.4) when Map-Replying with an NMR to a Map-Request for a non-registered or non-existent EID. As I read the text in section 5, it isn’t clear that other action codes are allowed, the text is focused solely on Natively-Forward, there are strong requirements to leverage the Drop action and particularly Drop/Policy-Denied. 2. There are multiple references to LISP-ALT in the text. Do we want to keep those references moving forward? Or can these be removed? The implementations I work with do not use ALT, but maybe there are others that do? 3. Section 5.3. Paragraph 2 is describing the behavior for the MS when there is a match on an EID “hole”. Section 5.3. suggests a 15 minute TTL, meanwhile section 5.1. suggests a 1 minute TTL for the same EID. I think it should be 1 minute in both cases. I can contribute with text suggestions once we discuss the above on the list. -v > On Nov 29, 2017, at 10:04 AM, Alberto Rodriguez-Natal > wrote: > > Thanks for the responses Dino. I'll get back to you later this week. > > Alberto > > On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci wrote: >>> Hi all, >>> >>> Wanted to send this before the meeting on Friday. I just completed a >>> review of 6833bis, you can find my comments below. Like last time, >>> extracts from the draft are copied and followed by my comments. >>> >>> Thanks, >>> Alberto >> >> Thanks again Alberto for your comments. See my responses inline and a -07 >> diff file. >> >>> Map-Resolver: A network infrastructure component that accepts LISP >>> Encapsulated Map-Requests, >>> >>> • [AR] We could remove "Encapsulated" and just use "Map-Requests". >>> A Map-Resolver may accept non-encapsulated Map-Requests as well. >> >> No, they are “control-plane” encapsulated. I’ll make that more clear. >> >>> Map-Register message: A LISP message sent by an ETR to a Map-Server >>> to register its associated EID-Prefixes. In addition to the set of >>> EID-Prefixes to register, the message includes one or more RLOCs to be >>> used by the Map-Server when forwarding Map-Requests (re-formatted as >>> Encapsulated Map-Requests) received through the database mapping >>> system. >>> >>> • [AR] This may give the impression that the RLOCs on the >>> Map-Register are only to forward Map-Requests, which is not the case >>> in proxy-reply mode. I would suggest we rephrase this text as follows: >>> "In addition to the set of EID-Prefixes to register, the message >>> includes one or more RLOCs to be used to reach the ETR. The Map-Server >>> uses these RLOCs when it has to forward Map-Requests (potentially >>> re-formatted as Encapsulated Map-Requests) received through the >>> database mapping system.” >> >> I reworded. >> >>> Map-Notify message: A LISP message sent by a Map-Server to an ETR >>> >>> • [AR] I would replace "ETR" with "xTR" so we cover the PubSub >>> behavior as well. >> >> Can’t do that because an ITR does not get Map-Notifies as a response to a >> Map-Register. But I will add that ITRs get Map-Notifies to inform them of >> RLOC-set changes (for pubsub and signal-free-multicast use-cases). >> >>> >>> For definitions of other terms -- notably Map-Request, Map-Reply, >>> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >>> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >>> >>> • [AR] I think that the definitions for Map-Request and Map-Reply >>> should be moved here, and probably we should include the definition >>> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >>> control-plane messages, not the other way around. >> >> They did. But the text you identified above was not changed. Changed now. >> >>> A Map-Register message contains a
Re: [lisp] Review of RFC6833bis
Thanks for the responses Dino. I'll get back to you later this week. Alberto On Tue, Nov 28, 2017 at 5:12 PM, Dino Farinacci wrote: >> Hi all, >> >> Wanted to send this before the meeting on Friday. I just completed a >> review of 6833bis, you can find my comments below. Like last time, >> extracts from the draft are copied and followed by my comments. >> >> Thanks, >> Alberto > > Thanks again Alberto for your comments. See my responses inline and a -07 > diff file. > >> Map-Resolver: A network infrastructure component that accepts LISP >> Encapsulated Map-Requests, >> >>• [AR] We could remove "Encapsulated" and just use "Map-Requests". >> A Map-Resolver may accept non-encapsulated Map-Requests as well. > > No, they are “control-plane” encapsulated. I’ll make that more clear. > >> Map-Register message: A LISP message sent by an ETR to a Map-Server >> to register its associated EID-Prefixes. In addition to the set of >> EID-Prefixes to register, the message includes one or more RLOCs to be >> used by the Map-Server when forwarding Map-Requests (re-formatted as >> Encapsulated Map-Requests) received through the database mapping >> system. >> >>• [AR] This may give the impression that the RLOCs on the >> Map-Register are only to forward Map-Requests, which is not the case >> in proxy-reply mode. I would suggest we rephrase this text as follows: >> "In addition to the set of EID-Prefixes to register, the message >> includes one or more RLOCs to be used to reach the ETR. The Map-Server >> uses these RLOCs when it has to forward Map-Requests (potentially >> re-formatted as Encapsulated Map-Requests) received through the >> database mapping system.” > > I reworded. > >> Map-Notify message: A LISP message sent by a Map-Server to an ETR >> >>• [AR] I would replace "ETR" with "xTR" so we cover the PubSub >> behavior as well. > > Can’t do that because an ITR does not get Map-Notifies as a response to a > Map-Register. But I will add that ITRs get Map-Notifies to inform them of > RLOC-set changes (for pubsub and signal-free-multicast use-cases). > >> >> For definitions of other terms -- notably Map-Request, Map-Reply, >> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >> >>• [AR] I think that the definitions for Map-Request and Map-Reply >> should be moved here, and probably we should include the definition >> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >> control-plane messages, not the other way around. > > They did. But the text you identified above was not changed. Changed now. > >> A Map-Register message contains a list of EID-Prefixes plus a set of >> RLOCs that can be used to reach the ETR when a Map-Server needs to >> forward a Map-Request to it. >> >>• [AR] Since proxy-reply is a common case, I'd not constrain the >> meaning of the RLOCs in the Map-Register. I'd remove the last part of >> the sentence that says "when a Map-Server needs to forward a >> Map-Request to it.” > > Agree. > >> A Map-Resolver receives Encapsulated Map-Requests from its client ITRs >> and uses a mapping database system to find the appropriate ETR to >> answer those requests. >> >>• [AR] A MR can receive Map-Requests that don't come from ITR >> and/or that are not encapsulated. If we don't want to change the text, >> at least I'd add at the beginning: "In a common scenario, a >> Map-Resolver…" > > I don’t think we should change this. The lig document indicates that a lig > client can send Map-Requests. This document is for support of a data-plane. > >> Note that while it is conceivable that a non-LISP-DDT Map-Resolver >> could cache responses to improve performance, >> >>• [AR] The discussion on caching or not at the Map-Resolver goes >> beyond DDT. We could rephrase this removing the mention to >> "non-LISP-DDT”. > > Agree. Changed. > >> The LISP UDP-based messages are the Map-Request and Map-Reply >> messages. When a UDP Map-Request is sent, the UDP source port is >> chosen by the sender and the destination UDP port number is set to >> 4342. When a UDP Map-Reply is sent, the source UDP port number is set >> to 4342 and the destination UDP port number is copied from the source >> port of either the Map-Request or the invoking data packet. >> >>• [AR] I would remove the first sentence and re-phrase this >> paragraph as follows: "When a UDP LISP control message is sent and is >> not a direct reply to a previous control message, the UDP source port >> is chosen by the sender and the destination UDP port number is set to >> 4342. When a UDP LISP control message is sent as a direct reply to a >> previous message, the source UDP port number is set to 4342 and the >> destination UDP port number is either set to 4342 or copied from the >> source port of the invoking LISP control message. See the following >> subsections for details.” > > This is not really true. There are too many cases with
Re: [lisp] Review of RFC6833bis
No worries Dino, there's no rush. Thanks for your early response. Thanks, Alberto On Thu, Nov 16, 2017 at 4:23 PM, Dino Farinacci wrote: > Thanks for the comments. We’ll bring this up in the meeting but I can’t > address your comments until next week. > > Some points: > > (1) Packets are “control-plane” encapsulated to the Map-Resolver, so the text > is correct. > (2) The WG had decided at some point to not include the NAT-traversal > document because its not a WG document. > (3) Your comments about clarifying text is valuable and IMO should go in. > Thanks for that. > > Dino > >> On Nov 16, 2017, at 12:34 AM, Alberto Rodriguez-Natal >> wrote: >> >> Hi all, >> >> Wanted to send this before the meeting on Friday. I just completed a >> review of 6833bis, you can find my comments below. Like last time, >> extracts from the draft are copied and followed by my comments. >> >> Thanks, >> Alberto >> >> >> >> >> Map-Resolver: A network infrastructure component that accepts LISP >> Encapsulated Map-Requests, >> >>• [AR] We could remove "Encapsulated" and just use "Map-Requests". >> A Map-Resolver may accept non-encapsulated Map-Requests as well. >> >> Map-Register message: A LISP message sent by an ETR to a Map-Server >> to register its associated EID-Prefixes. In addition to the set of >> EID-Prefixes to register, the message includes one or more RLOCs to be >> used by the Map-Server when forwarding Map-Requests (re-formatted as >> Encapsulated Map-Requests) received through the database mapping >> system. >> >>• [AR] This may give the impression that the RLOCs on the >> Map-Register are only to forward Map-Requests, which is not the case >> in proxy-reply mode. I would suggest we rephrase this text as follows: >> "In addition to the set of EID-Prefixes to register, the message >> includes one or more RLOCs to be used to reach the ETR. The Map-Server >> uses these RLOCs when it has to forward Map-Requests (potentially >> re-formatted as Encapsulated Map-Requests) received through the >> database mapping system." >> >> Map-Notify message: A LISP message sent by a Map-Server to an ETR >> >>• [AR] I would replace "ETR" with "xTR" so we cover the PubSub >> behavior as well. >> >> For definitions of other terms -- notably Map-Request, Map-Reply, >> Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please >> consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. >> >>• [AR] I think that the definitions for Map-Request and Map-Reply >> should be moved here, and probably we should include the definition >> for Map-Notify-Ack as well. 6830bis should reference 6833bis for >> control-plane messages, not the other way around. >> >> A Map-Register message contains a list of EID-Prefixes plus a set of >> RLOCs that can be used to reach the ETR when a Map-Server needs to >> forward a Map-Request to it. >> >>• [AR] Since proxy-reply is a common case, I'd not constrain the >> meaning of the RLOCs in the Map-Register. I'd remove the last part of >> the sentence that says "when a Map-Server needs to forward a >> Map-Request to it." >> >> A Map-Resolver receives Encapsulated Map-Requests from its client ITRs >> and uses a mapping database system to find the appropriate ETR to >> answer those requests. >> >>• [AR] A MR can receive Map-Requests that don't come from ITR >> and/or that are not encapsulated. If we don't want to change the text, >> at least I'd add at the beginning: "In a common scenario, a >> Map-Resolver..." >> >> Note that while it is conceivable that a non-LISP-DDT Map-Resolver >> could cache responses to improve performance, >> >>• [AR] The discussion on caching or not at the Map-Resolver goes >> beyond DDT. We could rephrase this removing the mention to >> "non-LISP-DDT". >> >> The LISP UDP-based messages are the Map-Request and Map-Reply >> messages. When a UDP Map-Request is sent, the UDP source port is >> chosen by the sender and the destination UDP port number is set to >> 4342. When a UDP Map-Reply is sent, the source UDP port number is set >> to 4342 and the destination UDP port number is copied from the source >> port of either the Map-Request or the invoking data packet. >> >>• [AR] I would remove the first sentence and re-phrase this >> paragraph as follows: "When a UDP LISP control message is sent and is >> not a direct reply to a previous control message, the UDP source port >> is chosen by the sender and the destination UDP port number is set to >> 4342. When a UDP LISP control message is sent as a direct reply to a >> previous message, the source UDP port number is set to 4342 and the >> destination UDP port number is either set to 4342 or copied from the >> source port of the invoking LISP control message. See the following >> subsections for details." >> >> The UDP checksum is computed and set to non-zero for Map-Request, >> Map-Reply, Map-Register, and Encapsulated Control Message (ECM) >> control messages. >> >>• [AR] Shouldn't it
Re: [lisp] Review of RFC6833bis
Thanks for the comments. We’ll bring this up in the meeting but I can’t address your comments until next week. Some points: (1) Packets are “control-plane” encapsulated to the Map-Resolver, so the text is correct. (2) The WG had decided at some point to not include the NAT-traversal document because its not a WG document. (3) Your comments about clarifying text is valuable and IMO should go in. Thanks for that. Dino > On Nov 16, 2017, at 12:34 AM, Alberto Rodriguez-Natal > wrote: > > Hi all, > > Wanted to send this before the meeting on Friday. I just completed a > review of 6833bis, you can find my comments below. Like last time, > extracts from the draft are copied and followed by my comments. > > Thanks, > Alberto > > > > > Map-Resolver: A network infrastructure component that accepts LISP > Encapsulated Map-Requests, > >• [AR] We could remove "Encapsulated" and just use "Map-Requests". > A Map-Resolver may accept non-encapsulated Map-Requests as well. > > Map-Register message: A LISP message sent by an ETR to a Map-Server > to register its associated EID-Prefixes. In addition to the set of > EID-Prefixes to register, the message includes one or more RLOCs to be > used by the Map-Server when forwarding Map-Requests (re-formatted as > Encapsulated Map-Requests) received through the database mapping > system. > >• [AR] This may give the impression that the RLOCs on the > Map-Register are only to forward Map-Requests, which is not the case > in proxy-reply mode. I would suggest we rephrase this text as follows: > "In addition to the set of EID-Prefixes to register, the message > includes one or more RLOCs to be used to reach the ETR. The Map-Server > uses these RLOCs when it has to forward Map-Requests (potentially > re-formatted as Encapsulated Map-Requests) received through the > database mapping system." > > Map-Notify message: A LISP message sent by a Map-Server to an ETR > >• [AR] I would replace "ETR" with "xTR" so we cover the PubSub > behavior as well. > > For definitions of other terms -- notably Map-Request, Map-Reply, > Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please > consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. > >• [AR] I think that the definitions for Map-Request and Map-Reply > should be moved here, and probably we should include the definition > for Map-Notify-Ack as well. 6830bis should reference 6833bis for > control-plane messages, not the other way around. > > A Map-Register message contains a list of EID-Prefixes plus a set of > RLOCs that can be used to reach the ETR when a Map-Server needs to > forward a Map-Request to it. > >• [AR] Since proxy-reply is a common case, I'd not constrain the > meaning of the RLOCs in the Map-Register. I'd remove the last part of > the sentence that says "when a Map-Server needs to forward a > Map-Request to it." > > A Map-Resolver receives Encapsulated Map-Requests from its client ITRs > and uses a mapping database system to find the appropriate ETR to > answer those requests. > >• [AR] A MR can receive Map-Requests that don't come from ITR > and/or that are not encapsulated. If we don't want to change the text, > at least I'd add at the beginning: "In a common scenario, a > Map-Resolver..." > > Note that while it is conceivable that a non-LISP-DDT Map-Resolver > could cache responses to improve performance, > >• [AR] The discussion on caching or not at the Map-Resolver goes > beyond DDT. We could rephrase this removing the mention to > "non-LISP-DDT". > > The LISP UDP-based messages are the Map-Request and Map-Reply > messages. When a UDP Map-Request is sent, the UDP source port is > chosen by the sender and the destination UDP port number is set to > 4342. When a UDP Map-Reply is sent, the source UDP port number is set > to 4342 and the destination UDP port number is copied from the source > port of either the Map-Request or the invoking data packet. > >• [AR] I would remove the first sentence and re-phrase this > paragraph as follows: "When a UDP LISP control message is sent and is > not a direct reply to a previous control message, the UDP source port > is chosen by the sender and the destination UDP port number is set to > 4342. When a UDP LISP control message is sent as a direct reply to a > previous message, the source UDP port number is set to 4342 and the > destination UDP port number is either set to 4342 or copied from the > source port of the invoking LISP control message. See the following > subsections for details." > > The UDP checksum is computed and set to non-zero for Map-Request, > Map-Reply, Map-Register, and Encapsulated Control Message (ECM) > control messages. > >• [AR] Shouldn't it be computed for all LISP control messages? > > EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 > octets for an IPv6 address family. When a Map-Request is sent by an > ITR because a data packet is received for a d
[lisp] Review of RFC6833bis
Hi all, Wanted to send this before the meeting on Friday. I just completed a review of 6833bis, you can find my comments below. Like last time, extracts from the draft are copied and followed by my comments. Thanks, Alberto Map-Resolver: A network infrastructure component that accepts LISP Encapsulated Map-Requests, • [AR] We could remove "Encapsulated" and just use "Map-Requests". A Map-Resolver may accept non-encapsulated Map-Requests as well. Map-Register message: A LISP message sent by an ETR to a Map-Server to register its associated EID-Prefixes. In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to be used by the Map-Server when forwarding Map-Requests (re-formatted as Encapsulated Map-Requests) received through the database mapping system. • [AR] This may give the impression that the RLOCs on the Map-Register are only to forward Map-Requests, which is not the case in proxy-reply mode. I would suggest we rephrase this text as follows: "In addition to the set of EID-Prefixes to register, the message includes one or more RLOCs to be used to reach the ETR. The Map-Server uses these RLOCs when it has to forward Map-Requests (potentially re-formatted as Encapsulated Map-Requests) received through the database mapping system." Map-Notify message: A LISP message sent by a Map-Server to an ETR • [AR] I would replace "ETR" with "xTR" so we cover the PubSub behavior as well. For definitions of other terms -- notably Map-Request, Map-Reply, Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR) -- please consult the LISP specification [I-D.ietf-lisp-rfc6830bis]. • [AR] I think that the definitions for Map-Request and Map-Reply should be moved here, and probably we should include the definition for Map-Notify-Ack as well. 6830bis should reference 6833bis for control-plane messages, not the other way around. A Map-Register message contains a list of EID-Prefixes plus a set of RLOCs that can be used to reach the ETR when a Map-Server needs to forward a Map-Request to it. • [AR] Since proxy-reply is a common case, I'd not constrain the meaning of the RLOCs in the Map-Register. I'd remove the last part of the sentence that says "when a Map-Server needs to forward a Map-Request to it." A Map-Resolver receives Encapsulated Map-Requests from its client ITRs and uses a mapping database system to find the appropriate ETR to answer those requests. • [AR] A MR can receive Map-Requests that don't come from ITR and/or that are not encapsulated. If we don't want to change the text, at least I'd add at the beginning: "In a common scenario, a Map-Resolver..." Note that while it is conceivable that a non-LISP-DDT Map-Resolver could cache responses to improve performance, • [AR] The discussion on caching or not at the Map-Resolver goes beyond DDT. We could rephrase this removing the mention to "non-LISP-DDT". The LISP UDP-based messages are the Map-Request and Map-Reply messages. When a UDP Map-Request is sent, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP Map-Reply is sent, the source UDP port number is set to 4342 and the destination UDP port number is copied from the source port of either the Map-Request or the invoking data packet. • [AR] I would remove the first sentence and re-phrase this paragraph as follows: "When a UDP LISP control message is sent and is not a direct reply to a previous control message, the UDP source port is chosen by the sender and the destination UDP port number is set to 4342. When a UDP LISP control message is sent as a direct reply to a previous message, the source UDP port number is set to 4342 and the destination UDP port number is either set to 4342 or copied from the source port of the invoking LISP control message. See the following subsections for details." The UDP checksum is computed and set to non-zero for Map-Request, Map-Reply, Map-Register, and Encapsulated Control Message (ECM) control messages. • [AR] Shouldn't it be computed for all LISP control messages? EID-Prefix: This prefix is 4 octets for an IPv4 address family and 16 octets for an IPv6 address family. When a Map-Request is sent by an ITR because a data packet is received for a destination where there is no mapping entry, the EID-Prefix is set to the destination IP address of the data packet, and the 'EID mask-len' is set to 32 or 128 for IPv4 or IPv6, respectively. • [AR] We should probably rephrase this to don't limit it to IPv4/6 For the latter two cases, the destination IP address used for the Map-Request is one of the RLOC addresses from the Locator-Set of the Map-Cache entry. • [AR] To refresh map-caches before TTL expiration, the destination IP of the Map-Request can be the address of the Map-Server if in proxy-reply. This should be considered here. If the ITR erroneously provides no ITR-RLOC addresses, the Map-Replier MUST drop the M
