A Reliable Transport Mechanism for PIM
draft-ietf-pim-port-09

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan in 1-Nov-2011 raises two points
  that deserve a response.

  Section 3.1: From my reading of the document, it is not clear whether
  we can have a node advertise multiple capability options of the same
  transport protocol (say PIM-over-TCP-Capable) in the same message.
  e.g. A dual stack node might want to advertise its capability to do
  both IPv4 and IPv6. Is this possible? If so, how?

  Section 4.7: Section 4 talks about the router with the lower
  connection ID initiating the transport layer connection but this does
  not really map into the rules mentioned in Section 4.7. Specifically,
  I am not sure Rule 3 for Node A in Section 4.7 conveys the same intent
  as the rest of Section 4.

[Ballot comment]
s3.1 and s3.2: Not being a PIM expert, I tripped up over how IPv6 addresses could fit in to TCP Connection ID and SCTP Connection ID.  I kind of had to guess where I'd find more information about this, so a pointer to the xoring mechanism in RFC 4061 would have helped a lot.

[Ballot discuss]
The Gen-ART Review by Suresh Krishnan in 1-Nov-2011 raises two points
  that deserve a response.

  Section 3.1: From my reading of the document, it is not clear whether
  we can have a node advertise multiple capability options of the same
  transport protocol (say PIM-over-TCP-Capable) in the same message.
  e.g. A dual stack node might want to advertise its capability to do
  both IPv4 and IPv6. Is this possible? If so, how?

  Section 4.7: Section 4 talks about the router with the lower
  connection ID initiating the transport layer connection but this does
  not really map into the rules mentioned in Section 4.7. Specifically,
  I am not sure Rule 3 for Node A in Section 4.7 conveys the same intent
  as the rest of Section 4.

[Ballot comment]
- Presumably if this experiment is a success then some method of
doing automated key management would be required for a successor
standards track document. I think just noting that in the
security considerations section would be good.

- I wondered why TLS wasn't considered as an additional option.
Be good to explain why, esp if there's a reason it wouldn't work
well enough.

TSVDIR review by Gorry Fairhurst

Hi, all,

I've reviewed this document as a part of the transport area
directorate's ongoing effort to review key IETF documents. These
comments were written primarily for the transport area directors, but
are copied to the document's authors for their information and to allow
them to address any issues raised. The authors should consider this
review together with any other last-call comments they receive. Please
always CC tsv-dir@ietf.org if you reply to or forward this review.

The document describes a protocol that is designed to use a TCP or SCTP
transport. The use of TCP is application-limited and a negotiation
mechanism is provided that helps select whether TCP or SCTP should be used.

The note below includes transport issues, as well as additional comments
that I hope are also useful.

I hope this feedback will be useful to the authors, and will be glad to
provide further assistance either on- or off-list as useful.

Gorry

-----

Overall this document seems complete and uses standard IETF transport
mechanisms that support congestion control.

Introduction: Recommend to specify the IANA-assigned port.

Since this specifies a protocol that runs over a specific IANA-allocated
port it would be good if the port number was mentioned in the
Introduction. This may confirm that this is the correct document to read
to find out about what happens when port 8471 is used (e.g. someone
interpreting IPFIX or building a NAT, Firewall, etc).

Section 4 (and others, including section 7): AF for transport.

I understand there is a rule to prefer SCTP over TCP when both
transports are available. This seems OK.

Various sections refer to the support for multiple address families
(IPv4, IPv6) and I understand that the PORT information for an AF does
need not to be carried over a transport connection using the same AF.
What I do not yet understand is how PORT knows whether to use an IPv4
transport for IPv6 or to use an IPv6 transport for IPv6. I'd like this
to be clear, so that I can understand what happens when TCP is available
over Ipv4 and SCTP only over IPv6 and similar combinations.

Section 4.2: TCP keep-alive.

SCTP heartbeat is described.

I understand PORT also includes an optional keep-alive mechanism using
the transport service.

TCP also contains an optional keep-alive mechanism. This should be
mentioned. Is TCP keep-alive recommended for PORT or does the protocol
recommend a keep-alive at the PORT layer?


Section 4.2: TCP Reset

The present text says that the TCP connection will be reset "after a few
reties". This does not seem clear. A lack of acknowledgement for a sent
data segment will result in the underlying TCP tansport retransmitting
after the Retransmission Time Out (RTO). Furthermore this would cause
the RTO to be doubled with each retransmission, until the RTO exceeds
the maximum value when the connection will be reset, this is typically
many 10s of seconds later.


Section 5: Unexpected corruption of the stream

It is good to see the service using the transport, in this case PORT
verifies the integrity of the transported data. The recommendation seems
to be that PORT skips any unknown data. While this may be good for
interoperability between different flavours of the protocol, it is not
good in terms of robustness, which could be an issue for long-lived
connections.

I suggest that if such errors occur they should be made visible, so that
operators are aware that there are either PORT protocol issues or
transport issues. That way a high count of such errors would alert a
possible underlying problem.

Could a single error in the transport result in loss of farming? I
suspect so. I think it should be considered whether it be wise to close
the connection (and reopen a new transport connection) after a repeated
number of such errors.


Section 9: ?

The opening para concludes:
/This the case even when the connection is down./
- I can see this case needs to be mentioned, but I am not sure from this
text what exactly I am to understand.


