Subject: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11

From: "Black, David" <[email-masked]>
Date: Tue, 10 Feb 2015 23:25:03 +0000

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call
may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last call
comments.

Document: draft-ietf-lisp-introduction-11
Reviewer: David Black
Review Date: Feb 10, 2015
IETF LC End Date: Feb 4, 2015 (on -10)

Summary: This draft is on the right track, but has open issues
 		described in the review.

First of all, I apologize for this review showing up after the end of
IETF Last Call on this draft.  I plead being one of the victims of this
year's flu vaccine being poorly matched to the prevalent flu viruses.

The draft is generally well written and provides a nice introduction to
LISP - good job.  Most of the usual OPS-Dir questions in Appendix A of
RFC 5706 do not apply, as they are better addressed by the additional
material in the RFCs that specify the actual LISP protocol specifications.
Nonetheless, there are a few that apply, as noted in the issues below.

I found a couple of major issues that I hope arise from the
summarization of LISP in this draft, as opposed to being problems in
the actual LISP protocols.  I also found a few minor issues, the most
important of which is the need for additional security considerations
discussion on misdelivery, with particular attention to VPNs.

-- Major issues --

[A] EID mobility vs. EID prefixes

- 5. Mobility

I understand how this works when mapping is per-EID, but how does this work
when the EID of the system that moves is part of an EID prefix, as discussed
in Section 3.4.1?  Even if the answer is a long version of "Don't do that!"
it should be explained.

- 7.4.  LISP for Virtual Machine Mobility in Data Centers

I don't understand how this works when EID prefixes are used, as each VM
has its own EID or EIDs, hence the entire prefix range does not move when
the VM moves.

For OPS-Dir, this EID prefix issue [A] falls under A.1.1 in Appendix A
of RFC 5706:  Has deployment been discussed? and specifically under:

       *  Is the proposed specification deployable?  If not, how could
          it be improved?

as EID prefixes appear to be undeployable for Mobility and VM Mobility usage.

[B] LISP Multicast vs. EID/RLOC separate

- 6. Multicast

This is interesting, multicast addresses (G) look like they're an exception
to the EID/RLOC separation as the same destination IP multicast address
is used for both purposes.  This could use some more discussion, as it's
unexpected based on the contents of the draft up to this point.

- 7.2.  LISP for IPv6 Co-existence

   LISP encapsulations allows to transport packets using EIDs from a
   given address family (e.g., IPv6) with packets from other address
   families (e.g., IPv4).

How does that work for multicast traffic, where the destination address
(G) has to be the same in both the inner and outer headers?  Are ETRs
and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.?

- 7.3.  LISP for Virtual Private Networks

This also has multicast problems, as there is only one instance of each
multicast address (G) in the underlay network.  I think I can figure out how
to make multicast work for this use case, but it's not immediately obvious,
and the result when the same underlay multicast address is used by more
than one VPN could well deliver some traffic to ETRs that have to discard
it because the Instance ID is wrong (and that excessive delivery is a
security consideration, see minor issue on Section 8 below).  I think an
explanation is in order.

For OPS-Dir, this multicast issue [B] falls under A.1.4 in Appendix A of
RFC 5706: Have the Requirements on other protocols and functional
       components been discussed?

-- Minor Issues --

There seems to be an implicit assumption that the end host and its
ITR (xTR) are in the same domain or Autonomous System.  For incremental
deployment, I don't think that's always the case, but I think that only
has editorial impact on this document, as I don't think any of the
fundamental LISP mechanisms are affected.  The authors should look for
use of "domain" and "Autonomous System" and ensure that the text is
generalized to the case where the end host and ITR are more widely
separated.

Despite multiple  mentions of incremental deployment, I did not
see a discussion of how that might be accomplished.  There is some
useful content in Section 3.5, but that's at best an incomplete
explanation.  This is an OPS-Dir review concern - it falls under
A.1.3 in Appendix A of RFC 5706: Has the migration path been discussed?

- 3.3.1.  LISP Encapsulation

   the source port is selected by 
   the ITR and ignored on reception.

Please mention multipathing (e.g., ECMP and LAG) as possible influences
on how source ports are selected, as this imposes some limits on what an
ITR can reasonably do.

