Subject: [mpls-tp] Comments on draft-ietf-mpls-tp-requirements-00.txt

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Dec 2008 08:55:08 -0000

Hi editors of draft-ietf-mpls-tp-requirements,

Please find attached a bunch of comments on this draft.

The comments come from three sources...

1. Input on the requirements for providing survivability in
   ring topologies gathered from various helpful people at
   the ITU-T meeting in Geneva.
   Although we might note that all of the requirements 
   explicitly called out for survivability in ring topologies, it
   is pragmatic to include a separate section listing these
   requirements so that it is abundantly clear that:
   - we *do* support survivability in rings
   - we have examined all of the requirements
   - those requirements can be seen to be generic

2. Rewrite of all generic survivability requirements by Nurit
   and me. Since we are responsible for the survivability 
   framework I-D, we thought it a good idea to give the
   requirements a very thorough review.

3. General comments on the whole document from me.

Apologies to everyone for using Word to highlight the changes.

Thanks,
Adrian

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 12 Dec 2008 19:38:48 +0000

Adrian,

Thanks for documenting these.  I have incorporated them into
draft-ietf-mpls-tp-requirements-01 which I have just submitted for
publication.

Some responses to the questions raised in the document you attached.

1) Terminology section:
Comment: Will you move these definitions to the Rosetta draft and add a
pointer?

In principle I have no issue with doing that my only concern is that the
rosetta draft then becoming a gating factor to publication of the
requirements document.  I guess it depends how long we think it will take
for the terminology to be hammered out and the rosetta draft to become
stable.

2) "Transport path: A connection as defined in G.805 [ITU.G805.2000]. The
combination of a PW (Single Segment or Multi-Segment) and LSP corresponds to
an MPLS-TP transport path."
Comment: Discussions in Geneva found this remarkably hard to understand.
It begs questions about whether the service is a transport path; whether
the path is the concatenation of the LSPs in the transport case (in which
case what has the PW got to do with it?), etc.

Originally I was working under the assumption that an MPLS-TP
connection/transport path always consisted of a PW and a LSP, i.e.
Everything wads wrapped in a PW and then wrapped in an LSP before being
transported.  From our recent discussion I think that is not a correct
assumption and that an MPLS-TP connection/transport path is an LSP that may
or may not carry one or more PWs.

I have changed the definition to the following to try and reflect this:
Transport path: A connection as defined in G.805 [ITU.G805.2000]. A
Transport path corresponds to an MPLS-TP LSP or to an MPLS-TP LSP and its
associated PW or PWs (Single Segment or Multi-Segment).

3) [Editor note: There are two semantically identical candidate definitions
for "ring topology". We should either select one, or present both for
clarity.]

I selected the first definition as I think it is easier to understand.

4) "MPLS-TP MUST support MPLS labels that are assigned by the downstream
(with respect to data flow) node per [RFC3031] and [RFC3473] and MAY support
context-specific MPLS labels as defined in [RFC5331]."
Comments: This is a solution requirement and is as bad as "must not support
PHP".
Can we convert this into a proper functional requirement? In order to do
that you would need to think about the function that drives downstream on
demand label allocation, and why context-specific labels were introduced.

It was Rahul who was keen on including this text on context-specific labels
during the Boston Design Team meeting. Rahul, could you respond Adrian's
comment?

5) "MPLS-TP transport paths MUST NOT perform merging in a way that prevents
the unique identification of the source at the destination (e.g. no use of
LDP mp2p signaling in order to avoid losing LSP head-end information, no use
of PHP, etc)."
Comment: Is this simply a restatement of requirement 24? If so, there is no
need to mention merging.
Perhaps we need to get at the real requirement. Requiring to not support a
certain form of merging  or PHP is a requirement to not perform specific
solution function. We should not do that. We need to describe the function
that is required.
Is the real requirement a need to identify the source and path? Or the flow?

The real requirement is that the source of a transport path must be
identifiable at its destination and that transport paths must only have one
ingress point.

However I think this is already covered by req 24 and the requirement that
states MPLS-TP MUST support P2P and P2MP.

So I have removed the requirement quoted above.

6) "MPLS-TP MUST be able to accommodate new types of client networks and
services."
Comment: See my separate email. New types of PW or other things in addition
to PW?

