Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx)
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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]