For OPS-Dir, this multipathing concern falls under A.1.4 in Appendix A of
RFC 5706: Have the Requirements on other protocols and functional
       components been discussed?

   This decision was made because the
   typical transport protocols used by the applications already include
   a checksum, by neglecting the additional UDP encapsulation checksum
   xTRs can forward packets more efficiently.

Groan!  I have an exquisite set of scars on UDP zero checksums for IPv6
from working on the MPLS in UDP draft, so I may be overly sensitive to
this concern.  The downside of this efficiency is that there is no
checksum coverage of the IPv6 header when zero UDP checksums are used.
That should at least be mentioned here, with a summary of why that's ok
- the detailed justification for why that's ok can be left to other
documents.

For OPS-Dir, this UDP zero checksum for IPv6 concern also falls under
A.1.4 in Appendix A of RFC 5706:
   Have the Requirements on other protocols and functional
       components been discussed?

- 8 Security Considerations

This should discuss possibility of misdelivery of LISP-encapsulated
packets to the wrong ETR and the resulting security consequences.  This
is particularly relevant to the VPN use case in Section 7.3.  This
discussion should also note that omitting the UDP checksum for IPv6
increases the opportunity for misdelivery.

For OPS-Dir, this security concern falls under A.1.5 in Appendix A of
RFC 5706: Has the impact on network operation been discussed?

This is because dealing with any such misdelivery will have an operational
impact.

-- Nits/Editorial Comments --

- Top of p.4:

   The initial motivation in the LISP effort is to be find in the

"find" -> "found"

- Section 3.1, first bullet item

      Devices are assigned with relatively opaque identity
      meaningful addresses that are independent of their topological
      location.

I don't understand "relatively opaque identity meaningful" and
suggest rewriting the sentence.  In particular - opaque to what?
meaningful to what in what manner?

- Section 3.2, second paragraph

Judging from the figure, xTRs are the common case, with single-
function ITRs and ETRs being rare.  It might be good to say that
and discuss when ITRs and ETRs that are not xTRs are appropriate
to use.

- 3rd paragraph on p.7:

   Finally, the LISP architecture emphasizes a cost effective
   incremental deployment.

I'd delete "cost effective" here and look for other occurrences
of "cost" as candidates for deletion.  This is supposed to be
a technical document, so discussion of costs is a bit off-target.

- First item after Figure 2:

   1.  HostA retrieves the EID_B of HostB, typically querying the DNS
       and obtaining and A or AAAA record.

"and A" -> "an A"  (spelling checkers don't catch everything).

- 3.3.1.  LISP Encapsulation

   On the other hand, Recursive
   tunnels are nested tunnels and are implemented by using multiple LISP
   encapsulations on a packet.

The above sentence seems out of place in the middle of a paragraph about
Re-encapsulating tunnels and routers - I suggest moving it down into its
own paragraph and perhaps adding a sentence about where/how Recursive
tunnels may be useful.

- 3.3.2.  LISP Forwarding State

   In the LISP architecture, ITRs keep just enough information to route
   traffic flowing through it.

"it." -> "them."

   Meaning that, ITRs retrieve from the
   LISP Mapping System mappings between EID prefixes and RLOCs that are
   used to encapsulate packets.

This is the first use of the notion of EID prefixes.  That concept should
be explained before it is used, although a forward reference to section
3.4.1 may suffice.  It might be better to rewrite this paragraph in terms
of EIDs and leave the notion of EID prefixes to section 3.4.1.

- 4.4.  MTU Handling

   Additionally, LISP also recommends inferring reachability of locators
   by using information provided by the underlay, in particular:

It'd be useful to add a sentence or two about how LISP and the techniques
in this section interact with host use of PMTUD and PLPMTUD.

- Next to last paragraph on p.17:

   Additionally, LISP also recommends inferring reachability of locators
   by using information provided by the underlay, in particular:

This looks like it's a paragraph early and needs to be moved down to
after the paragraph that follows it.

idnits 2.13.01 didn't find any nits.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Feb 2015 18:45:49 -0500

I will leave most of these for the authors to comment on.

With regard to your question about incremental deployment, that is the 
domain of the LISP Deployment document, and was deliberately only 
lightly covered here.  I am not sure what we can do to address your 
comment without duplicating the entirety of that document.

With regard to UDP Zero, this was approved by the IESG and published as 
an RFC.  It is part of the way the protocol is defined.  If there are 
specific changes you would like to see in the explanatory text, I am 
sure we could include them.  If you are looking for a change in the 
behavior, this document can not make changes to the LISP behavior.

Yours,
Joel

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Feb 2015 00:02:00 +0000

Joel,

Thanks for the quick response.

On incremental deployment, a few sentences on the role/usage of PITRs and
PETRs in incremental deployment plus considerations for how both EIDs and
fully routable IPv4 and IPv6 addresses can be used as destination addresses
from the same LISP host would be helpful (e.g., I'm reasonably certain that
this has implications for which IP address blocks can be used for EIDs, if
for no other reason than PETRs announce EID address blocks as fully routable
in the Internet).

On UDP zero checksum for IPv6, I'm not looking for protocol changes, but
I'd like to see some summarized discussion of the design rationale that
aligns  what LISP does with RFC 6936.  As noted in the review, the full
details don't belong here, but a technical summary of why this is ok beyond
"The IESG said so" ;-) would be helpful.  FWIW I'm not a strong believer in
that sort of "proof by authority" :-).

