Eric
At 01:44 PM 10/27/2010, Eric Rosen wrote:
> 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.
perhaps this needs to be stated (that the Type 4 is created by this
doc for your 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.
I'm not sold, but won't make a big deal about it.
> - 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.
fair - which was one of my goals with asking this, but a warning
about the perils of having an unreliable packet type exceed the MTU
of a link my be warranted, at least in the Security considerations
section (if not elsewhere).
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.
I can see this reason for recommended against doing it (in the text)
YMMV
> - 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.
You can probably imagine how many SIP and RSVP protocol extensions
there are (70+ and about 20 respectively off the top of my head), and
yet every one of them have to state "Session Initiation Protocol
(SIP)" and "ReSource ReserVation Protocol (version-1) (RSVPv1)" the
first time they appear, no matter how big the community of interest is.
> 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!
to me, that doesn't mean you don't explode it...
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.
ok, you know your area better
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.
yes, this makes it much clearer what you are doing/going after. Thanks
It's true that both paragraphs end with the same "However, ...",
I'm fine with that part
James
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf