|
Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
2015-02-12 08:21:22
That proposed text works for me.
Yours,
Joel
On 2/12/15 3:28 AM, Luigi Iannone wrote:
Hi,
Aren’t we going into to much details for the intro document?
What if we change the sentence in the following way:
OLD (suggested by David)
"in the specific case of a VM/mobile node the EID-prefix should be /32
or /128 (IPv4 or IPv6 respectively)”
NEW
"In the mobility case the EID-prefix can be as small as a full /32 or
/128 (IPv4 or IPv6 respectively) depending on the mobility use-case
(e.g., subnet mobility vs single VM/Mobile node mobility)"
Opinions?
On 12 Feb 2015, at 02:59, Jmh.direct
<jmh(_dot_)direct(_at_)joelhalpern(_dot_)com
<mailto:jmh(_dot_)direct(_at_)joelhalpern(_dot_)com>> wrote:
Temeber that an EID prefix represents a site. A tenant network in a
data center is a viable site. So the prefix as registered for that.
Mobiluty of VMs with the tenant network can be handled internally.
Ypu could instead advertise each VM EID. Tge fact that both cased
work makes doing an introductory description a bit tricky.
Yours,
Joel
Sent from my Samsung smartphone on AT&T
-------- Original message --------
Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
From: "Black, David" <david(_dot_)black(_at_)emc(_dot_)com
<mailto:david(_dot_)black(_at_)emc(_dot_)com>>
To: "Jmh.direct" <jmh(_dot_)direct(_at_)joelhalpern(_dot_)com
<mailto:jmh(_dot_)direct(_at_)joelhalpern(_dot_)com>>,"acabello(_at_)ac(_dot_)upc(_dot_)edu
<mailto:acabello(_at_)ac(_dot_)upc(_dot_)edu>"
<acabello(_at_)ac(_dot_)upc(_dot_)edu
<mailto:acabello(_at_)ac(_dot_)upc(_dot_)edu>>
CC: "farinacci(_at_)gmail(_dot_)com <mailto:farinacci(_at_)gmail(_dot_)com>"
<farinacci(_at_)gmail(_dot_)com
<mailto:farinacci(_at_)gmail(_dot_)com>>,"jmh(_at_)joelhalpern(_dot_)com
<mailto:jmh(_at_)joelhalpern(_dot_)com>" <jmh(_at_)joelhalpern(_dot_)com
<mailto:jmh(_at_)joelhalpern(_dot_)com>>,"damien(_dot_)saucez(_at_)inria(_dot_)fr
<mailto:damien(_dot_)saucez(_at_)inria(_dot_)fr>"
<damien(_dot_)saucez(_at_)inria(_dot_)fr
<mailto:damien(_dot_)saucez(_at_)inria(_dot_)fr>>,"ops-dir(_at_)ietf(_dot_)org
<mailto:ops-dir(_at_)ietf(_dot_)org>" <ops-dir(_at_)ietf(_dot_)org
<mailto:ops-dir(_at_)ietf(_dot_)org>>,"ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>"
<ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>>,"lisp(_at_)ietf(_dot_)org
<mailto:lisp(_at_)ietf(_dot_)org>" <lisp(_at_)ietf(_dot_)org
<mailto:lisp(_at_)ietf(_dot_)org>>,"Black,
David" <david(_dot_)black(_at_)emc(_dot_)com
<mailto:david(_dot_)black(_at_)emc(_dot_)com>>
> In the VM case, am entire service network may be moved to the data
center, and so the EID block for that set can be moved.
For a single VM, that would apply if the VM is using an entire EID
block - most individual VMs aren’t/don’t. Individual /32 and /128
addresses are common for individual VMs, so that’s what’s needed in
general for individual VM movement.
I’d expect the EID block move case to apply for movement of a group of
VMs that are using such a block (e.g., as a subnet), but VM live
migrations cannot be synchronized in general (cold migrations of
powered-off VMs can be, obviously), so even in this case where the
entire EID block moves, if live VM migrations are involved, there are
intermediate stages where the EID block is split between LISP sites
... and hence /32 and /128 prefixes are still what’s wanted.
Thanks,
--David
*From:*Jmh.direct [mailto:jmh(_dot_)direct(_at_)joelhalpern(_dot_)com]
*Sent:* Wednesday, February 11, 2015 7:19 PM
*To:* Black, David; acabello(_at_)ac(_dot_)upc(_dot_)edu
<mailto:acabello(_at_)ac(_dot_)upc(_dot_)edu>
*Cc:* farinacci(_at_)gmail(_dot_)com <mailto:farinacci(_at_)gmail(_dot_)com>;
jmh(_at_)joelhalpern(_dot_)com <mailto:jmh(_at_)joelhalpern(_dot_)com>;
damien(_dot_)saucez(_at_)inria(_dot_)fr
<mailto:damien(_dot_)saucez(_at_)inria(_dot_)fr>;
ops-dir(_at_)ietf(_dot_)org <mailto:ops-dir(_at_)ietf(_dot_)org>;
ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>; lisp(_at_)ietf(_dot_)org
<mailto:lisp(_at_)ietf(_dot_)org>
*Subject:* RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
*Importance:* Low
I thinl we may want to separate VM mobility from mobile devices. Om
the VM case, am entire setvice network may be moved to the data
center, and so the EID block for that set can be moved. In the case
of individually mobile debices or some vatiations on data center
mobility, there is a need to mske sure the full EID is advertised in
the mapping system.
Yours,
Joel
Sent from my Samsung smartphone on AT&T
-------- Original message --------
Subject: RE: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
From: "Black, David" <david(_dot_)black(_at_)emc(_dot_)com
<mailto:david(_dot_)black(_at_)emc(_dot_)com>>
To: "acabello(_at_)ac(_dot_)upc(_dot_)edu
<mailto:acabello(_at_)ac(_dot_)upc(_dot_)edu>"
<acabello(_at_)ac(_dot_)upc(_dot_)edu
<mailto:acabello(_at_)ac(_dot_)upc(_dot_)edu>>
CC: Dino Farinacci <farinacci(_at_)gmail(_dot_)com
<mailto:farinacci(_at_)gmail(_dot_)com>>,"Joel M. Halpern"
<jmh(_at_)joelhalpern(_dot_)com
<mailto:jmh(_at_)joelhalpern(_dot_)com>>,Damien Saucez
<damien(_dot_)saucez(_at_)inria(_dot_)fr
<mailto:damien(_dot_)saucez(_at_)inria(_dot_)fr>>,"ops-dir(_at_)ietf(_dot_)org
<mailto:ops-dir(_at_)ietf(_dot_)org>" <ops-dir(_at_)ietf(_dot_)org
<mailto:ops-dir(_at_)ietf(_dot_)org>>,"ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>"
<ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>>,"lisp(_at_)ietf(_dot_)org
<mailto:lisp(_at_)ietf(_dot_)org>" <lisp(_at_)ietf(_dot_)org
<mailto:lisp(_at_)ietf(_dot_)org>>,"Black,
David" <david(_dot_)black(_at_)emc(_dot_)com
<mailto:david(_dot_)black(_at_)emc(_dot_)com>>
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:albert(_dot_)cabellos(_at_)gmail(_dot_)com]
*Sent:* Wednesday, February 11, 2015 6:33 PM
*To:* Black, David
*Cc:* Dino Farinacci; Joel M. Halpern; Damien Saucez;
ops-dir(_at_)ietf(_dot_)org
<mailto:ops-dir(_at_)ietf(_dot_)org>; ietf(_at_)ietf(_dot_)org
<mailto:ietf(_at_)ietf(_dot_)org>;
lisp(_at_)ietf(_dot_)org <mailto:lisp(_at_)ietf(_dot_)org>
*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.
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
<david(_dot_)black(_at_)emc(_dot_)com
<mailto:david(_dot_)black(_at_)emc(_dot_)com>> wrote:
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).
> >> [A] EID mobility vs. EID prefixes
>
> ... 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.
> >> [B] LISP Multicast vs. EID/RLOC separate
> >>
> >> - 6. Multicast
> >>
> >> This is interesting, multicast addresses (G) look like they're an
exception
>
> 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.
---
> >> -- 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
>
> 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.
> >> Despite multiple mentions of incremental deployment, I did not
> >> see a discussion of how that might be accomplished.
>
> There are PxTRs and NATs. And references to the LISP interworking RFC.
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.
> >> - 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.
>
> 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
> -----Original Message-----
> From: Dino Farinacci [mailto:farinacci(_at_)gmail(_dot_)com
<mailto:farinacci(_at_)gmail(_dot_)com>]
> Sent: Wednesday, February 11, 2015 2:19 PM
> To: Joel M. Halpern
> Cc: Black, David; Albert Cabellos; Damien Saucez;ops-dir(_at_)ietf(_dot_)org
<mailto:ops-dir(_at_)ietf(_dot_)org>;
>ietf(_at_)ietf(_dot_)org <mailto:ietf(_at_)ietf(_dot_)org>; lisp(_at_)ietf(_dot_)org
<mailto:lisp(_at_)ietf(_dot_)org>
> Subject: Re: [lisp] OPS-Dir review of draft-ietf-lisp-introduction-11
>
> > 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.
>
> >> 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.
>
> Thanks a ton.
>
> >> -- 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.
>
> 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.
>
> >>
> >> - 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.
>
> See above example.
>
> >> [B] LISP Multicast vs. EID/RLOC separate
> >>
> >> - 6. Multicast
> >>
> >> 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.
>
> >> 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.
>
> 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.
>
> >> - 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.?
>
> 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.
>
> >> - 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
>
> 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.
>
> >> 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
>
> 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.
>
> >> 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.
>
> 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 --
> >>
> >> 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
>
> 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.
>
> >> 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.
>
> 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".
>
> >> Despite multiple mentions of incremental deployment, I did not
> >> see a discussion of how that might be accomplished. There is some
>
> There are PxTRs and NATs. And references to the LISP interworking RFC.
>
> >> 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.
>
> 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.
>
> >> 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.
>
> 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.
>
> >>
> >> -- 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
>
> We will certainly fixe these. Thanks.
>
> >>
> >> 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?
>
> 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.
>
> >>
> >> - 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.
>
> 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:
> >>
> >>
> >> 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.
>
> Fair enough.
>
> >> - 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).
>
> Already noted and will be fixed.
>
> >>
> >> - 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.
>
> Good suggestion and makes sense.
>
> >> - 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.
>
> Hmm, I'll let Albert and Damien decide if we should state "EID-prefixes"
> everywhere instead of just "EID".
>
> >>
> >> - 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.
>
> 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.
>
> >> - 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.
>
> Agree.
>
> >> idnits 2.13.01 didn't find any nits.
> >>
> >> Thanks,
> >> --David
>
> Thanks again David.
>
> Dino
|
|