We're not prescriptive, who knows what the future holds! Seriously, really
it's just saying MPLS-TP should be extensible so new types of PW. However,
it is not restricted to new types of PW (that'd be stating a solution!).

7) "MPLS-TP SHOULD support mechanisms to minimize traffic impact during
network reconfiguration.
Comment: Minimize? To what level?
Used like this it may mean "reduce to zero."

To the minimal level possible.  Ideally zero but "minimize" is used as it is
recognised that stating no traffic impact may be unrealistic to achieve.

8) "MPLS-TP SHOULD support mechanisms which ensure the integrity of the
transported customer's service traffic."
Comment: Is this "MUST NOT modify user traffic" or is it really a request to
provide integrity guarantees to the client layer?

I'm not sure.  I suspect the former. Does anyone have a view on this?

9) "The requirements for ASON signaling and routing and the requirements for
multi-region and multi-layer networks as specified in [RFC4139], [RFC4258]
and [RFC5212] respectively apply to MPLS-TP."
Comment: I am really worried about this requirement and the reference to
CCAMP RFCs without discussion with the CCAMP chairs. Worst of these is the
reference to RFC 4258.
I would really like to understand why anyone has a requirement for RFC 4258
(ASON routing) and I am not clear that RFC 5212 is applicable unless it is
the intention to support integrated multi-layer networks.

Deborah is a co-author :-) This came out of the Boston Design Team meeting I
have copied the relevant section of the minutes below:
" Some requirements are specific to MPLS-TP but others are general ASON
requirements. Should the general requirements be referenced and focus this
section on MPLS-TP requirements.  Agreed.  Eg., refer to G.8080  - Which
points do we remove? Could refer to ASON requirements, refer to updated ASON
routing requirements and cover deltas from there."

I believe I included references to documents that folks suggested.  If those
references are incorrect I can remove them.

10) "In some situations it is impractical to expect acceptable recovery
performance to be achieved using dynamic recalculation of transport path
routes.  For this reason, it is necessary to allow for pre-planning of
protection routes for selected transport paths."
Comment: Is this a requirement? Or is the performance a requirement?
Or perhaps it is just an interesting piece of information to keep the reader
amused.

It is an artifact of the early versions where we included some commentary to
explain the rationale behind some of the requirements. I have removed it as
I do not believe it is required any longer.

11) " An MPLS-TP control plane SHOULD provide a common control mechanism for
architecturally similar operations."
Comment: That is a little subjective

It is really just trying to say reuse as much as possible.

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 14 Dec 2008 14:56:12 -0000

Ben,

Thanks for a really rapid turn-round.

>> 1) Terminology section:
>> Comment: Will you move these definitions to the Rosetta draft
>> and add a pointer?
>

Agreed.

>> 2) "Transport path: A connection as defined in G.805 [ITU.G805.2000].
>> The combination of a PW (Single Segment or Multi-Segment) and LSP
>> corresponds to an MPLS-TP transport path."

OK

>> 3) [Editor note: There are two semantically identical candidate
>> definitions for "ring topology". We should either select one, or
>> present both for clarity.]
>

wfm

>> 4) "MPLS-TP MUST support MPLS labels that are assigned by the
>> downstream (with respect to data flow) node per [RFC3031] and
>> [RFC3473] and MAY support context-specific MPLS labels as
>> defined in [RFC5331]."
>> Comments: This is a solution requirement and is as bad as "must not
>> support PHP".
>> Can we convert this into a proper functional requirement? In order
>> to do that you would need to think about the function that drives
>> downstream on demand label allocation, and why context-specific
>> labels were introduced.
>

Looking forward to that discussion.
I'll pull it out into a separate thread.

>> 5) "MPLS-TP transport paths MUST NOT perform merging in a way
>> that prevents the unique identification of the source at the destination
>> (e.g. no use of LDP mp2p signaling in order to avoid losing LSP head-
>> end information, no use of PHP, etc)."
>> Comment: Is this simply a restatement of requirement 24? If so, there
>> is no need to mention merging.
>> Perhaps we need to get at the real requirement. Requiring to not
>> support a certain form of merging  or PHP is a requirement to not
>> perform specific solution function. We should not do that. We need
>> to describe the function that is required.

Good.

>> 6) "MPLS-TP MUST be able to accommodate new types of client
>> networks and services."
>> Comment: See my separate email. New types of PW or other things
>> in addition to PW?
>

OK

