Dino, Yet more comments in-line.
Alia On Mon, Jun 20, 2011 at 2:51 PM, Dino Farinacci <[email protected]> wrote: >> Dino, >> >> Comments are in-line > > Thanks for the comments. See responses inline. > >> On Mon, May 30, 2011 at 11:50 PM, Dino Farinacci <[email protected]> wrote: >> >>> Alia comments: >>> >>>> What I most want to see in this draft is a clear description of what >>>> needs to implemented and how. It gives a good survey of the >>>> architectural possibilities and even makes suggestions at the end - >>>> but not quite sufficient to be clear in the details of what needs to >>>> be implemented for interoperability and what is for future >>>> experimentation. >>> >>> Everything in the spec needs to be implemented. Why would you think >>> differently? >> >> There are places in the text where the phrasing is very unclear - for just >> the >> first instance, there is the last paragraph in Sec 4: >> >> "There is a possible solution to this problem which reduces the number >> of many-to-one occurrences of (S-EID,G) entries aggregating into a >> single (S-RLOC,G) entry. If a physical ITR can be assigned multiple >> RLOC addresses and these addresses are advertised in mapping database >> entries, then ETRs at receiver sites have more RLOC address options >> and therefore can join different (RLOC,G) entries for each (S-EID,G) >> entry joined at the receiver site. It would not scale to have a one- >> to-one relationship between the number of S-EID sources at a source >> site and the number of RLOCs assigned to all ITRs at the site, but we >> can reduce the "n" to a smaller number in the "n-to-1" relationship. >> And in turn, reduce the opportunity for data packets to be delivered >> to sites for groups not joined." >> >> This doesn't give a way to force all receiver sites to select the same >> (RLOC,G) for a given (S-EID,G) as you replied was necessary to Jesus' >> comments. > > The above paragraph is showing a tradeoff between one-to-one state between > (S-EID,G) and (S-RLOC,G). If you want good trees at the expense of core > state, you go with this option. If you want to reduce core state, you use > aggregate trees in the core which combine many (S-EID,G) entries into one > (S-RLOC,G) entry. > > Jesus made a lot of comments, so I don't know how this paragraph relates to > which comment. > > If you want to make this thread productive so we can proceed, you need to be > very detailed in your commentary or there is nothing I can do to decide on > how to deal with the comments. I am referring to the following question and your response in the first message of this thread. Jesus comments: 1. Cross-talk duplication of multicast flows when using multiple RLOCS: Consider two receiver sites A and B with the following mappings: Site A: (S1, G) --> (RLOC1, G) (S2, G) --> (RLOC2, G) Site B: (S1, G) --> (RLOC2, G) This would cause Site A to receive duplicate packets for (S1,G). One copy would be encapsulated with source RLOC1 while the second copy will be All sites are suppose to hash to the same RLOC for a given (S-EID,G). So Site B would use (RLOC1,G) as would Site A. >> I can go through the draft again for each example - but phrasing of >> "it is possible", >> "a potential solution", "one approach", etc. do not indicate a >> requirement to implement >> for interoperability. > > I am going to repeat. This draft is experimental. And there are a lot of > potential solutions we have not thought about yet. The ones are presented > make it obvious and convincing that the currently documented potential > solutions should be considered by the implementation, allowing us to leave > room for the implementation to create its own solution for experimentation > and interoperability. > > If you think we have all the answers, and want us to document them, then we > would be lieing. We don't want to lie. ;-) And I know you are not asking > us to do that. Of course not - but I'm looking for enough clarity to understand what the base is to inter-operate & what is trying to address open questions to be investigated during experimentation. >>>> b) Sec 4, second paragraph: "At this point in time, we don't see a >>>> requirement for different locator-sets, priority, and weight policies >>>> for multicast than we have for unicast." but there is an M Priority >>>> and M Weight in the [LISP] draft. Clarification as to why would be >>>> useful... (I know it is to get the RLOCs of the ITRs which shouldn't >>>> be used for unicast traffic.) >>> >>> I added a sentence. >>> >>>> I don't see a mechanism other than the M Priority to obtain the RLOCs >>>> associated with an ITR - since only ETR RLOCs would normally be >>>> included. >>> >>> I don't understand the comment. There is one locator-set, and the RLOCs >>> for >>> encapsulating unicast packets to and the RLOCs for sending multicast join >>> messages to can be a different set within the locator-set. >> >> Ok - let me clarify. The set of RLOCs in a locator-set, until this >> draft, are for the ETR. For multicast, the set of RLOCs required must > > Well, correction, they are for xTRs at the site. And the encoding allows you > to list ITRs as well even though you would not use them as targets of > encapsulation. You achieve this either by setting the priority to 255 or > setting the corresponding R-bit/LSB bit to 0. OK - but this is not stated anywhere in the set of drafts - i.e. either that one should/may include ITRs with a priority of 255 and/or corresponding R-bit to 0. My assumption from what the text says is that those RLOCs shouldn't be used for unicast forwarding. I have seen nothing about what they should be used for (except R-bit = 0 addressing the concerns of removing existing locators). Can you please write this assumption into the draft(s) - both on the including ITRs and on what assumptions the multicast draft may make about it? >> be for the ITR. IF the ITR and ETR are different, there must be a way >> of telling which RLOCs belong to an ITR and which belong to an ETR. > > This is how you encode them in a Map-Reply, as an example of unicast ITRs A > and B, and multicast ITRs C and D: > > locator-set-count:4 > > A, up: 1, uw: 50, mp: 255, mw: 0 > B, up: 1, uw: 50, mp: 255, mw: 0 > C, up: 255, uw: 0, mp: 1, mw: 50 > D, up: 255, uw: 0, mp: 1, mw: 50 > > This describes a site that is doing active-active multihoming for unicast > traffic by having ITRs, which received this Map-Reply, to load-split unicast > flows across encapsulations to A and B. ITRs do not use C and D because the > unicast priority is set to 255. > > A and B are not used for unicast Joins since the multicast priority is set > to 255. > > When ETRs at a receiver site want to join an (EID,G), they will use C and D > and load-split different (S-EID,G) entries across C and D in a active-active > fashion. I agree with this example. My point is that it relies on having the M Priority. I'm asking for the simple set of rules to be spelled out. >> The ONLY way that I can find to do this is from the M Priority and the >> Priority fields. If you intend that RLOCs with a priority=255 are >> assumed to be RLOCs associated with ITRs, then that should be clearly >> stated. I certainly assumed not - there can be reasons to have an >> inactive RLOC, as I understand it. > > Wherever the text says where to send joins and talks about priorities, each > occurrence refers to "multicast priority". I'd have to reread the draft, but I didn't interpret it that way. > And the Basic Overview section says: > > At this point in time, we don't see a requirement for different > locator-sets, priority, and weight policies for multicast than we > have for unicast. However, when traffic engineering policies are > different for unicast versus multicast flows, it will be desirable to > use multicast-based priority and weight values in Map-Reply messages. And, again, my point is that the multicast-based priority and weight values are needed to identify the ITR RLOCs that can be used. I guess that you are talking about traffic engineering policies to distinguish between the cases where there are xTRs and where there are separate ITRs and ETRs. That isn't something which an ETR can trivially deduce about a different site - which is why there are the multicast priority and weight. PLEASE just give the simple rules for what should be taken from a locator-set and what should be placed in it for multicast - and either acknowledge that the M priority is needed or provide what the other mechanism is. >>>> What would be good to add to the draft is the changes to be made to >>>> information such as the Map-Reply messages. E.g. >>>> Set the M Priority for all ETR RLOCs to be 255 >>>> Add the ITR RLOCs and set the Priority to 255 & the M Priority to >>>> something else. >>> >>> They are the same locators. The xTR has one locator-set, the RLOCs are >>> used >>> as a destination for unicast packets or for a destination for multicast >>> joins. >> >> The unicast traffic needs to go to ETRs. The multicast traffic needs >> to go to ITRs. My understanding is that these can be deployed >> separately. If this is not the case for multicast, then that should >> certainly be stated! > > There is one locator-set that is shared when but unicast and multicast > priority is non-255. Otherwise, some locators are used for unicast-only and > others can be used for multicast-only. Sure - the ETR and ITR can be co-located with the same RLOCs. Different sets of RLOCs may be pulled from the same locator-set for unicast and for multicast according to different rules. IF the ETRs are always co-located with the ITRs, then the sets of RLOCs would match. At a meta-level here, this is a case where I feel that clear and exact behavior could be specified - and there aren't questions about experimental uncertainty. However, that has not been done - and is what I am asking for. I think we agree on the desired behavior - but it took inference, substantial background, and assumptions on my part to get there. >>>> c) What happens if the S-EID and S-RLOC collide? In particular, at >>> >>> You have to be more specific on what you mean here. >> >> Can an S-EID and an S-RLOC have the same value? If not, why not? > > Yes, they will when a mPETR sends a native join to a non-LISP source > multicast site. Ok - I think that you answered some of my question in the responses to the main lisp draft. I am concerned about confusion between different trees - if the S-RLOC is used separately and independently of the S-EID. >>>> the ETR and ITR, it seems useful to specify that the xTR has knowledge >>>> of whether the packet was LISP-encapsulated & forwards it either to >>>> receivers that expect it un-LISP-encapsulated (ETR) or to receivers >>>> that expect it LISP-encapsulated (ITR). >> >> If an S-EID and S-RLOC have the same value, what helps disambiguate them >> in a received multicast packet is whether the packet was >> LISP-encapsulated. > > A LISP multicast packet is defined to be a UDP packet with a destination > port of 4341. Yes - but what would be useful is to clearly specify the rules and behavior. Again, this isn't a point where I think there is >>> An EID and RLOC can have the same value just like in the unicast >>> scenario. >> >> That is what I initially assumed - but there are places in the drafts >> where it is assumed that one can tell an EID from an RLOC without any >> additional information or look-ups. I tried to pull them out in my >> comments and mentioned this as a general concern. > > Not true. If you have a specific location of this confusion, POINT OUT THE > TEXT, and we can try to clarify it. I will DEFINITELY do this. There were, in fact, so many (3-4) that I resorted to pulling it out as a higher-layer concern since I thought I must have misunderstood. I will read your updated versions and tell you the specific sentences. An example is immediately below in item (d) on p.15 at the end of MSDP. >>>> d) p. 15 end of MSDP: >>>> "And the choice can be made unilaterally because the ITR at the >>>> site will determine which namespace the destination peer address is >>>> out of by looking in the mapping database service." >>>> >>>> Is there an assumption in LISP that an EID and an RLOC MUST NOT have >>>> the same value?? I've seen this potentially implied, but not >>>> proscriptively stated. >>> >>> There is not architectural. >> >> So how can the ITR determine which namespace the destination peer address >> is >> out of by looking in the mapping database service?? > > I don't understand the question. What is a destination peer address. Please > use LISP defined terminology or else we be second guessing each other. Dino, I am QUOTING the draft text - given above. >> >>>> e) p. 22 first paragraph: >>>> "So the ETR knows to simply propagate the PIM Join/Prune message to >>>> a external-facing interface without converting the (S-EID,G) because >>>> it is an (S,G) where S is routable and reachable via core routing >>>> tables." >>>> >>>> In [INTWRK], it is clear that an EID may be globally routable. This >>>> creates a conflict here, where there is an assumption that if an IP >>>> address is globally routable, then it is not in the EID/RLOC mapping >>>> database. >>> >>> The text says: >>> >>> In this case, S-EID is not in the >>> >>> Farinacci, et al. Expires December 1, 2011 [Page 21] >>> Internet-Draft LISP for Multicast Environments May 2011 >>> >>> >>> mapping database because the source multicast site is using a >>> routable address and not an EID prefix address. So the ETR knows to >>> simply propagate the PIM Join/Prune message to a external-facing >>> interface without converting the (S-EID,G) because it is an (S,G) >>> where S is routable and reachable via core routing tables. >>> >>> So the ETR knows because "there is no mapping database entry and the >>> S-EID >>> is routable". >> >> But in [INTWRK}, the same IP address can be globally routable AND appear >> in the mapping database. > > Then it can be reached either way. Not a problem. It is up the ITR to decide > to encapsulate to the LISP site or send natively. Could you please add that to the draft? As written, I think it says that the ETR can unambiguously tell whether it is an EID or globally routable address. Clarifying that in the cases where this can not be determined, it is up to the ETR to decide how to join would help immensely with clarity. >> Also, how does the ETR know that the S-EID is routable - by getting a >> negative >> Map-Reply? > > It assumes it is routable if not in the mapping database. I understand that there can be different mechanisms for mapping databases - but I think that clearly describing the methods for doing this check - and the appropriate decision-making after would be useful. >> Statements like that of "is using a routable address and not an EID >> prefix address" >> without any further hints imply that there isn't overlap of addresses. > > This string is in two locations in the spec. And it is here: > > Since the ITR in the source multicast site has never received a > unicast encapsulated PIM Join/Prune message from any ETR in a > receiver multicast site, it knows there are no LISP-Multicast > receiver sites. Therefore, there is no need for the ITR to > encapsulate data. Since it will know a priori (via configuration) > that its site's EIDs are not routable, it assumes that the multicast > packets from the source host are sent by a routable address. That > is, it is the responsibility of the multicast source host's system > administrator to ensure that the source host sends multicast traffic > using a routable source address. When this happens, the ITR acts > simply as a router and forwards the multicast packet like an ordinary > multicast router. > > And here: > > The solution to this problem is the same as when an ITR wants to send > a unicast packet to a destination site but needs determine if the > site is LISP capable or not. When it is not LISP capable, the ITR > does not encapsulate the packet. So for the multicast case, when ETR > receives a PIM Join/Prune message for (S-EID,G) state, it will do a > mapping table lookup on S-EID. In this case, S-EID is not in the > > > > Farinacci, et al. Expires December 1, 2011 [Page 21] > Internet-Draft LISP for Multicast Environments May 2011 > > > mapping database because the source multicast site is using a > routable address and not an EID prefix address. So the ETR knows to > simply propagate the PIM Join/Prune message to a external-facing > interface without converting the (S-EID,G) because it is an (S,G) > where S is routable and reachable via core routing tables. > > > Does your comment pertain to these paragraphs. I can change the first to > "using a routable source address (meaning that it is not in the mapping > database system)". Would that suffice? Yes - because it could be both according to [INTWRK]. > The second occurrence says "In this case, the S-EID is not in the mapping > database ...". So it is clear IMO. Why is an S-EID not in the mapping database? Also, the higher meta-question is whether a value A is assigned to either the EID space or the RLOC space? Could site X have an EID with value A while site Y (or even a non-LISP) has an RLOC (or globally routable address) with the same value A? I'll bring this up more clearly in separate email - because this is the crux of many questions I have about being able to tell whether a value A is an EID or an RLOC/globally-routable. >>>> Couldn't a more specific check be done along the lines of: >>>> if the S-EID is reachable via core routing and >>>> i) it is not in the mapping database or >>>> ii) it is in the mapping database, but there are no RLOCs with >>>> an M Priority other than 255? >>>> >>>> f) Text in 9.1.1, 9.1.2 doesn't match the headings well. For >>>> instance, in 9.1.1, there is discussion of how a LISP source site that >>>> sends to non-LISP or uLISP receiver sites also can send to LISP >>>> receiver sites. >>> >>> They actually are correct, but the first start out saying how the trees >>> are >>> built from the receiver side so that text can support the data-flow >>> description that comes later. >>> >>>> In 9.1.2, maybe renaming it to non-mLISP Receiver Sites would be >>>> clearer? >>> >>> We stated up from the definition of a non-LISP receiver site. Creating a >>> new >>> term would add to the number of combinations. The spec doesn't need that >>> extra complexity. >>> >>>> g) In 9.1.4, Mpriority and Mweight are finally mentioned - but as far >>>> as I can tell, they are needed earlier and for the pure mLISP to mLISP >>>> case. Please pull the discussion of this earlier. >>> >>> Can you be more specific please. >> >> Please look at my comment (b) and further elaboration there. I think >> Mpriority is >> needed to find the RLOCs associated with an ITR. > > We already covered this and I hope you are satisfied with my response. If > not, you need to PLEASE SITE TEXT SO WE CAN CORRECT IT. The text is above in the email. I've responded there. >>>> Also, this case is discussed in 9.1.1 last paragraph on p. 21 - but >>>> claimed that it is sufficient to look in the mapping database. Could >>>> you please combine these and bring more consistency to the draft? >>> >>> Combine what? Please be more specific. >> >> How much more specific than the exact sections and paragraphs do you >> need? > > Point out text please in the email. I am asking to combine or clarify the differences between the cases in 9.1.4 and in 9.1.1 last paragraph on p. 21. The specific texts are: "The solution to this problem is the same as when an ITR wants to send a unicast packet to a destination site but needs determine if the site is LISP capable or not. When it is not LISP capable, the ITR does not encapsulate the packet. So for the multicast case, when ETR receives a PIM Join/Prune message for (S-EID,G) state, it will do a mapping table lookup on S-EID. In this case, S-EID is not in the Farinacci, et al. Expires October 7, 2011 [Page 21] Internet-Draft LISP for Multicast Environments April 2011 mapping database because the source multicast site is using a routable address and not an EID prefix address. So the ETR knows to simply propagate the PIM Join/Prune message to a external-facing interface without converting the (S-EID,G) because it is an (S,G) where S is routable and reachable via core routing tables. " and " Special considerations are required for LISP receiver multicast sites since they think the source multicast site is LISP capable, the ETR cannot know if ITR is LISP-Multicast capable. To solve this problem, each mapping database entry will have a multicast 2-tuple (Mpriority, Mweight) per RLOC. When the Mpriority is set to 255, the site is considered not multicast capable. So an ETR in a LISP receiver multicast site can distinguish whether a LISP source multicast site is LISP-Multicast site from a uLISP site. " These are parts of the same "if-then-else" for behavior that are scattered. The first handles the case where the source multicast site is non-LISP & the second handles the case where the source multicast site is uLISP. What is not clear is why/when a uLISP-site would use an EID instead of a globally routable address for a source multicast??? Is that legit? I think the "if-then-else" is: if the source address is not in the mapping database: then it is globally routable - use the (S-global, G) else if the locator-set has no Mpriority < 255 locators then it is a uLISP-site & the source address is globally routable - use the (S-global, G) else pick an RLOC from the locator-set and use (S-RLOC, G) >>>> h) In 9.1.5, is it possible to make a recommendation (e.g. an ITR >>>> SHOULD be able to send two packets based on what its oif-lists are? >>> >>> No, we want to leave it up to the implementation. >> >> So both solutions must be implemented (see your response to my first >> question), configured, and managed??? Why? How will there be >> interoperable implementations? >> >>>> Isn't this already the case because the mLISP ITR could have >>>> internal-facing entries in the (S-EID,G) that need to be replicated >>>> without encapsulation and external-facing entries in the (S-RLOC, G) >>>> that need encapsulation? >>> >>> Yes, but those forwarding rules are up to the multicast routing protocol >>> run >>> in the site. That is, if your comment is to document this. >> >> So - clarity of understanding what needs to be done and ITR behavior is >> good. >> Yes, please document this. As phrased, there's the appearance that an ITR >> doesn't normally need to duplicate packets. > > I am sorry, I am not going to document PIM-DM, PIM-SM, DVMRP, MOSPF, IGMP, > and MLD in this document. If that is your request, it is unreasonable and > adds no value and just creates opportunity for complexity, confusion, and > errors. That is, of course, not my request. My request is to add clarity to the additional behavior that LISP imposes. "Via a multicast protocol, an mLISP ITR may have internal-facing entries in the (S-EID, G) that need to be replicated without LISP-encapsulation (e.g. normal IP behavior) as well as external-facing entries in the (S-RLOC, G) that require encapsulation." That is straightforward and brings a bit of clarity - and also makes it clear that an ITR must be able to make two copies of a packet - one encapsulated & one not. >>>> I understand that this isn't ideal because multiple copies of data are >>>> going into the core - but the trees are different there too. >>> >>> Which trees are different? >> >> The ones referred to in sec 9.1.5: >> >> " 1. Make the LISP ITR in the source multicast site send two packets, >> one that is encapsulated with (S-RLOC,G) to reach LISP receiver >> multicast sites and another that is not encapsulated with >> (S-EID,G) to reach non-LISP and uLISP receiver multicast sites." > > We have no choice but to do this. The receiver sites are incompatible. Right - this is a fine approach. I'm looking for a stake that says "Because an ITR must be able to send two packets, one encapsulated to external-facing entries and one not encapsulated to internal-facing entries, approach (1) SHOULD be implemented." >>>> What I'm looking for is some normative text about what MUST/SHOULD be >>>> supported - even for experimental interoperability. >>> >>> If there are mPETRs deployed an ITR can use option 2. If not, option 1 is >>> the only option. >> >> So - why not require option 1 to be implemented? Is it a requirement to >> support >> mPETRs? > > Yes. So - the operator configures whether mPETRs are available for all cases??? How does an ITR know? >>>> The second option seems like it comes naturally - if a Join comes for >>>> the (S-RLOC, G), then it is sent the encapsulated packet. >>> >>> Right, if joins come from the mPETRs. >> >> Regardless of where the join came from... >> Otherwise, how does the ITR know that the join is from an mPETR > > The joins we are talking about here are native ones, not ECM based joins. So > you don't know if they are coming from mPETRs or non-LISP receiver multicast > sites. ?? If a join comes to (S-RLOC, G), then it is coming from an ETR or mPETR. If the join comes to (S-global/EID, G), then it is coming from a non-LISP receiver multicast site or uLISP site. Alia _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