Section 11.4

This section describes critical and non-critical options. I could not
find guidance for IANA on how to now whether a new option should be
classified as one or the other.

---

There are two general observations about this usage of TCP, I leave it
to the TSV ADs to decide if any of these topics should be discussed further:

1) As I understand the protocol, it is application-limited, in that it
will not usually  use the entire TCP congestion window, but rather sends
"occasional" small messages under the control of PORT. It seems
important that such use does not grow an unbounded cwnd and then emit
large bursts of data into the path when the application produces bursts
of data that exceed a few MSS. It may be wise to consider a TCP stack
that includes rate-limiting or burst-limiting. RFC 3645 (EXP) may also
help in this case.

2) Since PORT may generate one or two segments of data per interval, TCP
retransmission may be slow following loss, since there may not be
sufficient to trigger fats retransmission using DupAcks. Limited
transmit (RFC 3042, STD) may help in this case.

---

Editorial/General comments:

Section 6: Use of keywords

The opening para contains two statements that could need to be RFC 2119
keywords:
/This is done for all PORT joins and PRUNES/ is this a  MUST?
/It may be done for..? is this a MAY?

Page 6, section 2
/PORT capable/PORT-capable/

page 13, section 4.2
/until you actually try to send/until the PIM PORT module then tries to
send/


Section 10: ?

This section describes security threats. Please could the editors
identify whether these are on-path attacks or off-path attacks.

ANA understands that, upon approval of this document, there are four
IANA Actions that need to be completed.

First, in the Service Name and Transport Protocol Port Number Registry
located at:

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

IANA has registered the following port number for TCP and SCTP: 8471.
The reference for this registration will be changed to this document [
RFC-to-be ].
In addition, the registration of this port number will be made permanent.

Second, in the Protocol Independent Multicast (PIM) Hello Options
registry, located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

two new PIM Hello Options will be registered as follows:

Value Length Name Reference
------- ---------- ----------------------- ---------------
tbd1 Variable PIM-over-TCP Capable [ RFC-to-be ]
tbd2 Variable PIM-over-SCTP Capable [ RFC-to-be ]

IANA notes that the author suggest the values 37 and 28 for these new
Hello Options.

Third, a new registry will be created for "PORT Message Types" in the
PIM Parameters Registry located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

The message type is a 16-bit integer, with values from 0 to 65535.

An RFC is required for assignments in the range 0 - 65531.
The type range 65532 - 65535 is for experimental use.

The initial content of the registry should be as follows:

Type Name Reference
------------ ------------------------------- ---------------
0 Reserved [ RFC-to-be ]
1 Join/Prune [ RFC-to-be ]
2 Keep-alive [ RFC-to-be ]
3-65531 Unassigned
65532-65535 Experimental [ RFC-to-be ]

Fourth, a new registry for "PORT option types" will be created in the
PIM Parameters Registry located at:

http://www.iana.org/assignments/pim-parameters/pim-parameters.xml

The option type is a 16-bit integer, with values from 0 to 65535.

Option types in the ranges 32764 - 32767 and 65532 - 65535 are for
experimental use. All other option types are maintained through "RFC
required."

The initial content of the registry should be as follows:

Type Name Reference
------------- ---------------------------------- ---------------
0 Reserved [ RFC-to-be ]
1 PIM IPv4 Join/Prune Message [ RFC-to-be ]
2 PIM IPv6 Join/Prune Message [ RFC-to-be ]
3-32763 Unassigned Critical Options
32764-32767 Experimental [ RFC-to-be ]
32768-65531 Unassigned Non-Critical Options
65532-65535 Experimental [ RFC-to-be ]

IANA understands that these actions are the only ones required upon
approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A Reliable Transport Mechanism for PIM) to Experimental RFC


The IESG has received a request from the Protocol Independent Multicast
WG (pim) to consider the following document:
- 'A Reliable Transport Mechanism for PIM'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a reliable transport mechanism for the PIM
  protocol for transmission of Join/Prune messages.  This eliminates
  the need for periodic Join/Prune message transmission and processing.
  The reliable transport mechanism can use either TCP or SCTP as the
  transport protocol.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pim-port/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pim-port/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Evaluation

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?

PROTO Writeup for draft-ietf-pim-port-07
=================================================

http://www.ietf.org/id/draft-ietf-pim-port-07.txt

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Mike McBride is the document shepherd. I have personally reviewed the
document, and believe it is ready for publication as a Proposed
Standard.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

The document has undergone thorough review within IETF's Multicast
community.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

No

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

I have no concerns.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

There is consensus within the PIM WG to publish the document. The
participation has been with individuals from a variety of vendors and
providers. This document has undergone multiple wglc's due to a variety
of comments. All comments have been addressed.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

Yes. Normative references are all stable documents published as RFCs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

This specification makes use of a TCP port number and a SCTP port
number for the use of PIM-Over-Reliable-Transport that has been
allocated by IANA. It also makes use of IANA PIM Hello Options
allocations that should be made permanent.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

Not applicable.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup. Recent examples can be found in the
"Action" announcements for approved documents.

This draft describes how a reliable transport mechanism can be used
by the PIM protocol to optimize CPU and bandwidth resource
utilization by eliminating periodic Join/Prune message transmission.
This draft proposes a modular extension to PIM to use either the TCP
or SCTP transport protocol.