>> 7) "MPLS-TP SHOULD support mechanisms to minimize traffic
>> impact during network reconfiguration.

OK

>> 8) "MPLS-TP SHOULD support mechanisms which ensure the
>> integrity of the transported customer's service traffic."
>> Comment: Is this "MUST NOT modify user traffic" or is it really a
>> request to provide integrity guarantees to the client layer?
>

OK.
New thread for this.

>> 9) "The requirements for ASON signaling and routing and the
>> requirements for multi-region and multi-layer networks as specified
>> in [RFC4139], [RFC4258] and [RFC5212] respectively apply to
>> MPLS-TP."
>> Comment: I am really worried about this requirement and the reference
>> to CCAMP RFCs without discussion with the CCAMP chairs. Worst
>> of these is the reference to RFC 4258.
>> I would really like to understand why anyone has a requirement for
>> RFC 4258 (ASON routing) and I am not clear that RFC 5212 is
>> applicable unless it is the intention to support integrated multi-layer
>> networks.
>
> Deborah is a co-author :-) This came out of the Boston Design Team meeting
> I have copied the relevant section of the minutes below:

OK.
I'll suggest some replacement text.

>> performance to be achieved using dynamic recalculation of transport
>> path routes.  For this reason, it is necessary to allow for pre-planning
>> of protection routes for selected transport paths."
>> Or perhaps it is just an interesting piece of information to keep the
>> reader amused.
>

OK

>> 11) " An MPLS-TP control plane SHOULD provide a common control
>> mechanism for architecturally similar operations."

OK

Very many thanks.

Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Sun, 14 Dec 2008 18:10:51 +0100

Ben, Adrian,

The PW and LSP are elements in different layer networks and can never be
combined into a single "transport path". Each layer network will have its
own set of connections ('transport paths'). Not being sure at the moment if
a SS-PW is representing a layer entwork, or is just the equivalent of a "MAC
flow inside of a rooted-multipoint VLAN", I prefer to identify the following
generic layer stack in an MPLS-TP network:

        Customer services
---------------------------------
| MPLS-TP Channel | ETH Channel |
---------------------------------
|        MPLS-TP Path           |
---------------------------------
|        MPLS-TP Section        |
---------------------------------
|       Physical Media          |
---------------------------------
 MPLS-TP Transport Module (MTM-n)

This layer stack on selected interfaces (e.g. access link, E-NNI link) may
be operated without MPLS-TP Path layer, and will then look like:

        Customer services
---------------------------------
| MPLS-TP Channel | ETH Channel |
---------------------------------
|        MPLS-TP Section        |
---------------------------------
|       Physical Media          |
---------------------------------
 MPLS-TP Transport Module (MTM-n)

The connections in each of the above layers are:
- MPLS-TP Channel: p2p and p2mp
- ETH Channel: rmp and mp2mp
- MPLS-TP Path: p2p
- MPLS-TP Section: p2p
- Physical Media: p2p.

For p2p business services, the MPLS-TP Channel layer network will be
equipped with a p2p MPLS-TP Channel connection. This channel connection will
be implemented by a MPLS-TP MS-PW connection.

For p2p carrier-carrier services (typically a MPLS-TP path or section
connection), the MPLS-TP channel layer network in the carrier-carrier
network may either continue the carrier's MPLS-TP path or section
connection, or may encapsulate those carrier connections into its own
MPLS-TP Channel layer connection.

For rmp or mp2mp business services or rmp layer 3 aggregation services, the
ETH Channel layer network will be equipped with an rmp or mp2mp ETH Channel
"connection" (which is referred to in G.8010 as an ETH flow domain
fragment).

Both the MPLS-TP channel and ETH channel "connection" signals will be
identified with a 20-bit Label carried in the label field of a Label Stack
Entry header.

To support the transport of service signals in the channel layers, the
MPLS-TP Path layer network is equipped with a number of MPLS-TP path layer
connections (i.e. tunnels) that provide G.805 Links in the mPLS-TP Channel
and ETH Channel layer networks.

The MPLS-TP path connection signals will be identified with a 20-bit Label
carried in the label field of a Label Stack Entry header.

The MPLS-TP Seciton layer network supports section layer connections that
provide G.805 Links in the MPLS-TP Path layer network (within metro and core
domains) and MPLS-TP/ETH Channel layer networks (within access links and
E-NNI links).

