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 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.
a) Could you add a definition for uPITR? It is first used on p.9 in
the mPETR definition and only on p. 22 is it described as
"(where in unicast it acts as a "Proxy ITR", or an uPITR)"
I do not want to duplicate the definition from the Interworking
spec. I will
add a reference though.
Looks good
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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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?
The second occurrence says "In this case, the S-EID is not in the
mapping database ...". So it is clear IMO.
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.
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.
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.
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.
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.
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.
Dino
Alia
g) p. 21 Sec 9.1.1 end of second paragraph:
"It is important to note that the routable address for the host
cannot
be the same as an RLOC for the site. Because we want the ITRs to
process a received PIM Join/Prune message from an external-facing
interface to be propagated inside of the site so the site-part of
the
distribution tree is built."
Is this supposed to be one sentence??
I fixed it up a bit. Thanks.
h) typo: p. 9 mPETR definition, last sentence: "co-loacted" -> co-
located
i) typo: p. 23 4th line from bottom: "oins to" -> joins to
j) typo: p.27 first sentence: "MUST not" -> MUST NOT
k) typo: Sec 11 last sentence: "addition to slow" -> "addition due
to
slow"
l) [LISP] needs to be Normative - it has the packet formats!
Fixed all these. Thanks.
Thanks,
Dino/Dave/Stig/JohnZ
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
