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

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Apr 2012 18:03:33 +0100

Authors

Please can you answer or address these comments

Thanks

Stewart

On 19/03/2012 22:22, Radia Perlman 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.
>
>
>
> 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.
>
>
>
> Typos:
>
>
>
> Section 4.1:
>
> besupported ->  be supported
>
> suported ->  supported
>
>
>
> Section 4.2:
>
> Orphaned bullet
>

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 16 Apr 2012 18:27:31 +0200

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" <[email-masked]> wrote:

>At this level of abstraction, I don¹t think there are any interesting
>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.
>
>
>
>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.
>
>
>

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.

>says that non-revertive protection MUST be supported and revertive is

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.

>besupported -> be supported

MB> Thanks

>Orphaned bullet

MB> Thanks

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 17 Apr 2012 09:16:56 +0200

Tina hi,
Thank you for your review.
Please see inline.
Best regards,
Nurit
 
-----Original Message-----
From: ext Tina TSOU [mailto:[email-masked]] 
Sent: Saturday, March 24, 2012 8:11 AM
To: [email-masked]; [email-masked]
Subject: secdir review of draft-ietf-mpls-tp-oam-analysis-08
 
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.
 
Some comments which may not be from security aspects only are below.
 
1) One missing OAM function
 
I compared the OAM functions listed in this draft and those required in
RFC5860 and find out one OAM function named Client Failure Indication
(Section 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for
this. Since this is an informational analysis document, it is
recommended to give a whole view. Specific clarifications are
appreciated in the document. 
 
<Nurit> this document provides an overview of the MPLS-TP OAM tools that
are specified in separate RFCs. It was agreed by the working group that
the final version of this document refers to RFCs only.
draft-ietf-mpls-tp-csf on "Indication of Client Failure in MPLS-TP" was
expired on September 2011, hence we cannot refer to this document. 
Please note also that although the name of the FILE may confuse, this
document does not make any analysis but rather presents an overview of
the OAM tools. The purpose of the document is carried in the document
TITLE and Abstract/Introduction. \<Nurit>

2) Lack of analysis about the compatibility with existing tools
 
It is said in this document that compatibility with the existing tools
has been maintained. But there is no detailed analysis which IMHO might
be of great interest to the industry and should form an important part
of this analysis document.
 
<Nurit> 
As mentioned above, the purpose of the document is to provide an
overview of the MPLS-TP OA tools. It is not a detailed analysis of the
tools. 
Still, I think your idea is excellent, and may be a subject for another
I-D. \<Nurit>
 
3) 1.1 Scope
 
In the middle of this section, under the "three objectives", the first
bullet reads  
 
   o  The OAM toolset should be developed based on existing MPLS
      architecture, technology, and toolsets.
 
However, in the following paragraph it is written as
 
   o  ITU-T OAM for Ethernet toolset as defined in [Y.1731].  This has
      been used for functionality guidelines for the performance
      measurement tools that were not previously supported in MPLS.
 
There seem to be conflicts between the objective (should...existing
MPLS....) 
<Nurit> I am afraid I cannot see the conflict between the sentences....I
consulted with some colleagues and they could not see the conflict as
well. \<Nurit>
and the toolset development (...tools...not...supported in MPLS). [RFC
5860] says that "...the MPLS-TP design, SHOULD as far as reasonably
possible, reuse existing MPLS standards." which looks more appropriate
to me as the objective. Please clarify this point.

4) 1.1 Scope
 
The third one of the "three objectives" in this draft reads 
 
   o  The OAM toolset developed for MPLS based transport networks needs
      to be fully inter-operable with existing MPLS OAM tools as
      documented in [RFC 5860].
 
I may be wrong but I find [RFC 5860] only requires OAM interoperability
between distinct domains (w/wo IP capabilities). The original
description is as follows:
 
   It is REQUIRED that OAM interoperability is achieved between distinct
   domains materializing the environments described in Section 2.1.4.
My understanding of the "OAM interoperability" mentioned here refers to
MPLS-TP OAM interoperable in different domains, but not MPLS-TP OAM and
MPLS OAM interoperability. 
 