The MPLS-TP section connection signals will be "unlabelled" when carried
over a Physical Media connection (there is only one section connection
signal present, which does not require any labelling). When such section
connection signal is carried over a carrier-carrier network, then the
section connection signal will be labelled like a MPLS-TP channel connection
signal when caried directly over the carrier-carrier's MPLS-TP path
connections.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: zondag 14 december 2008 15:56
To: Ben Niven-Jenkins; [email-masked]
Subject: Re: [mpls-tp] Comments on draft-ietf-mpls-tp-requirements-00.txt

Ben,

>> 1) Terminology section:
>> Comment: Will you move these definitions to the Rosetta draft and add 
>> a pointer?
>
> In principle I have no issue with doing that my only concern is that 
> the rosetta draft then becoming a gating factor to publication of the 
> requirements document.  I guess it depends how long we think it will 
> take for the terminology to be hammered out and the rosetta draft to 
> become stable.

Agreed.

>> It begs questions about whether the service is a transport path; 
>> whether the path is the concatenation of the LSPs in the transport 
>> case (in which case what has the PW got to do with it?), etc.
>
> Everything wads wrapped in a PW and then wrapped in an LSP before 
> being transported.  From our recent discussion I think that is not a 
> correct assumption and that an MPLS-TP connection/transport path is an 
> LSP that may or may not carry one or more PWs.
>
> Transport path corresponds to an MPLS-TP LSP or to an MPLS-TP LSP and 
> its associated PW or PWs (Single Segment or Multi-Segment).

OK

wfm

>> [RFC3473] and MAY support context-specific MPLS labels as defined in 
>> [RFC5331]."
>> Can we convert this into a proper functional requirement? In order to 
>> do that you would need to think about the function that drives 
> It was Rahul who was keen on including this text on context-specific 
> labels during the Boston Design Team meeting. Rahul, could you respond 
> Adrian's comment?

>> 5) "MPLS-TP transport paths MUST NOT perform merging in a way that 
>> prevents the unique identification of the source at the destination 
>> perform specific solution function. We should not do that. We need to 
>> describe the function that is required.
> identifiable at its destination and that transport paths must only 
> have one ingress point.
>
> However I think this is already covered by req 24 and the requirement 
> that states MPLS-TP MUST support P2P and P2MP.
>

Good.

>> 6) "MPLS-TP MUST be able to accommodate new types of client networks 
>> and services."
>> Comment: See my separate email. New types of PW or other things in 
>> addition to PW?
>
> We're not prescriptive, who knows what the future holds! Seriously, 
> really it's just saying MPLS-TP should be extensible so new types of 
> PW. However, it is not restricted to new types of PW (that'd be stating a
solution!).

OK

>> 7) "MPLS-TP SHOULD support mechanisms to minimize traffic impact 
>> during network reconfiguration.
> To the minimal level possible.  Ideally zero but "minimize" is used as 
> it is recognised that stating no traffic impact may be unrealistic to 
> achieve.

OK

>> 8) "MPLS-TP SHOULD support mechanisms which ensure the integrity of 
>> the transported customer's service traffic."

OK.
New thread for this.

>> in [RFC4139], [RFC4258] and [RFC5212] respectively apply to MPLS-TP."
>> to CCAMP RFCs without discussion with the CCAMP chairs. Worst of 
>> these is the reference to RFC 4258.
>> applicable unless it is the intention to support integrated 
>> multi-layer networks.
>
> Deborah is a co-author :-) This came out of the Boston Design Team 
> meeting I have copied the relevant section of the minutes below:
> " Some requirements are specific to MPLS-TP but others are general 
> ASON requirements. Should the general requirements be referenced and 
> focus this section on MPLS-TP requirements.  Agreed.  Eg., refer to 
> G.8080  - Which points do we remove? Could refer to ASON requirements, 
> refer to updated ASON routing requirements and cover deltas from 
> there."
>
> I believe I included references to documents that folks suggested.  If 
> those references are incorrect I can remove them.

OK.

>> 10) "In some situations it is impractical to expect acceptable 
>> recovery performance to be achieved using dynamic recalculation of 
>> transport path routes.  For this reason, it is necessary to allow for 
>> pre-planning of protection routes for selected transport paths."
> It is an artifact of the early versions where we included some 
> commentary to explain the rationale behind some of the requirements. I 
> have removed it as I do not believe it is required any longer.

OK

OK

Very many thanks.

Adrian