Subject: Re: [mpls-tp] [PWE3] working group last call ondraft-ietf-mpls-tp-requirements-04

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 08 Mar 2009 21:40:35 +0000

Italo,

On 27/02/2009 16:34, "BUSI ITALO" <[email-masked]> wrote:
> In attachment the complete set of WG LC comments on
> draft-ietf-mpls-tp-requirements-04.

Thanks for the further comments.

> In the Word version, revision bars mark the proposed text change and
> colors help distinguishing the comments I have already sent (marked in
> green) from new comments (marked in yellow)

I will only address the yellow comments below as I have already addressed
and replied to the green comments. Unless otherwise stated I have
incorporated your proposed edits.

1) Comment: MPLS-TP requires only the support of unidirectional and
co-routed bidirectional
transport paths. 
 
If they are not required, it is not necessary to keep this definition.

BN: The current terms are unidirectional, bidirectional and associated
bidirectional. The definitions and document will be aligned with these
terms.

2) Comment: We think that the definition of Section above is not fully in
line with the ITU- T definition as given in the LS from last December 2008
meeting.

BN: Let's compare the two.

>From the LS statement
"If two MPLS-TP nodes are directly connected by a physical media or a non
MPLS-TP server layer (e.g. Ethernet, SONET/SDH, OTH), then to support the
OAM between those two nodes you need a Section Layer is used (which could be
supported by either the server layer or by MPLS-TP).
In the case the server layer network does not support adequate OAM
capabilities, an MPLS-TP Section layer network can provide those
capabilities for MPLS-TP clients."

>From MPLS-TP Requirements
   Section: A section is a server layer (which may be MPLS-TP or a
   different technology) which provides for encapsulation and OAM of a
   MPLS-TP transport path client layer.  A section layer may provide for
   aggregation of multiple MPLS-TP clients.  Note that G.805
   [ITU.G805.2000] defines the section layer as one of the two layer
   networks in a transmission media layer network.  The other layer
   network is the physical media layer network.

The LS statement says to support OAM between two directly connected MPLS-TP
nodes you need a section layer.

MPLS-TP Requirements says a section is a server layer (which may be MPLS-TP
or a different technology) which provides for encapsulation and OAM of a
MPLS-TP transport path client layer

>From what I can see the definitions align.

3) Suggestion to rephrase definition of transport path layer.

BN: I don't agree with your proposed edits
A) the transport path layer is a layer network. It may be composed of sub
layers but it is not a sub layer within a layer network it is a layer
network in itself.  However, it is one of the layers in a transport network.

B) Suggestion to replace client layer network with transport path. The
client may not be a transport path. The current definition is more general
than the ne you propose and I think it more accurately captures the
scenarios that may exist.

4) Suggested replacement of transport networks with transport technologies
in re 10. The requirement is about operations for network and explicitly
states functional requirements independent of technology.

5) Comment: I think we should add a requirement to allow MPLS-TP P2MP
transport paths to be established over P2P server (sub-)layer transport
paths. Otherwise Req.28 could be mis-interpreted as mandating that MPLS-TP
P2MP transport paths can only be established over P2MP server (sub-)layer
transport paths.  

BN: Have reworded to

"MPLS-TP MUST be capable of using P2MP server (sub-)layer capabilities as
well as P2P server (sub-)layer capabilities when supporting P2MP MPLS-TP
transport paths..."

6) Requirement 29 - change IP forwarding capability to IP capability.

BN: We have been back and forth on this one already we started with IP
capability, through agreement in MEAD design team meetings in Boston and
further work on the mailing list we refined down to IP forwarding
capability. I am reluctant to change it back again unless it can be
justified and clarification made as to what exactly is meant by IP
capability.

7) Control plane requirements - inclusion of ASON references.

BN: I am disinclined to include an extensive list of ASON requirements. It
is stated control plane MUST fit within ASON architecture and presumably the
ASON architecture as referenced took into consideration those requirements.
Therefore I will update references to include reference to G8080 Amd1 and
assume by implication the requirements in the extensive list of
Recommendations you suggest have been taken into consideration.

Also although you note that ASTN is not a term used in ITU any more I think
making reference to it is helpful as it shows that the requirements are not
just applicable to optical networks but to transport networks as well.  I am
happy to remove reference to ASTN if you do not agree with me.

8) Comment on req 49C

I have reworded to make clearer what is meant by "SHOULD include bandwidth
and QoS" New wording is

Recovery objectives SHOULD be configurable per transport path, and SHOULD
support objectives for bandwidth and QoS.

