I am reviewing this draft. This is the first part of my review, I've
read up to end of Section 7. I should complete the review tomorrow but
wanted to send out these early comments already today.
So far I've liked what I saw, with the exception of few places where I
think clarifications are needed (see below).
Technical:
The fundamental multicast forwarding model is to encapsulate a
multicast packet into another multicast packet. An ITR will
encapsulate multicast packets received from sources that it serves in
another LISP multicast header.
... but elsewhere you say ...
Ingress Tunnel Router (ITR): a router which accepts an IP multicast
packet with a single IP header (more precisely, an IP packet that
does not contain a LISP header). The router treats this "inner"
IP destination multicast address opaquely so it doesn't need to
perform a map lookup on the group address because it is
topologically insignificant. The router then prepends an "outer"
IP header with one of its globally-routable RLOCs as the source
address field.
I think the first text fragment should have said " An ITR will
encapsulate multicast packets received from sources that it serves in a
LISP multicast header. ", not " An ITR will encapsulate multicast
packets received from sources that it serves in another LISP multicast
header. "
MBGP: Even though MBGP is not a multicast routing protocol, it is
used to find multicast sources when the unicast BGP peering
topology and the multicast MBGP peering topology are not
congruent. When MBGP is used in a LISP-Multicast environment, the
prefixes which are advertised are from the RLOC namespace. This
allows receiver multicast sites to find a path to the source
multicast site's ITRs. MBGP peering addresses will be from the
RLOC namespace.
You should clearly state whether or not there are protocol changes (not
just configuration or address space differences). You say so later in
the conclusions of this section, but I think you should clearly state it
already here.
The same applies to the rest of the items in this section. I think it
will be beneficial to the reader to know if there are no impacts, if
some different configuration is needed or different address space is
used (IGMP and MBGP), implementation changes are needed for some address
mapping or other task (PIM-SM), or if the actual protocol needs to
change in order to support LISP-Multicast. I liked the way the
description was written for PIM-SM, maybe you can do the same for
others. MBGP, MSDP, PIM-Bidir, and PIM-ASM entries were unclear to me.
Editorial:
The terms EID, RLOC, ASM, SSM, Bidir-mode, TE-ITR, TE-ETR, uPITR,
oif-list, RPF should be expanded upon first use (and in some cases you
should point to the relevant reference). Note that some of the terms are
in Section 3 but used in Section 2.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
