I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-l3vpn-mvpn-spmsi-joins-01.txt
Reviewer: James Polk (jmpolk(_at_)cisco(_dot_)com)
Review Date: 2010-10-27
IETF LC End Date: 2010-09-16
IESG Telechat date: (if known)
Summary:
This is a short doc that appears to do what sets out to do. I am not
a PIM or MVPN expert, so take my comments and suggestions as you
would any other comment within the L3VPN WG.
there are a few nits, with some rising up a bit to be minor issues -
but that's as far as it goes. Once these are cleared up, I believe
this doc is ready to progress.
Major issues:
- there are no major issues with this doc.
Minor issues:
- Section 3, 2nd para, second sentence is:
"A Type 4 S-PMSI Join may be used to assign a customer
IPv6 (C-S,C-G) flow to a P-tunnel that is created by
PIM/IPv4. "
I'm curious how else might a Type 4 S-PMSI be used? This sentence
makes it seem unclear as to whether there are any uses a Type 4.
Recommend stating "...Join is used..." or state in this or the next
paragraph how else it can be used (unless I've missed something).
- Section 3.2, 2nd para, 1st sentence is:
"A single UDP datagram MAY carry multiple S-PMSI Join Messages,
as many as can fit entirely within it."
What's the MTU of a UDP packet (or frame)?
Might there be a problem if the MTU of UDP doesn't match the MTU of
the link on the PE? This doesn't appear to be covered by the sentence
above, but should be, IMO (i.e., state that the link MTU is the max
that can fit new S-PMSI Join Messages, or the max bytes UDP allows
should be stated here explicitly).
Nits/editorial comments:
- as someone not familiar with Multicast VPNs, having the acronym
"S-PMSI Join" messages *not* exploded in the abstract is a bit
confusing. I had to look into the first and second paragraphs of the
intro to determine for myself that it means "Selective Provider
Multicast Service Interface", which isn't all in one explosion of
this acronym. This might need to be changed for clarity.
- The second paragraph's first sentence has an "also" that, to me,
appears to be pointing back to the first paragraph. This is oddly disjointed.
- in the second paragraph of the Intro section (2), the first
sentence says "...allows PIM...", then the second sentence starts
with "...requires PIM to be sent..." and I don't get the connection.
I think you mean to basically say "PIM can be used to control PEs. If
PIM is used, message are required to be sent through a P-tunnel from
one PE in an MVPN to others in the same MVPN".
- Intro, 2nd para, 4th sentence
s/"However, that specification..."/"However, RFC 4601..." to be much clearer.
- Intro, 2nd para, last sentence is redundant to what was stated 2
sentences earlier (including the "However..."), and should be removed.
"However, the specification does not cover the
case where the customer flows are IPv6 flows."
- Intro, 3rd para, 1st sentence
s/specifications/capability (or capabilities)
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf