Re: [secdir] secdir review of draft-ietf-pwe3-redundancy-06

["Bocci, Matthew (Matthew)" <[e-mail]>]

Radia,

Many thanks for your review. Please see below for some comments and
proposed amendments to the draft.

Best regards,

Matthew

On 19/03/2012 22:22, "Radia Perlman" <[e-mail]> wrote:

>I have reviewed this document as part of the security directorate's
>ongoing effort to review all IETF documents being processed by the
>IESG.  These comments were written primarily for the benefit of the
>security area directors.  Document editors and WG chairs should treat
>these comments just like any other last call comments.
>
>This is a requirements document (intended as informational) for a
>routing protocol.
>
>
>
>At this level of abstraction, I don¹t think there are any interesting
>security issues. There are some messages in the protocol that need to
>be communicated securely, and the security considerations section
>references some other RFCs and says the new messages will ³inherit at
>least the same security properties² as the messages in those other
>RFCs. I didn¹t look up what kind of protection existed there.
>
>
>
>The interesting routing protocol issue has to do with nesting of
>routing algorithms and the needed multipliers in timeouts. It would
>appear that pseudo-wires run over a conventional routed infrastructure
>and also connect parts of a conventional routed infrastructure. The
>spec assumes that failures within the inner routed infrastructure will
>heal themselves quickly enough to not be noticed by the pwe3 redundancy
>protocol (if they are capable of healing at all), and that pseudo-wire
>failover (triggered by this inner failure) will happen quickly enough
>to not disrupt the routing protocol that is running over the
>pseudo-wires.
>
>
>
>But that requirement is not explicitly acknowledged in the document,
>and it intuitively seems like a significant challenge.

MB> Multi-layer resiliency mechanisms, where protection is provided at
multiple nested levels are fairly common in provider networks, but there
is indeed an assumption that lower layer protection mechanisms react and
restore more rapidly than those in the next higher layer. I agree that
this implicit assumption is worth acknowledging in the draft, and propose
modifying the 2nd paragraph in the introduction as follows:

"In single-segment PW (SS-PW) applications, protection for the PW is
   provided by the PSN layer.  This may be a Resource Reservation
   Protocol with Traffic Engineering (RSVP-TE) labeled switched path
   (LSP) with a fast-Reroute (FRR) backup or an end-to-end backup LSP. It
is assumed that these mechanisms can restore PSN connectivity rapidly
enough to avoid triggering protection by PW redundancy."

Regarding your second point about an assumption that PW redundancy will
switch over quickly enough that any routing protocols running over the
emulated service provided by the PW don't notice, I am not sure that that
assumption is always correct. It is certainly possible to engineer PW
redundancy to achieve this, but there are mechanisms that it relies on
(e.g. Native service dual-homing protocols running on the ACs) that are
outside the scope of the work in PWE3 that we can't really set a
performance objective for in this document. Further, PWs provide a 'good
enough' emulation rather than a perfect emulation of a native service (as
detailed in the PWE3 charter). This means that the emulation may be good
enough for a particular application, but isn't guaranteed to be
indistinguishable from a network built entirely of the native service
technology.


>
>
>
>Micro-level issues:
>
>
>
>In terminology (section 2), the Primary PW is defined as the one that
>will be used when any one will do, and that if it goes down and comes
>back the PW will revert to it. But it also defines non-revertive
>protection switching as an option where the traffic will not switch
>back to the primary unless the secondary fails, and in section 4.1 it
>says that non-revertive protection MUST be supported and revertive is
>optional.

MB>
I propose modifying the definition of Primary as follows:
o  Primary PW: the PW which a PW endpoint activates (i.e. uses for
      forwarding) in preference to any other PW when more than one PW
      qualifies for active state.  When the primary PW comes back up
      after a failure and qualifies for the active state, the PW
      endpoint always reverts to it.  The designation of Primary is
      performed by local configuration for the PW at the PE and is only
required when revertive behaviour is used.


>
>
>
>Typos:
>
>
>
>Section 4.1:
>
>besupported -> be supported
>
>suported -> supported

MB> Thanks

>
>
>
>Section 4.2:
>
>Orphaned bullet

MB> Thanks