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

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 00:44:03 -0500

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 ([email-masked])
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)

---

From: Eric Rosen <[email-masked]>
Date: Wed, 27 Oct 2010 14:44:42 -0400

> 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.

> 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.

>  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 
> 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 ;-)

>  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.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Oct 2010 14:41:04 -0500

Eric

At 01:44 PM 10/27/2010, Eric Rosen wrote:
>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

I'm not sold, but won't make a big deal about it.

>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).

>wise implementation, but it would still work, and I don't see a reason to

I can see this reason for recommended against doing it (in the text)

YMMV

>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.

>you didn't look in that draft to see what this really means!

to me, that doesn't mean you don't explode it...

>the term "capability" is used to refer to something that requires explcit

ok, you know your area better

>    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

---

From: Eric Rosen <[email-masked]>
Date: Thu, 28 Oct 2010 15:06:44 -0400

James> perhaps this needs to be stated (that the Type 4 is created by this
James> doc for your purpose)?

I think the doc already makes this clear, maybe I'm not sure what you are
asking.

James> You can probably imagine how many SIP and RSVP protocol extensions
James> there are (70+ and about 20 respectively off the top of my head), and
James> yet every one of them have to state "Session Initiation Protocol
James> (SIP)" and "ReSource ReserVation Protocol (version-1) (RSVPv1)" the
James> first time they appear, no matter how big the community of interest
James> is.

And this makes sense to you?

Okay, I will expand the occurrence of "S-PMSI" in the abstract.  

On the issue of the maximum UDP packet size, I think that is an
implementation issue and I don't think it is appropriate to raise it in this
document.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 28 Oct 2010 20:22:29 +0100

Hi,

There is a list of acronyms at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

Those marked with a star do not need to be expanded in any new I-D or RFC.

Those not marked need to be expanded on first use in the Abstract and in the
main body of the text (the Abstract is supposed to be free-standing).

Over time, the RFC Editor adds stars. I suspect they are susceptible to
lobbying.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rosen
> Sent: 28 October 2010 20:07
> To: James M. Polk
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
> 
> 
> James> perhaps this needs to be stated (that the Type 4 is created by
> James> this doc for your purpose)?
> 
asking.
> 
> James> You can probably imagine how many SIP and RSVP protocol
> James> extensions there are (70+ and about 20 respectively off the top
> James> of my head), and yet every one of them have to state "Session
> James> Initiation Protocol (SIP)" and "ReSource ReserVation Protocol
> James> (version-1) (RSVPv1)" the first time they appear, no matter how
> James> big the community of interest is.
> 
> On the issue of the maximum UDP packet size, I think that is an implementation
> issue and I don't think it is appropriate to raise it in this document.
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Mr. James W. Laferriere" <[email-masked]>
Date: Thu, 28 Oct 2010 11:35:50 -0800 (AKDT)

Hello All ,

> Over time, the RFC Editor adds stars. I suspect they are susceptible to

 	May I suggest that if any doucument at any stage of publication has 
Acronyms/Abbreviations that are susceptible to non-expansion at the time of that 
publication MUST have this url in the document .
 	Sure might aleave the need for my & others requests for 'What's this ... 
mean?' questions on this and many other lists .

 		Hth ,  JimL

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| [email-masked] | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Oct 2010 14:38:14 -0500

>I think the doc already makes this clear, maybe I'm not sure what you are

you may be right (that I'm not being clear). This is all about the 
wording in Section 3. You doc creates and IANA registers this Type 4 
message (in the second paragraph), but you state in the doc that

    '...(this) may be used to assign a v6 customer to a P-tunnel in a 
PIMv4 SP.'

To me, and this has been beaten into me over the 340+ IDs I've 
written, that anytime one uses lowercase "may", it actually needs to 
be replaced with "can". If I do that in my head, this usage of a Type 
4 is wishy-washy, in other words, something else is obviously 
available to do the same thing, otherwise the "can" meaning would 
have been stronger - like a "SHOULD be used to" or "MUST be used to" 
or even "will be used to", or the easiest "is used to".

And yes, I see that in the first paragraph you state that in some other doc a

    '...Type 1 may be used to to assign a v4 customer to a P-tunnel 
in a PIMv4 SP.'

so the wording is consistent, but I still don't like the lowercase 
use of a 2119 word, especially "may", because that means there are 
alternatives known, but here, they are not stated.

>And this makes sense to you?

no, but it is the way it has been and continues to be, at least in 
the areas I'm authoring in.  So you can take this one with the grain 
of salt, because those of mine that have slipped through to the 
RFC-Editor have always been caught there, but now that I've pointed this out...

>implementation issue and I don't think it is appropriate to raise it in this

It would normally be ok, but your doc says effectively "go ahead and 
stick as many Joins as you want and something/where else will deal 
with the consequences"... and that doesn't make a good spec to me.  I 
recommend that at least a warning of link MTU causing fragmentation 
be mentioned as a potential inefficient side effect.

James

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 28 Oct 2010 17:37:09 -0500

BTW Eric, my views here are just comments and shouldn't be taken as 
if these are showstoppers for your doc's progression.

James

At 02:38 PM 10/28/2010, James M. Polk wrote:
>    '...(this) may be used to assign a v6 customer to a P-tunnel in 
> a PIMv4 SP.'
>
>be replaced with "can". If I do that in my head, this usage of a 
>Type 4 is wishy-washy, in other words, something else is obviously 
>with the consequences"... and that doesn't make a good spec to 
>me.  I recommend that at least a warning of link MTU causing 
>fragmentation be mentioned as a potential inefficient side effect.
>
>James
>