Thanks,
--David

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Tuesday, February 10, 2015 6:46 PM
> To: Black, David; [email-masked]; [email-masked]; ops-
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: OPS-Dir review of draft-ietf-lisp-introduction-11
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Feb 2015 11:19:05 -0800

> I will leave most of these for the authors to comment on.

See my comments inline. Thanks David for your detailed review and commentary.

> With regard to your question about incremental deployment, that is the domain of the LISP Deployment document, and was deliberately only lightly covered here.  I am not sure what we can do to address your comment without duplicating the entirety of that document.

That is the risk we may have with many of your comments. We have a lot of detail in the already 9 published RFCs  and this document really is to take all that detail and summarize as an easily understandable description of a cohesive design.

> With regard to UDP Zero, this was approved by the IESG and published as an RFC.  It is part of the way the protocol is defined.  If there are specific changes you would like to see in the explanatory text, I am sure 

Definitely agreed. In fact we instigated UDP zero. And I continually talk to hardware engineers and they all believe we made the right decision. So hats off to the IETF for being practical.

> we could include them.  If you are looking for a change in the behavior, this document can not make changes to the LISP behavior.

Yes, an important point.

>> discussion on misdelivery, with particular attention to VPNs.

Thanks a ton.

>> in Section 3.4.1?  Even if the answer is a long version of "Don't do that!"

No, from the start of the LISP design (circa 2007), an prefix is what moves. And a specific EID is simply a /32 or /128 prefix. Here is a practical example:

You have a cluster of servers that communicate together for a particular application. They application cluster is running in a set of VMs. Those VMs are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are currently running in a brick-and-mortar data center. Now there is a desire to move the VM cluster to a cloud provider. What is moved is the EID-prefix of the cluster. The mapping system is told that the EID-prefix is changing its RLOC-set from the brick-and-mortar xTRs to the cloud providers xTRs.

>> as EID prefixes appear to be undeployable for Mobility and VM Mobility usage.

See above example.

>> This is interesting, multicast addresses (G) look like they're an exception

They are really not. Since multicast addresses *identify* a group of receivers, it is very much an EID and aheres to the definition of an EID. Multicast addresses never had topological signficance but the state representing a distribution tree does tell you were the members are (but the identity of the members are not know in multicast).

So it makes perfect sense to register multicast addresses to the mapping system as EIDs and they can map to RLOCs of sites that have joined the group. See draft-farinacci-signal-free-multicast as just one example. RFC6831 and draft-farinacci-lisp-mr-signaling are other examples.

>> unexpected based on the contents of the draft up to this point.

I believe the level of detail we have in the introduction document is at the right level or we'll err on having way too many details crop in.

>> and ITRs expected to map IPv6 multicast addresses to IPv4 and v.v.?

The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RLOC set that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that receives the packet from S-EID-ipv6 would replicate the packet and multicast encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast.

>> multicast address (G) in the underlay network.  I think I can figure out how

You can map from EID-G to RLOC-G one to one. But we have seen over the last decade in a half that with general multicast deployment that many-to-1 is desirable. Hence, now that we have a way to map with a network-based database, we can map multiple EID-Gs to a single (or multiple) RLOC-Gs.

>> than one VPN could well deliver some traffic to ETRs that have to discard

This is a necessary evil when the underlay is state challenged. But it is a state/bandwidth tradeoff. We have found with MVPN deployment that the network admin configures the underly or simply unicasts.

