Subject: [pim] AD Review of draft-ietf-pim-port

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 4 Aug 2011 17:02:52 +0100

Hi,

Don't panic!

I have performed my AD review of your draft. The purpose of the
review is to catch any nits or issues before the document goes
forward to IETF last call and IESG review. By getting these issues
out at this stage we can hope for a higher quality review and a
smoother passage through the process.

I don't have any major technical issues with your draft. The intention
and solution are fine. However, I found a largish number of small
issues and questions. These are mainly concerns with clarity, although
I did have some more substantial concerns about the use of experimental
code points.

All of my comments are up for discussion, and you should not feel
rail-roaded into making changes. But I do think my comments need to be
addressed before it goes to IESG review, and I would like you to have a
look and see whether you can work to improve the text before I take it
forward. 

I have moved the draft into "AD-review:Revised-ID-needed" state in
the datatracker, and I look forward to seeing the new revision which
I can put forward for IETF last call.

Thanks,
Adrian

---

You should change "draft" to "document" in the Abstract.

---

While I understand your motivation, the argument presented in the 
Abstract is suspect. You suggest that replacing one retransmission
protocol with another will reduce CPU and bandwidth load.

I think that the purposes you describe in the Introduction have a bit
more focus, and would make for a better Abstract. Perhaps you could 
write...

   This document creates a simple incremental mechanism to provide 
   reliable PIM message delivery in PIM version 2 for use with PIM
   Sparse-Mode (including Source-Specific Multicast) and Bidirectional
   PIM.

   The reliable transport mechanism will be used for Join-Prune message
   transmission only, and can use either TCP or SCTP as the transport
   protocol.

---

In Section 1 you say:

   This specification enables greater scalability in terms of control
   traffic overhead.  However, for routers connected to multi-access
   links that comes at the price of increased control plane state
   overhead and the control plane overhead required to maintain this
   state.

Notwithstanding the price may be worth paying, isn't there overhead
of TCP state even on p2p links?

---

I appreciate you positioning this work as Experimental. This is 
consistent with the way that PIM has developed over the years, and fits
with the type of extension you are defining.

It would be really good if you could add a paragraph to the end of
Section 1 that explains the experiment with some scope indicating at 
what point you might bring the work back to move it on to the Standards
Track. You don't need make a big song and dance. I think that you can
mention that the protocol extension operates between peers so,
experimentation does not need to be constrained to walled gardens.

---

Section 1.2

   Datagram Mode:   The current procedures PIM uses by encapsulating
      Join/Prune messages in IP packets sent either triggered or
      periodically.

I think you don't want to say "current" since, once your I-D is
approved, you hope that this will no longer be the case. How about:

   Datagram Mode:   The procedures whereby PIM encapsulates Join/Prune
      messages in IP packets sent either triggered or periodically.

---

Section 2

   This document does not update the PIM Join/Prune packet format.
   However, for Join/Prune messages sent over TCP/SCTP connections, only
   what would be the IP payload of a native PIM Join/Prune is included,
   there is no IP Header.

Well, of course, there is an IP header if TCP is delivered over IP. And
I don't think anyone would think you intended to carry PIM over IP over 
TCP over IP. But why are we worried about this? 4601 doesn't spend much
time on the IP header (see Section 4.9 of RFC 4601). 
                                                   
Perhaps you could replace the sentence to give...

   This document does not update the PIM Join/Prune packet format.
   In the procedures described in this document, each Join/Prune message
   is sent as the payload of a PORT message carried over TCP/SCTP.

On which subject, maybe I am slow, but it took me a long time to realise
that the PIM messages are not the direct payload of TCP/SCTP and that a
wrapping message (the PORT message) is used. Could you make this 
clearer? Perhaps my suggested change is enough.

---

Sections 3.1 and 3.2

   Length:   Length in bytes for the value part of the Type/Length/Value
      encoding; where X is the number of bytes that make up the
      Connection ID field.  X is 4 when AFI of value 1 (IPv4) is used,
      16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is
      used [AFI].

You should not give [AIF] as a reference for AFI 0 because according to 
IANA the zero value is Reserved. Thus, the 0 you are specifying is 
scoped to just these fields. You should write...
                                                          
   Length:   Length in bytes for the value part of the Type/Length/Value
      encoding; where X is the number of bytes that make up the
      Connection ID field.  X is 4 when AFI of value 1 (IPv4) [AFI] is
      used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 if AFI of 
      value 0 is used.

---

Sections 3.1 and 3.2

I am hugely suspicious of your determination of three reserved bits as
Experimental. Less scrupulous people than yourselves use this sort of 
mechanism to end-run the standards process and achieve proprietary
extensions. That is, they don't use them for experimentation at all :-(

At this stage, you probably need to give a hint of the type of 
experiment that might be run with these bits. Otherwise it would be
better to leave all of the bits unreserved.

If you do keep the bits as experimental, you must give some clues to 
non-participating routers about what they do if they see any of the bits
set. Do they ignore the bits; do they ignore the message; do they reject
the message with an error; or do they tear down the TCP connection?

---

Section 4

   When a Transport connection is established (or reestablished), the
   two routers MUST both send a full set of Join/Prune messages for
   state for which the other router is the upstream neighbor.

I understand why.
What is the risk that the amount of information that has to be sent is 
very considerably large? Is there a need for graceful restart?

---

Section 4.2

Can you have another look at the text in this section. It looks to me 
that it contains two attempts to write the same material. Perhaps some
paragraphs can be deleted?

Could you also include a forward pointer to Section 5.2.

---

Section 4.2

JP_HOLDTIME and JP_HoldTime are actually called J/P_Holdtime in RFC 4601

---

Section 5

Title should read 

5.  PORT Message Definitions

---

Section 5 (also Sections 5.3 and 10.4)

   The TLV type field is 16 bits.  The range 61440 - 65535 is for
   experimental use [RFC3692].
                                                                         
Curious that you give the reference to 3692 but don't follow the advice
it contains :-)  It says...                                     

   In many, if not most cases, reserving a single value for experimental
   use will suffice.  While it may be tempting to reserve more in order
   to make it easy to test many things at once, reserving many may also
   increase the temptation for someone using a particular value to
   assume that a specific experimental value can be used for a given
   purpose exclusively.

Can you explain why you need 4096 experimental values rather than, say,
four? 

The same issue arises for the message type in Section 10.3.

---

Sections 5.1 and 5.2

I have the same misgivings about the EXP fields in these two messages.
Possibly, however, you intend processing rules to be covered by the text
in Section 5 that states...

   PORT messages are error checked.  This includes a bad PIM checksum,
   illegal type fields, illegal addresses or a truncated message.  If
   any parsing errors occur in a PORT message, it is skipped, and we
   proceed to any following PORT messages.

Anyway, clarification of how to handle unexpected EXP bits would help.

Meanwhile, the text here implies that the checksum applies to the PORT
message. It does not. It may be better to list the error checking on
the PORT message, and then state that each payload PIM message is also
subject to the normal error checks.

---

Sections 5.1 and 5.2

I understand that the PORT messages are just simple wrappers, but I am
surprised that you have designed a message format that is different from
that used by regular PIM. Also that you have created a new registry for 
PORT messages rather than picking two values from the PIM message
registry. Lastly, that you have not included "protocol version"

Of course, this works, and maybe the working group is also OK with this.

It just seemed an odd choice. 

---

Section 5.1

Is there a reason why a PORT message can only contain one PIM message?

---

Section 5.1

The description of how to handle unrecognised PORT options is clear. It
allows you to survive in the presence of experiments. It does not give
you very graceful future-proofing in that you cannot have one router 
send an option it would like parsed by its peer, but does not care
about, since the whole message will be skipped. OTOH, it does not allow
a receiver to indicate that it has skipped the received message (and 
why).

If this is a conscious choice, so be it.

---

Section 5.2

Wouldn't it be nice to align the YLVs in the same way in both messages?

---

Section 5.2

