Re: Working Group Last Call: draft-ietf-ccamp-gr-description-02

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi,

Well written draft. Thanks.

Here are some comments. Most of them are small editorial issues.

Regards,
Adrian

===
idnits
tmp/draft-ietf-ccamp-gr-description-02.txt(191): Line is too long: the 
offending characters are ','

===
1. Introduction

  Recovery Label object

Please be consistent with the names for all objects within this I-D.
Mainly you use upper case, for example, RECOVERY_LABEL object

s/provides and informational/provides an informational/

===
2.1. Procedures defined in [RFC3473]

Please capitalise section heading.

s/2) Recovers its RSVP state/2) Recover its RSVP state/

s/state in data plane/state in the data plane/

s/is not existed/does not exist/

s/state in data plane is existed/state in the data plane exists/

You have:

  For the Restarting Node:
[SNIP]
  4)
[SNIP]
  In addition, if the node is not
  the tail-end of the LSP, the corresponding outgoing Path messages is
  sent with the incoming label from that entry carried in the
  UPSTREAM_LABEL object.
"incoming label from that entry" is correct, but may be confusing.
How about...
  In addition, if the node is not the tail-end of the LSP, the incoming
  label on the downstream interface is retrieved from the forwarding
  state on the restarting node and set in the UPSTREAM_LABEL object in
  the Path message sent to the downstream neighbor.

s/1) Sends the Path message/1) Sends a Path message/

===
2.2. Procedures defined in [RFC5063]

s/in [RFC5063] which is called the/in [RFC5063] called the /

s/From the received Path message the following state can be recovered:/
The following state can be recovered from the received Path message:/

s/From the received RecoveryPath message the following state can be 
recovered:/
The following state can be recovered from the received RecoveryPath 
message:/

s/either by regular Path message or RecoveryPath message, and Resv message./
either from the regular Path and Resv messages, or from the RecoveryPath 
message./

===
3. Multiple Node Restart Scenarios

s/Note that if multi nodes/Note that if multiple nodes/

===
5.2.2. Procedures for Scenario 2

s/node(Node A)/node (Node A)/

===
5.2.3. Procedures for scenario 3

Please capitalise section heading.

s/on the nodes that are waiting/on the node that is waiting/

===
5.2.4. Procedures for scenario 4

Please capitalise section heading.

You have:
  In the event that Node B never restarts, management plane
  intervention may be used at Node A to clean up any LSP state
  restored from the management plane or from local configuration.
More importantly, management plane action is needed to clean up the
data plane.

===
5.2.5. Procedures for scenario 5

Please capitalise section heading.

You have:
  In this scenario the Egress node (Node D) restarts, and its
  upstream neighbor (Node C) has not restarted. In this case, the
  Egress node is completely unaware of the LSPs. It has no downstream
  neighbor to help it, and no management plane or configuration
  information. The Egress node must simply wait until its upstream
  neighbor restarts and gives it the information as Path messages
  carrying RECOVERY_LABEL objects.
It is not quite the case that the egress is "completely unaware" of
the LSP as the data plane will be set up and carrying data (as
described in the next section).

===
6. Clarification of Restarting Node Procedure

In the figure, you have
    X(CON deletion)  X (CON deletion)
I suggest you replace this with
    X(LSP deletion)  X (LSP deletion)

Please add a caption for the figure. Such as,

        Figure 2 Message flow for accidental LSP deletion

c/hello/Hello/  (several times)

  To resolve the aforementioned problem, the following procedures are
  proposed and are meant to work together with the recovery
  procedures documented in [RFC3473]. Here, it is assumed that the
  restarting node and the neighboring node(s) support Hello extension
  as documented in [RFC3209] and recovery procedures documented in
  [RFC3473].
This paragraph implies that there *are* new procedures defined in this
document contrary to the promise in the Abstract and Introduction.
I suggest you change the text as follows...
  To resolve the aforementioned problem, the following procedures which
  are implicit in [RFC3473] and [RFC5063] should be followed. These
  procedures work together with the recovery procedures documented in
  [RFC3473]. Here, it is assumed that the restarting node and the
  neighboring node(s) support Hello extension as documented in
  [RFC3209] and recovery procedures documented in [RFC3473].

===
7. Security Considerations

We had some debate with the Security ADs when RFC 5063 was processed. We
need to fill out the text in this section a little to reflect those
comments.

I suggest replacing the existing text with the following...

  This document clarifies the procedures defined in [RFC3473] and
  [RFC5063] to be performed on RSVP agents that neighbor one or more
  restarting RSVP agents. It does not introduce any new procedures and,
  therefore, does not introduce any new security risks or issues.

  In the case of the control plane in general, and the RSVP agent in
  particular, where one or more nodes carrying one or more LSPs are
  restarted due to external attacks, the procedures defined in
  [RFC5063] and described in this document provide the ability for
  the restarting RSVP agents to recover the RSVP state in each
  restarting node corresponding to the LSPs, with the least possible
  perturbation to the rest of the network. These procedures can be
  considered to provide mechanisms by which the GMPLS network can
  recover from physical attacks or from attacks on remotely controlled
  power supplies.

  The procedures described are such that, only the neighboring RSVP
  agents should notice the restart of a node, and hence only they need
  to perform additional processing. This allows for a network with
  active LSPs to recover LSP state gracefully from an external attack,
  without perturbing the data/forwarding plane state, and without
  propagating the error condition in the control or data plane. In
  other words, the effect of the restart (which might be the result of
  an attack) does not spread into the network.

  Note that concern has been expressed about the vulnerability of a
  restarting node to false messages received from its neighbors. For
  example, a restarting node might receive a false Path message with a
  Recovery Label object from an upstream neighbor, or a false
  RecoveryPath message from its downstream neighbor. This situation
  might arise in one of four cases:

  - The message is spoofed and does not come from the neighbor at all.
  - The message has been modified as it was travelling from the
    neighbor.
  - The neighbor is defective and has generated a message in error.
  - The neighbor has been subverted and has a "rogue" RSVP agent.

  The first two cases may be handled using standard RSVP authentication
  and integrity procedures [RFC3209], [RFC3473]. If the operator is
  particularly worried, the control plane may be operated using IPsec
  [RFC4301], [RFC4302], [RFC4835], [RFC4306], and [RFC2411]

  Protection against defective or rogue RSVP implementations is
  generally hard to impossible. Neighbor-to-neighbor authentication
  and integrity validation is, by definition, ineffective in these
  situations. For example, if a neighbor node sends a Resv during
  normal LSP setup, and if that message carries a GENERALIZED_LABEL
  object carrying an incorrect label value, then the receiving LSR will
  use the supplied value and the LSP will be set up incorrectly.
  Alternatively, if a Path message is modified by an upstream LSR to
  change the destination and explicit route, there is no way for the
  downstream LSR to detect this, and the LSP may be set up to the wrong
  destination. Furthermore, the upstream LSR could disguise this fact by
  modifying the recorded route reported in the Resv message. Thus, these
  issues are in no way specific to the restart case, do not cause any
  greater or different problems from the normal case, and do not warrant
  specific security measure applicable to restart scenarios.

  Note that the RSVP POLICY object [RFC2205] provides a scope by which
  secure end-to-end checks could be applied. However, very little
  definition of the use of this object has been made to date.

  See [MPLS-SEC] for a wider discussion of security in MPLS and GMPLS
  networks.


===
10.2. Informative References

Replace with...

  [MPLS-SEC] Fang, L., " Security Framework for MPLS and GMPLS
  Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework, work
  in progress.

  [RFC2411] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document
  Roadmap," November 1998.

  [RFC4301] S. Kent, K. Seo, "Security Architecture for the Internet
  Protocol," December 2005.

  [RFC4302] S. Kent, "IP Authentication Header," December 2005.

  [RFC4306] C. Kaufman, "Internet Key Exchange (IKEv2)
  Protocol", December 2005.

  [RFC4835] V. Manral, "Cryptographic Algorithm Implementation
  Requirements for Encapsulating Security Payload (ESP) and
  Authentication Header (AH)", April 2007.