>> security consideration, see minor issue on Section 8 below).  I think an

There are just too many combinations to make a high-level description simple to understand. The current introduction text does a find job providing references for someone to go off and get the details.

>> ITR (xTR) are in the same domain or Autonomous System.  For incremental

This is true when you call the domain a "LISP site". But if the site is unchanged and one uses PITRs, maybe even close to the site, like in a PE router, then the PITR is definitely in another AS. But note I said PITR and not ITR. The reason being is because an ITR is configured with database-mapping prefixes that is uses to encapsulate packets from such addresses. Versus the PITR being an ITR with *no database-mappings* providing a much more larger/or more aggregtable service.

>> generalized to the case where the end host and ITR are more widely

We are overloaded with terms that create topological or organization boundary. Hence why we created "LISP site" which is also the same as a "LISP VPN site". Where a "LISP site" that has multiple tennants would be multiple "LISP VPN sites".

>> see a discussion of how that might be accomplished.  There is some

There are PxTRs and NATs. And references to the LISP interworking RFC.

>> on how source ports are selected, as this imposes some limits on what an

ECMP/LAG don't influence which source port is selected. It is a 5-tuple hash of the inner header that selects a source port that influences how an underlay router would load-split traffic.

>> - the detailed justification for why that's ok can be left to other

My head spins every time I hear about this subject. This subject has been talked about from 100s of people for a decade. We have CRC on links, we have apps that use TCP and UDP checksums. Nuf said.

>> - Section 3.1, first bullet item

We will certainly fixe these. Thanks.

>> meaningful to what in what manner?

Well beacuse it is as accurate as it can be. If automobiles are going to be assigned EIDs from a VIN number allocation from a manufacture, the address is relatively opaque. If a VM in a data-center is going to be assigned an EID from the set of prefixes already being used and allocated to that data-center, then there is a good chance that address is in a power-of-2 block that is summarizable in the IGP.

>> and discuss when ITRs and ETRs that are not xTRs are appropriate

When you want egress path selection to happen further out in the toplogical from the source location, then you put an ITR-only system there. Where ingress to the same source (destination in this direction), the ETR can be closer to the destination.

>> a technical document, so discussion of costs is a bit off-target.

Fair enough.

>> "and A" -> "an A"  (spelling checkers don't catch everything).

Already noted and will be fixed.

>> own paragraph and perhaps adding a sentence about where/how Recursive

Good suggestion and makes sense.

>> of EIDs and leave the notion of EID prefixes to section 3.4.1.

Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes" everywhere instead of just "EID".

>> in this section interact with host use of PMTUD and PLPMTUD.

This is a lot of detail because in RFC6830 we have 3 positions or options on the subject. And we did provide a reference to RFC6830 for this topic.

>> after the paragraph that follows it.

Agree.

>> idnits 2.13.01 didn't find any nits.

Thanks again David.

Dino

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Feb 2015 23:07:09 +0000

Dino - thanks for the response.

On the major issues, it looks like both [A] and [B] involve only the text
in this draft and nothing beyond, which is good news.  I have a simple text
suggestion for [A], but it looks like [B] is going to require some careful
editing, as one of the primary causes is that the draft is sloppy in using
the same symbol "G" to represent both EID and RLOC multicast groups.

On the minor issues, I have text suggestions for three of the four, and
I'd like to temporarily defer further discussion the IPv6 UDP zero
checksum "tarpit" in favor of resolving everything else first.

On the nits/editorial comments, all the suggestions in your email are fine
with me.  FWIW, I regard that portion of a review as almost entirely
subject to the draft authors' discretion (and editorial taste).

> ... from the start of the LISP design (circa 2007), an prefix is what moves.
> And a specific EID is simply a /32 or /128 prefix. Here is a practical
> example:

A statement that the mobility use cases need to employ /32 and /128 prefixes,
and not anything coarser should suffice.  That should be added to Section 5.

> They are really not.

My concern is that as I read the draft, it leaves me with the strong impression
that the same multicast addresses (G) are being used in both the overlay
(as EIDs) and the underlay (as RLOCs).  From your response, I conclude that this
is not the case (and I have no argument with that).  Rather, Section 6 needs to
bluntly state that multicast addresses are mapped between EID and RLOC space at
both ITRs and ETRs, so that the following inference is obvious from the text
(it's currently not obvious):

> So it makes perfect sense to register multicast addresses to the mapping
> system as EIDs and they can map to RLOCs of sites that have joined the group.

As part of this, I strongly recommend moving away from use of "G" to refer to
multicast groups in both the overlay and underlay.  Careful use of G-EID
and G-RLOC would significantly improve clarity.

---
If the above are done for [A] and [B] in Sections 5 and 6, then the text for the
use cases in Section 7 should not need further attention.
---

> This is true when you call the domain a "LISP site". But if the site is
> unchanged and one uses PITRs, maybe even close to the site, like in a PE
> router, then the PITR is definitely in another AS.

Looking at the text, it seems that "LISP site" and "domain" are the same
concept for this draft.  That would be useful to state, IMHO but I'll leave
the decision on whether to do so to you and the draft authors.

On rereading, my concerns seem to be triggered mostly by this sentence in
Section 3.2:

   The edge consists of LISP sites (e.g., an
   Autonomous System) that use EID addresses.

I think a small change to the last sentence in that paragraph would resolve
my concern without distracting from the narrative:

OLD
   EIDs do not
   contain inter-domain topological information and because of this,
   EIDs are usually routable at the edge (within LISP sites) or in the
   non-LISP Internet.
NEW
   EIDs do not
   contain inter-domain topological information and because of this,
   EIDs are usually routable at the edge (within LISP sites) or in the
   non-LISP Internet; see Section 3.5 for discussion of LISP site
   internetworking with non-LISP sites and domains in the Internet.

> >> see a discussion of how that might be accomplished.
> 

Ok, can we just say so in Section 3.5?  Adding the following sentence
to the end of the section would suffice:

   PITRs, PETRs and LISP-NAT support incremental deployment of LISP
   by providing significant flexibility in location of the boundaries
   between the LISP and non-LISP portions of the network, and making
   it reasonable to change those boundaries over time.

> ECMP/LAG don't influence which source port is selected. It is a 5-tuple hash
> of the inner header that selects a source port that influences how an underlay
> router would load-split traffic.

Please state that a 5-tuple hash is used.  ECMP/LAG is among the important
reasons why, but that doesn't need to be stated if you prefer not to.  An
example of something that needs to be excluded is that using a random
number generator to set the source port would be wrong - I could suggest
citing draft-ietf-dart-dscp-rtp for related discussion (and lots more
details), but I don't think that's necessary.

-- IPv6 zero UDP checksum

> My head spins every time I hear about this subject. This subject has been
> talked about from 100s of people for a decade. We have CRC on links, we have
> apps that use TCP and UDP checksums. Nuf said.

Understood - there's more than one set of scars on this one :-(.  Let's come back
to this topic after we've resolved everything else, and please keep in mind
that I tagged this as a minor issue, not a major one (e.g., the above changes
for [A] and [B] are far more important, IMHO).

Thanks,
--David

> From: Dino Farinacci [mailto:[email-masked]]
> Sent: Wednesday, February 11, 2015 2:19 PM
> To: Joel M. Halpern
> Cc: Black, David; Albert Cabellos; Damien Saucez; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
> 
> domain of the LISP Deployment document, and was deliberately only lightly
> covered here.  I am not sure what we can do to address your comment without
> duplicating the entirety of that document.
> 
> That is the risk we may have with many of your comments. We have a lot of
> detail in the already 9 published RFCs  and this document really is to take
> all that detail and summarize as an easily understandable description of a
> cohesive design.
> 
> > With regard to UDP Zero, this was approved by the IESG and published as an
> RFC.  It is part of the way the protocol is defined.  If there are specific
> changes you would like to see in the explanatory text, I am sure
> 
> Definitely agreed. In fact we instigated UDP zero. And I continually talk to
> hardware engineers and they all believe we made the right decision. So hats
> off to the IETF for being practical.
> 
> > we could include them.  If you are looking for a change in the behavior,
> this document can not make changes to the LISP behavior.
> 
> Yes, an important point.
> 
> No, from the start of the LISP design (circa 2007), an prefix is what moves.
> And a specific EID is simply a /32 or /128 prefix. Here is a practical
> example:
> 
> You have a cluster of servers that communicate together for a particular
> application. They application cluster is running in a set of VMs. Those VMs
> are assigned EIDs from a common power-of-2 EID-prefix. Those VMs are currently
> running in a brick-and-mortar data center. Now there is a desire to move the
> VM cluster to a cloud provider. What is moved is the EID-prefix of the
> cluster. The mapping system is told that the EID-prefix is changing its RLOC-
> set from the brick-and-mortar xTRs to the cloud providers xTRs.
> 
> >>
> They are really not. Since multicast addresses *identify* a group of
> receivers, it is very much an EID and aheres to the definition of an EID.
> Multicast addresses never had topological signficance but the state
> representing a distribution tree does tell you were the members are (but the
> identity of the members are not know in multicast).
> 
> So it makes perfect sense to register multicast addresses to the mapping
> system as EIDs and they can map to RLOCs of sites that have joined the group.
> See draft-farinacci-signal-free-multicast as just one example. RFC6831 and
> draft-farinacci-lisp-mr-signaling are other examples.
> 
> I believe the level of detail we have in the introduction document is at the
> right level or we'll err on having way too many details crop in.
> 
> The mapping system can map an (S-EID-ipv6, group-ipv6) 2-tuple to a RLOC set
> that looked like this (ipv4-multicast, ipv4-unicast) mean the ITR that
> receives the packet from S-EID-ipv6 would replicate the packet and multicast
> encapsulate to ipv4-multicast and unicast encapsualte to ipv4-unicast.
> 
> You can map from EID-G to RLOC-G one to one. But we have seen over the last
> decade in a half that with general multicast deployment that many-to-1 is
> desirable. Hence, now that we have a way to map with a network-based database,
> we can map multiple EID-Gs to a single (or multiple) RLOC-Gs.
> 
> This is a necessary evil when the underlay is state challenged. But it is a
> state/bandwidth tradeoff. We have found with MVPN deployment that the network
> admin configures the underly or simply unicasts.
> 
> There are just too many combinations to make a high-level description simple
> to understand. The current introduction text does a find job providing
> references for someone to go off and get the details.
> 
> >> -- Minor Issues --
> >>
> This is true when you call the domain a "LISP site". But if the site is
> unchanged and one uses PITRs, maybe even close to the site, like in a PE
> router, then the PITR is definitely in another AS. But note I said PITR and
> not ITR. The reason being is because an ITR is configured with database-
> mapping prefixes that is uses to encapsulate packets from such addresses.
> Versus the PITR being an ITR with *no database-mappings* providing a much more
> larger/or more aggregtable service.
> 
> We are overloaded with terms that create topological or organization boundary.
> Hence why we created "LISP site" which is also the same as a "LISP VPN site".
> Where a "LISP site" that has multiple tennants would be multiple "LISP VPN
> sites".
> 
> ECMP/LAG don't influence which source port is selected. It is a 5-tuple hash
> of the inner header that selects a source port that influences how an underlay
> router would load-split traffic.
> 
> My head spins every time I hear about this subject. This subject has been
> talked about from 100s of people for a decade. We have CRC on links, we have
> apps that use TCP and UDP checksums. Nuf said.
> 
> >>
> Well beacuse it is as accurate as it can be. If automobiles are going to be
> assigned EIDs from a VIN number allocation from a manufacture, the address is
> relatively opaque. If a VM in a data-center is going to be assigned an EID
> from the set of prefixes already being used and allocated to that data-center,
> then there is a good chance that address is in a power-of-2 block that is
> summarizable in the IGP.
> 
> >>
> When you want egress path selection to happen further out in the toplogical
> from the source location, then you put an ITR-only system there. Where ingress
> to the same source (destination in this direction), the ETR can be closer to
> the destination.
> 
> >>
> >> - 3rd paragraph on p.7:
> >>
> >>
> This is a lot of detail because in RFC6830 we have 3 positions or options on
> the subject. And we did provide a reference to RFC6830 for this topic.
>

---

From: Albert Cabellos <[email-masked]>
Date: Thu, 12 Feb 2015 00:32:59 +0100

Hi David

Thanks for your comments, I am parsing them and I´ll suggest new text
aiming to address them ASAP.

I would also like to better understand [A] before doing this.

With LISP an EID-preifx can have an arbitrary length and can move (i.e.,
change its RLOC bindings), in the specific case of a VM/mobile node the
EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). What doesn't
work is the mobility of a node (assigned with a /32 or /128) *within* a
coarser EID-prefix, in this case you need to split the prefix into more
specifics and register them independently in the Mapping System,
effectively creating new EID-prefixes.

Please let me know if this clarifies your comment, in this case I will
suggest new text for Section 5.

Albert

On Thu, Feb 12, 2015 at 12:07 AM, Black, David <[email-masked]> wrote:

> > >> multicast address (G) in the underlay network.  I think I can figure
> out
> > how
> >

---

From: "Black, David" <[email-masked]>
Date: Wed, 11 Feb 2015 23:40:17 +0000

Hi Albert,

As noted below, on the EID prefix for mobility issue, a simple statement in Section 5 to the effect that “in the specific case of a VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively)” will suffice.  Details on what to do when that advice is ignored can be left to other documents.

Thanks,
--David

From: Albert Cabellos [mailto:[email-masked]]
Sent: Wednesday, February 11, 2015 6:33 PM
To: Black, David
Cc: Dino Farinacci; Joel M. Halpern; Damien Saucez; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11

Hi David

Thanks for your comments, I am parsing them and I´ll suggest new text aiming to address them ASAP.

With LISP an EID-preifx can have an arbitrary length and can move (i.e., change its RLOC bindings), in the specific case of a VM/mobile node the EID-prefix should be /32 or /128 (IPv4 or IPv6 respectively). What doesn't work is the mobility of a node (assigned with a /32 or /128) *within* a coarser EID-prefix, in this case you need to split the prefix into more specifics and register them independently in the Mapping System, effectively creating new EID-prefixes.

Please let me know if this clarifies your comment, in this case I will suggest new text for Section 5.

Albert

On Thu, Feb 12, 2015 at 12:07 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:
Dino - thanks for the response.

---

OLD
   EIDs do not

Thanks,
--David

> From: Dino Farinacci [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Black, David; Albert Cabellos; Damien Saucez; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Feb 2015 20:39:31 -0800

> the same symbol "G" to represent both EID and RLOC multicast groups.

Okay for [A] but not true for [B]. In RFC6831, a multicast address G is not in the mapping database because signaling is performed from ETR to ITR. What's in the mapping database is the EID S from the (S,G) the source sends from and to.

> checksum "tarpit" in favor of resolving everything else first.

Sounds good David.

> and not anything coarser should suffice.  That should be added to Section 5.

Well I think it is not true. Because EID-prefixes are moved but is outside of the VM-mobility use-case.

> (as EIDs) and the underlay (as RLOCs).  From your response, I conclude that this

Understand. We state in RFC6831 that it can map one-to-one or many-to-one. We'll make that more clear in the introduction document.

> (it's currently not obvious):

Right, agree.

> and G-RLOC would significantly improve clarity.

Well we have not used G-EID in any documentation. And since we want to encourage the use of SSM in the underlay and how we signal in the overlay, we simply call the "eid" the 2-tuple (S,G).

>   internetworking with non-LISP sites and domains in the Internet.

Ack.

>   it reasonable to change those boundaries over time.

Yes.

> Please state that a 5-tuple hash is used.  ECMP/LAG is among the important

Well there can be other ways to hash and that is detail not needed at this level IMO. We suggest a 5-tuple hash in RFC6830.

> details), but I don't think that's necessary.

How about stating the source-port should not change for a flow or it causes an underlay router to resequence packets over lags?

> for [A] and [B] are far more important, IMHO).

Ack. Thanks again.

Dino

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 12 Feb 2015 09:23:57 +0100

> On 12 Feb 2015, at 05:39, Dino Farinacci <[email-masked]> wrote:
> 

[snip]
> Well we have not used G-EID in any documentation. And since we want to encourage the use of SSM in the underlay and how we signal in the overlay, we simply call the "eid" the 2-tuple (S,G).

I second DIno on this point.
In the evolution of this document one discussion point was about the terminology to use. 
The final choice was to avoid to introduce any terminology not used in the current set of RFCs.
Introducing “G-EID” and "G-RLOC” would go against that decision (and confuse the reader since it will never agin find such terms).

What if we drop the dashes?  

G-EID     =>  the EID multicast group G 
G-RLOC =>  the RLOC multicast group G

Yes bit prolix!

Could this work?

Luigi

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 12 Feb 2015 05:14:56 -0800

> G-RLOC =>  the RLOC multicast group G

"inner and outer group addresses" have been used in various LISP multicast documents. 

Dino