<Nurit> Section 2.1.4 to which you refer in your quote, discusses the
environments. 
"There are environments where IP capabilities are present in the data
plane.  IP/MPLS environments are examples of such environments....".
RFC 5860 continues to require that "When MPLS-TP is run with IP routing
and forwarding capabilities, it MUST be possible to operate any of the
existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD
[13], VCCV [5], and VCCV-BFD [14])."
\<Nurit>

5) MPLS-TP v.s. MPLS based transport networks
The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g.
is it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport
networks? 
Are they the same? Or what is the relationship between them?
 
<Nurit> thank you for catching this. We will clarify that they are the
same. \<Nurit> 
 
Tina

---

From: Tina TSOU <[email-masked]>
Date: Sun, 22 Apr 2012 14:43:40 +0000

Hi Nurit,
Thank u for ur reply, comments are in line.
Have a good weekend.

Sent from my iPad

On Apr 17, 2012, at 12:18 AM, "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]<mailto:[email-masked]>> wrote:

Tina hi,

Please see inline.

Best regards,

Nurit

-----Original Message-----
From: ext Tina TSOU [mailto:[email-masked]]
Sent: Saturday, March 24, 2012 8:11 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: secdir review of draft-ietf-mpls-tp-oam-analysis-08

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.

I compared the OAM functions listed in this draft and those required in RFC5860 and find out one OAM function named Client Failure Indication (Section 2.2.10 of [RFC 5860]) is missing. I cannot see a reason for this. Since this is an informational analysis document, it is recommended to give a whole view. Specific clarifications are appreciated in the document.

<Nurit> this document provides an overview of the MPLS-TP OAM tools that are specified in separate RFCs. It was agreed by the working group that the final version of this document refers to RFCs only. draft-ietf-mpls-tp-csf on “Indication of Client Failure in MPLS-TP” was expired on September 2011, hence we cannot refer to this document.

Please note also that although the name of the FILE may confuse, this document does not make any analysis but rather presents an overview of the OAM tools. The purpose of the document is carried in the document TITLE and Abstract/Introduction. \<Nurit>

If there is no RFC to refer at the moment (perhaps FFS?), you may just reflect the simple fact in the document. This is also the purpose of an overview to let people know what is done and what is missing.

I still prefer to match the analysis or overview with the requirement RFC referenced in this document.

It is said in this document that compatibility with the existing tools has been maintained. But there is no detailed analysis which IMHO might be of great interest to the industry and should form an important part of this analysis document.

<Nurit>

As mentioned above, the purpose of the document is to provide an overview of the MPLS-TP OA tools. It is not a detailed analysis of the tools.

Still, I think your idea is excellent, and may be a subject for another I-D. \<Nurit>

OK.

3) 1.1 Scope

In the middle of this section, under the "three objectives", the first bullet reads

There seem to be conflicts between the objective (should...existing MPLS....)

<Nurit> I am afraid I cannot see the conflict between the sentences….I consulted with some colleagues and they could not see the conflict as well. \<Nurit>

and the toolset development (...tools...not...supported in MPLS). [RFC 5860] says that "...the MPLS-TP design, SHOULD as far as reasonably possible, reuse existing MPLS standards." which looks more appropriate to me as the objective. Please clarify this point.

My concern is that the objective in this document is not exactly the same as in RFC5860. It is proposed to keep aligned.

4) 1.1 Scope

I may be wrong but I find [RFC 5860] only requires OAM interoperability between distinct domains (w/wo IP capabilities). The original description is as follows:

My understanding of the "OAM interoperability" mentioned here refers to MPLS-TP OAM interoperable in different domains, but not MPLS-TP OAM and MPLS OAM interoperability.

<Nurit> Section 2.1.4 to which you refer in your quote, discusses the environments.

“There are environments where IP capabilities are present in the data plane.  IP/MPLS environments are examples of such environments….”.

RFC 5860 continues to require that “When MPLS-TP is run with IP routing and forwarding capabilities, it MUST be possible to operate any of the existing IP/MPLS and PW OAM protocols (e.g., LSP-Ping [4], MPLS-BFD [13], VCCV [5], and VCCV-BFD [14]).”

\<Nurit>

The draft uses both "MPLS-TP" and "MPLS based transport networks". E.g. is it "MPLS-TP OAM" or OAM toolset developed for MPLS based transport networks?

<Nurit> thank you for catching this. We will clarify that they are the same. \<Nurit>

Tina