9) Comment on

   50  The recovery mechanisms MUST all be applicable to any topology.

I have changed to a SHOULD instead of removing as you suggest. I think this
gives the flexibility to allow topology optimised mechanisms if they can be
justified while keeping the overall intent that in general recovery
mechanisms should be capable of support any topology.

10) Comment: The current requirement is to support 1+1 protection with
unidirectional protection switching in order to have a mechanism that does
not require protection switching coordination between the two protection
switching endpoints.
 
No requirements to support 1+1 bidirectional protection switching have been
yet identified. 
 
There is a need to rephrase requirement 54 accordingly.

BN: Current text I have in -05 which is different to the text you reviewed
following other comments was agreed amongst a group of operators and I
believe you also indicated you were happy with it so I suggest keeping the
text agreed and not making the edits you suggest. Text can always be
reviewed again by you when I publish -05.

11) Suggestion add new requirement

A solution MUST be defined to support the MPLS-TP protection mechanisms
without any IP capability.

After requirement 55.

BN: I am happy to include but before I do can you clarify what exactly is
meat by "without any IP capability" so we can construct the requirement
correctly.

12) Comment: The requirements below [section 2.8.1.2] are not requirements
for a data plane behavior. We do not see any requirement on the data plane
behavior (other than general MPLS-TP data plane requirements) to support
restoration mechanisms. The requirements below apply to the either the
control plane or the management plane.

BN: While their relationship to data plane behaviour is very general I don't
want to repeat them twice for control & management plane so this seems as
good a place as any to put them so unless you want to suggest an alternative
section they fit in better that doesn't require repeating them I propose
leaving them where they are.

13) Req 61 Comment: The requirement is not clear, in particular because the
definition of "shared protection groups" is missing.

BN: shared protection groups are often known as shared risk groups - e.g.
Two fibres in the same duct would share risk at the duct level. IF you think
clarification is need in the document I will look up and reference/create a
definition for the term.

14) Requirement 63 defaults for revertive action.

BN: I have polled a group of operators for their opinion on what should be
the defaults for revertive action. I will include their consensus in the
document.

15) Comment: A clear way to distinguish when control plane protects from
when control plane notifies an action performed by data plane, should also
be defined. 

BN: I am not sure what the requirement is here? Isn't state about whether
the control plane protects or just notifies is just configuration state on a
switch isn't it? Or are you suggesting the control plane protocols should
support communicating (and negotiating?) such support?

16) Comment: The external controls defined in RFC 4427 are not fully aligned
with ITU-T requirements for external controls. It is proposed to align
Req.73 with ITU-T requirements for external controls.

BN: OK, can you provide a reference for ITU requirements for external
controls?

17) Comment: Not clear the need/role of timers for recovery operations

BN: If there is no need for them then cool. The requirement just states that
if they are needed they must be configurable.

18) Comment on Note that topology-specific recovery mechanisms are subject
to the development of requirements using the normal IETF process.

The purpose of the note above is not clear. The whole document (including
section 2.8.5) will be developed using the normal IETF process.

BN: I think this is left over from when we did not explicitly state topology
specific requirements. I have removed it.

19) Ring protection section Comment: The last sentence is a vendor/operator
issue and not a standard/requirement issue. It is proposed to remove it.

BN: As it is stated there is a benefit to topology specific mechanisms I
think it only fair to also highlight those benefits need to be balanced
against the other factors.

20) Comment Req.82 seems specific to ring topologies.

BN: It is in the ring protection section ;-)

21)
       88  Recovery actions in a ring MUST be data plane functions triggered
       by different elements of control.  The triggers are configured by
       management or control planes and are subject to configurable
       policy. 
 
Comment: It is suggested to clarify Req.88.

BN: Which part of req 88 is not clear so that I can clarify accordingly?

22) req 90 Comment: Scenario to be clarified (it should be included in Req.
99) 

BN: I have combined with requirement 99 which now reads

99  MPLS-TP recovery mechanisms in a ring:

    A  MUST include a mechanism to allow an implementation to handle
(including the coordination of) coexisting requests or triggers (i.e.,
multiple requests  not necessarily arriving simultaneously and located
anywhere in the ring) for protection switching based on priority. Note that
such coordination is the ring equivalent of the definition of shared
protection groups.

    B  MAY support multiple failures without reconfiguring the protection
actions.

23) Req 103 - I have now removed as it has been incorporated into req 99.

24) QoS: Comment: Add the following requirement:
 
It MUST be possible to support operator¹s policies regarding agreed traffic
profiles. 

BN: I don't understand the propose requirement can you explain it?

Ben