The Locator/ID Separation Protocol (LISP) for Multicast Environments
RFC 6831
Yes
(Jari Arkko)
No Objection
(Dan Romascanu)
(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Sean Turner)
No Record
Note: This ballot was opened for revision 14 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
()
Adrian Farrel Former IESG member
(was Discuss)
No Objection
No Objection
(2012-02-08)
The title talks about "LISP for multicast environments" but the Abstract is specific to "inter-domain multicast routing". Should the document title be updated accordingly or is the Abstract wrong? It is possible that the confusion is at bullet 2 of Section 2 where it is implied that a "domain" is a LISP site such that "inter-domain" means between LISP sites. It would be helpful not to re-use "domain" in ths way (we are used to it meaning inter-AS and inter-area). Since multicast between LISP sites is just a special case of multicast using LISP, you could stike the text from the Abstract.
Dan Romascanu Former IESG member
No Objection
No Objection
()
Gonzalo Camarillo Former IESG member
No Objection
No Objection
()
Peter Saint-Andre Former IESG member
No Objection
No Objection
(2011-10-05)
draft-ietf-lisp-ms contains a section entitled "Open Issues and Considerations", which provides a good start toward understanding the parameters of the experiment we're engaging in here, and perhaps some dimensions for measuring success. It would be helpful for this document to contain a similar section. The terminology section repeats definitions from the base LISP spec. This seems like a bad idea. It would be better to reference those definitions and here simply provide the extended information that applies only to multicast environments. The Security Considerations section seems rather sparse. Does the use of LISP in a multicast environment truly have no security implications whatsoever?
Ralph Droms Former IESG member
(was Discuss)
No Objection
No Objection
(2011-10-05)
In the numbered list of scenarios in section 9.1, there are a couple of occurrences of the term "LISP sites." Should "LISP sites" be replaced by "LISP-Multicast sites"? Is it assumed that a uLISP site uses non-LISP transport for multicast? If so, it would be helpful for the document to state that situation explicitly. In the Security Considerations section, if this document introduces no additional security concerns beyond those in LISP base spec, that assertion should be made explicitly.
Robert Sparks Former IESG member
No Objection
No Objection
()
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
()
Russ Housley Former IESG member
No Objection
No Objection
(2011-10-04)
Please consider the editorial comments in the Gen-ART Review by Kathleen Moriarty on 3-October-2011. The review can be found here: http://www.ietf.org/mail-archive/web/gen-art/current/msg06774.html
Sean Turner Former IESG member
No Objection
No Objection
()
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2011-10-17)
- It'd be good to know if this use of LISP claims some benefit over "ordinary" multicast, or if you're just making multicast work ok in a LISP environment. It doesn't matter much, but it'd be nice to say so the reader knows whether or not to get excited:-) - The intro leaves me wondering if a multicast group address is regarded as an EID or RLOC, or if it varies or if it matters. Just wondering. That is described at the start of section 5, but earlier would be good too. - You may want to expand the RPF acronym. - p5, 1st para after bullets - the 1st sentence talks about "protocols" but the 2nd talks about "the protocol" - seems wrong. - Section 10, 1st para, last sentence is missing something, maybe s/need to/and need to/?
Stewart Bryant Former IESG member
(was Discuss)
No Objection
No Objection
(2012-01-17)
"By using the traffic engineering features of LISP" needs a ref. The subtleties of different m/c paths surely belongs after the basic description rather than as the first item The protocols in section 7 need references Mpriority seems to lack a definition
Wesley Eddy Former IESG member
(was No Objection)
No Record
No Record
(2011-10-05)
I support Peter's DISCUSS