I think you should give some advice for the sender about the Holdtime.
1. Should it be configurable?
2. Is there a default?
3. How often should a KeepAlive be sent relative to the Holdtime if 
   there are no other messages sent?

---

Section 5.3

Maybe "PIM IPv4 Join/Prune Option" and "PIM IPv6 Join/Prune Option" 
would look better as sub-sections.

---

Section 6

The mention of "LAN Prune Delay option" could use a reference to   
[RFC4601]

---

Section 8

Idle curiosity...
Why don't you allow other PIM messages to delivered reliably over TCP
or SCTP?

---

Section 10.1

You should request IANA to insert a reference to this document in the
port numbers registry.

---

Section 13.2

   [AFI]      IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
              NUMBERS http://www.iana.org/numbers.html, February 2007.

This should read

   [AFI]      IANA, "Address Family Numbers", ADDRESS FAMILY NUMBERS
              http://www.iana.org/assignments/address-family-numbers,
              February 2007.

---                                               

Manageability

I think you have done a good job in calling out the items that should
be configurable. The Ops ADs are increasingly asking us to pull 
together a single, small section entitled "Manageability". They are 
pushing back on this for new protocols and for significant protocol
extensions.

In your case this would just be a list of items and references to the
appropriate sections. You would also need to add a list of objects that
might be reasonably made available by an implementation for inspection
by an operator.

Could you add such a section?

---

From: Stig Venaas <[email-masked]>
Date: Tue, 09 Aug 2011 15:40:27 -0700

> Don't panic!

OK, I'm trying not to panic :) See my comments below.

> You should change "draft" to "document" in the Abstract.

Right

> protocol with another will reduce CPU and bandwidth load.

Yes! The major reason for this is to not require periodic signaling
just to maintain state. That can require a lot of CPU. There are
other advantages too though.

>     transmission only, and can use either TCP or SCTP as the transport

This doesn't really say why we want a reliable transport though. Do
you think it is better to not explain that in the abstract, and talk
about the CPU savings in the introduction instead?

> of TCP state even on p2p links?

Yes, the overhead is bigger for multi-access though. There are two
types of state.

TCP state: This would be on a per neighbor basis. So the amount of
   state is based on how many neighbors there are.

PIM state: When using PORT one needs to use explicit tracking.
   Normally with PIM for a given (S,G) you only need to remember
   that someone on the link has joined. But with PORT, for a
   multi-access link,  you need to remember exactly which neighbors.

Perhaps I could alter this to say that there is a PIM state overhead
for multi-access links?

> experimentation does not need to be constrained to walled gardens.

I think experimental is appropriate, because PIM has always been a
soft-state protocol, so this is something completely new and untested. 
So I can add this, and also the sentence you suggest
regarding no constraint regarding walled gardens.

Perhaps I can add that it should be considered as a proposed standard
once there are experiences from multiple deployments in the field?
I don't want to require interoperability, but half expect that with
some deployment experience we may figure out some necessary improvements.

>        messages in IP packets sent either triggered or periodically.

Right, thanks.

>     is sent as the payload of a PORT message carried over TCP/SCTP.

Yes, happy with that change :)

> clearer? Perhaps my suggested change is enough.

Yes.

>        used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 if AFI of

Agree.

> better to leave all of the bits unreserved.

I don't have any concreate ideas at this stage. But if PORT gets
enhanced in the future, it might be good for showing additional
capabilities, which PORT enhancements are supported. So if a
vendor comes up with a possible PORT extension, and wants to do
an experiment, one of these bits can show that it is supported.

The main purpose would be to allow testing out new features at a
small scale, for a limited time period, but not for more permanent
use. It's good to be able to experiment and know that it doesn't
conflict with possible future IANA assignments. Pretty much as
described in the referenced RFC 3692. I'm fully aware that it can be
abused though. But so can reserved bits be.

I don't have a strong feeling regarding keeping them or not. I guess
we could check with the WG (anyone of you reading this? :)

> the message with an error; or do they tear down the TCP connection?

I agree, that would be needed. I'm a bit unsure how they should be
treated, as it depends a bit on what the potential use might be.

> very considerably large? Is there a need for graceful restart?

This is the current PIM behavior, PORT doesn't change this. For both
regular PIM and PIM with PORT, one could consider graceful restart
extensions. I have ideas regarding that, but at this point I'm not
sure if it should be PORT specific, and if we do, I think it is
better to leave it as a future extension.

> Could you also include a forward pointer to Section 5.2.

You're right, I think this can be improved. I'll work on that.

> JP_HOLDTIME and JP_HoldTime are actually called J/P_Holdtime in RFC 4601

Will change.

> 5.  PORT Message Definitions

Yes

> Can you explain why you need 4096 experimental values rather than, say,

I can make it 4. I felt there was plenty of space, but I agree it
will make it easier to abuse it. So I'm happy to use 4.

> Anyway, clarification of how to handle unexpected EXP bits would help.

Agree.

> subject to the normal error checks.

Agree.

> registry. Lastly, that you have not included "protocol version"

One issue with using types from the existing PIM registry is that we
have very few unallocated types. Also, if a PORT message type would
only be used for PORT, I don't see why it makes sense to use the same
registry. I would say that PORT may have several different messages,
some of them may include a PIM message in the payload. It would be
just confusing to say that they are all PORT messages.

> Is there a reason why a PORT message can only contain one PIM message?

Ease of parsing. You might as well send a second PORT message. Note
that if you have two PIM J/P messages, you might also try to merge
them. Also if you have multiple PIM messages, what do you do if say
one has wrong checksum and not the other. Also, an implementation
would probably read an entire PORT message from TCP before processing. 
If you have multiple PIM messages, you will wait unless
you've read all the data before you process the first message. I
guess this could be made to work though.

> If this is a conscious choice, so be it.

I think this is the best option. An alternative would be to have some
bits indicating how a peer should behave. Or have say two option
ranges, where you say that if you don't understand an option in one
range, then you just ignore that option but continue processing,
while if the option is in another range, then the entire message
should be ignored.

I'm interested in your and the WG thoughts on this.

> Wouldn't it be nice to align the YLVs in the same way in both messages?

Don't think worth doing that.
>     there are no other messages sent?

I prefer leaving this open. An implementation can choose this freely,
and still have interoperability. Since we have reliability, a
keepalive need only be sent once within each holdtime. The main thing
is to send it well before the holdtime. I can add 1-2 sentences with
some considerations, but don't want to specify defaults. This can be
considered if we want to make it a standard, and we know better what
makes sense in different deployments.

There are a lot of different opinions on what the best defaults are.
> would look better as sub-sections.

Agree.

> The mention of "LAN Prune Delay option" could use a reference to

Agree.

> Why don't you allow other PIM messages to delivered reliably over TCP

That is a long story. The main issue are messages that are periodic.
While Hello messages need to be outside PORT, for capabilities, for
PORT connection parameters etc. E.g. Asserts would be difficult as
they need to be seen by all the routers.

I don't have any plans, but at least PORT could be extended to
allow other PIM message types in the future, if we see any
benefits.

> You should request IANA to insert a reference to this document in the

Yes.

>                http://www.iana.org/assignments/address-family-numbers,

Oh right.

> Could you add such a section?

OK.

I will need some time on this, and propose some improvements. There
are a few things above we probably need to discuss a bit further
though.

Thanks for the detailed review. It has been through several
thorough reviews by people in the WG, but you found some issues
I think should be taken care of. And a few I'm not so sure about
as well...

Stig

> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 10 Aug 2011 19:21:03 +0100

Hi Stig.

In line. Snipped the agreements.

> about the CPU savings in the introduction instead?

Hmmm, well, no. I think the Abstract and Introduction should state the full
picture.

I am saying that moving the reliability mechanism from one protocol to another
does not reduce the protocol overhead, it just moves it.

But something you say lower down makes sense. This is not about making anything
reliable per se, this is about moving from a soft-state model to a hard-state
model. In hard state you have:
- confirmed delivery (aka reliable delivery)
- explicit state teardown (which also has to be confirmed)
- neighbor failure detection

So we could argue that the objective of the draft is to remove state refresh. Is
that the case?

Or am I missing something?

> Perhaps I could alter this to say that there is a PIM state overhead

Yes. s/control plane/PIM/

> some deployment experience we may figure out some necessary improvements.

That sounds about right.

> treated, as it depends a bit on what the potential use might be.

Well, let's try keeping them. I half expect the IESG will push back, but who
knows.

How about saying that a receiver that sees one of these bits set must drop the
message and may log an error?
That also requires that these bits should be set to zero by non-participating
routers.

> better to leave it as a future extension.

Hmmm. Well, it is different. Currently when a PIM router restarts it has to
resynch as you describe. And that applies with or without PORT.

But the draft describes what to do when a Transport connection is
re-established. This could happen with the two routers both still up and running
(perhaps there was a blip on the link that took down the TCP connection, but
would have been handled seamlessly by the soft state part of the protocol). So
GR becomes more important in the presence of reliable transport.

Maybe you can simply flag the issue. People can look at this in a separate I-D
and as part of the Experiment.

> just confusing to say that they are all PORT messages.

OK

> guess this could be made to work though.

OK. No problem. I was just curious.

> I'm interested in your and the WG thoughts on this.

I think you have captured the three possible behaviors:
i) discard the message with the unknown option
ii) ignore the unknown option and process the message
iii) reject the message with the unknown option

Within ii) there is:
a) retain the option in messages forwarded/triggered
b) purge the option in messages forwarded/triggered

Many protocols do as you say: blend these behaviors depending on additional
fields or sub-ranges (see LDP and RSVP for example).

I have no strong views, but I would like you to have made the decision rather
than allowed it to creep up. It is a hard decision to change once boxes are
deployed.

> > Section 5.2
> >
> > Wouldn't it be nice to align the TLVs in the same way in both messages?
> 

OK. I must be anal ;-)

> There are a lot of different opinions on what the best defaults are.

Ah, good point. This is not a standard!
In fact, just noting that this is an issue for experimentation should do the
job.

> I think should be taken care of. And a few I'm not so sure about

Oh well, sorry to add to the development time. I guess the market is not
champing at the bit for an RFC :-)

Let me know when you have a revision and we will take it to the next step.

Cheers,
Adrian

---

From: Stig Venaas <[email-masked]>
Date: Mon, 29 Aug 2011 11:41:00 -0700

I have now submitted version 08 that I hope addresses all the
issues.

There are some protocol changes that I want you all to be aware of.
Please have a look and let us know if you have any concerns.

The new draft is at
http://www.ietf.org/internet-drafts/draft-ietf-pim-port-08.txt

A diff is available at
http://tools.ietf.org/rfcdiff?url2=draft-ietf-pim-port-08.txt

See the diff for all changes. The main changes as I see them
are below.

Removed experimental bits from the defined PORT messages. If
something is needed for an experiment, one can use an experimental
option instead of a bit. A bit can be requested if the experiment
results in the need for something more permanent.

The number of PORT messages for experimental use has been reduced
to 4.

Split the PORT option space into two, as follows:
    Each PORT Option is a TLV.  The type is 16 bits.  The PORT Option
    type space is split in two ranges.  The types in the range 0 - 32767
    (the most significant bit is not set) are for Critical Options.  The
    types in the range 32768 - 65535 (the most significant bit is set)
    are for Non-Critical Options.

    The behavior of a router receiving a message with an unknown PORT
    Option, is determined by whether the option is a critical option.  If
    the message contains an unknown critical option, the entire message
    must be ignored.  If the option is non-critical, only that particular
    option is ignored, and the message is processed as if the option was
    not present.

This should allow us enough flexibility to be future proof. The options
we have defined so far are Critical Options.

I also reduced significantly the number of options for experimental use.
I have now defined this:

    PORT Option types are assigned by IANA, except the ranges 32764 -
    32767 and 65532 - 65535 that are for experimental use [RFC3692].

The IANA considerations were updated accordingly.

A section on manageability added as requested.

Comments welcome.

Stig