Continuing my review.
The document was a pleasure to read and is in very good shape, despite
some areas which were quite complex (such as the different interworking
cases). Thank you for that. I think it is ready to move forward soon
with a few small changes. I also had one question below and I want to
understand the answer to it. Please answer the question and review the
suggested changes. Send mail if there's anything that seems out of order.
Technical:
This specification focuses on what changes are needed to the
multicast routing protocols to support LISP-Multicast as well as
other protocols used for inter-domain multicast, such as Multi-
protocol BGP (MBGP) [RFC4760 <http://tools.ietf.org/html/rfc4760>]. The
approach proposed in this
specification requires no changes to the multicast infrastructure
inside of a site when all sources and receivers reside in that site,
even when the site is LISP enabled. That is, internal operation of
multicast is unchanged regardless of whether or not the site is LISP
enabled or whether or not receivers exist in other sites which are
LISP-enabled.
Therefore, we see changes only to PIM-ASM [RFC4601
<http://tools.ietf.org/html/rfc4601>], MSDP [RFC3618
<http://tools.ietf.org/html/rfc3618>],
and PIM-SSM [RFC4607 <http://tools.ietf.org/html/rfc4607>]. Bidir-PIM [RFC5015
<http://tools.ietf.org/html/rfc5015>], which typically does not
run in an inter-domain environment is not addressed in depth in this
version of the specification.
This text from the Introduction seems to say the protocols change. But
section 7 says
Based on the protocol description above, the conclusion is that there
are no protocol message format changes, just a translation function
performed at the control-plane.
I think you should soften the statement in the introduction to clarify
that only mapping operations and router implementation changes are
required, the protocols themselves are still as they were.
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 (and not registered to the
mapping database system), 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.
I have a question about this. The source network is a LISP site, right?
When you say that it is an admin responsibility to ensure that the hosts
send multicast traffic using a routable source address, what exactly do
you mean? That hosts are configured with multiple addresses, and that
they know which address to use for which traffic?
Therefore, it is the responsibility of ETRs in multicast receiver
sites to map the group address into a group address where the
embedded-RP address is from the RLOC namespace. The mapped RP-
address is obtained from a EID-to-RLOC mapping database lookup. The
ETR will also send a unicast (*,G) Join/Prune message to the ITR so
the branch of the distribution tree from the source site resident RP
to the ITR is created.
I'm not sure I fully understand the implications of this. What has to be
done by the source site to make this happen? Craft a specific database
entry and possibly configure an additional IP address for its ITR? More
generally, this specification would benefit from a "Manageability
Considerations" section that talks about what expectations there are for
the network administrator to configure different parameters in the xTRs
and elsewhere.
Finally, I think the introduction should provide a high-level overview
of what the "in progress" or otherwise uncertain areas of the
specification are, so that experimentation and future deployment
experience can confirm how well these actually work in practice. You
already do quite a bit of that, but I would still make the following edit:
OLD:
Also, the current version of this specification does not describe
multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
descriptions in [LISP].
NEW:
Also, the current version of this specification does not describe
multicast-based Traffic Engineering relative to the TE-ITR and TE-ETR
descriptions in [LISP]. Futher work is also needed to determine the
detailed behavior for multicast proxy ITRs (mPITRs, Section 9.1.3),
mtrace
(Section 12), and locator reachability (Section 6). Finally, further
deployment and experimentation would be useful to understand the
real-life performance of the LISP-Multicast solution. For instance,
the design optimizes for minimal state and control traffic in the
core, but
can in some cases cause extra multicast traffic to be sent (Section
8.1.2).
These are just a few things that I collected from elsewhere in the
document. Feel free to edit the above text, I'm sure you can provide a
more accurate description. But I think some of these things should at
least be mentioned upfront.
Editorial:
And to have the ITR use its own IP address (its RLOC), and
as the source address.
Shouldn't this be: "... use its own IP address (its RLOC) as the source
address."?
9.1.2. Non-LISP Source Site to non-LISP Receiver Sites
Extra space
Section 9 was hard to read. Maybe because its a complex topic.
o A mixed multicast locator-set with the best multicast priority
values MUST NOT be configured on multicast ITRs. A mixed locator-
set can exist (for unicast use), but the multicast priorities MUST
be the set for the same address family locators.
I had trouble parsing this requirement. Do you mean that on a multicast
locator-set, there must always be one address family that is preferred?
Expand the term "RP" when first used.
I think [INTWORK] should be a normative reference, given how it is used
in Section 9.
Therefore, this specifications
focuses on to map a source EID address of a multicast flow during
distribution tree setup and packet delivery.
... this specification focuses ...
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
