> 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.
While there is no other use of the Type 4 S-PMSI Join, there are other
mechanisms that may be used for the same purpose. If the text read "is
used", someone might interpret that as meaning that there is no other
mechanism for assigning a v6 flow to a v4 P-tunnel. So I think the wording
should remain as is.
> - 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).
I think it would be an inappropriate layering violation to state the maximum
UDP size in this specification.
If someone were to create a UDP packet that exceeded the link MTU,
presumably it would get fragmented and reassembled. This might not be a
wise implementation, but it would still work, and I don't see a reason to
prohibit it.
> - as someone not familiar with Multicast VPNs, having the acronym
> "S-PMSI Join" messages *not* exploded in the abstract is a bit
> confusing.
I did think about this, but I thought that using the term "Selective Provider
Multicast Service Interface Join message" in the abstract would not be any
less confusing to someone who is not familiar with the MVPN work, and it
would be more confusing to someone who is familiar with the MVPN work.
> 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",
That's a technical term defined in draft-ietf-l3vpn-2547bis-mcast. I'll bet
you didn't look in that draft to see what this really means!
This is one of those cases where anyone who actually has to use the document
will know what an "S-PMSI Join" message is, even if they don't know what the
acronym expands to. I realize that the RFC Editor will probably expand it
anyway ;-)
> - Intro, 3rd para, 1st sentence
> s/specifications/capability (or capabilities)
I think s/specifications/specification would be better. MVPN implementers
are likely to also be BGP and/or LDP implementers, and in those protocols
the term "capability" is used to refer to something that requires explcit
advertisement.
You had a number of valid complaints about the writing of the first two
paragraphs of the introduction. What do you think of the following proposed
rewrite:
The Multicast Virtual Private Networks (MVPN) specification [MVPN]
defines the notion of a "PMSI" (Provider Multicast Service
Interface), and specifies how a PMSI can be instantiated by various
kinds of tunnels through a service provider's network ("P-tunnels").
It also specifies the procedures for using PIM ("Protocol Independent
Multicast", [RFC4601]) as the control protocol between Provider Edge
(PE) routers. When PIM is used as the control protocol, PIM messages
are sent through a P-tunnel from one PE in an MVPN to others in the
same MVPN. These PIM messages carry customer multicast routing
information. However, [MVPN] does not cover the case where the
customer is using IPv6, but the service provider is using P-tunnels
created by PIM over an IPv4 infrastructure.
The MVPN specification also specifies "S-PMSI (Selective PMSI) Join"
messages, which are optionally used to bind particular customer
multicast flows to particular P-tunnels. However, the specification
does not cover the case where the customer flows are IPv6 flows.
It's true that both paragraphs end with the same "However, ...", but the
first paragraph is about sending customer PIM/IPv6 messages though a
P-tunnel in a v4 infrastructure, while the second paragraph is about using
the S-PMSI Join message to assign specific customer multicast flows to a
particular P-tunnel.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf