Subject: [mpls-tp] working group last call on draft-ietf-mpls-tp-requirements-04

From: Loa Andersson <[email-masked]>
Date: Fri, 06 Feb 2009 11:11:08 +0100

All,

this is to initiate a working group last call for 
draft-ietf-mpls-tp-requirements-04.

This document is one of the key documents for the mpls-tp work,
in particular it is important that the ITU-T mpls-tp ad hoc team
verifies the completeness of the requirements and that we have a
good review form all parties.

Please review and send your comments to the mpls-tp list,
i.e. try to avoid doing a "reply all on this message" !

The working group last call will end on Feb 28, 2009.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 06 Feb 2009 15:20:00 +0000

Colleagues,

In my rush to get this ready for last call I made an editing mistake,
requirement 30 currently reads

   30  MPLS-TP MUST support unidirectional, bidirectional and co-routed
       bidirectional point-to-point transport paths.

But it should read

   30  MPLS-TP MUST support unidirectional, bidirectional and associated
       bidirectional point-to-point transport paths.

This has no impact in terms of the meaning of the requirement, just an
editing error where I updated the terminology section to reflect discussion
on the MPLS-TP mailing list but forgot to subsequently update the
requirement to use the agreed term.

Ben

---

From: "BUSI ITALO" <[email-masked]>
Date: Thu, 19 Feb 2009 09:56:21 +0100

In attachment a first set of WG LC comments on
draft-ietf-mpls-tp-requirements-04

Italo

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: Friday, February 06, 2009 11:11 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [PWE3] working group last call on 
> draft-ietf-mpls-tp-requirements-04
> 
> All,
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 Feb 2009 20:21:09 +0000

Italo,

Thanks. I will review & incorporate as part of WG LC.

For my information whose comments are these as you use "we" in several
places, are these formal comments from ITU or your/ALU comments?

Thanks
Ben

On 19/02/2009 08:56, "BUSI ITALO" <[email-masked]> wrote:

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

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 20 Feb 2009 08:54:40 +0100

Ben,

Your are right, I did not realized the potential confusion on the source
of the comments.

The "we" in the document means myself and other colleagues of mine
within ALU who have jointly review the draft.

I have sent the comments both to ITU-T and IETF mailing list because I
think ITU-T can endorse some of them.

However these comments need to be reviewed and agreed by ITU-T before
being called "ITU-T comments"

Thanks for having requested the clarification. This helps avoiding
misunderstandings.

Next time I will be more carefull in clarifying whether the comments are
individual or ITU-T.

Italo

> From: Ben Niven-Jenkins [mailto:[email-masked]] 
> Sent: Thursday, February 19, 2009 9:21 PM
> To: BUSI ITALO; [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [PWE3] working group last call on

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 22 Feb 2009 20:37:43 +0000

Italo,

I have incorporated most of your suggested edits but I left some existing
text which you suggested deleting as I believe it adds emphasis and is
important even if in some regards it is not strictly necessary.

Also see below for specific responses to some of your comments

1) IB Comment: Is the terminology in this section aligned with the Rosetta
stone draft?

BPN: Well there is no rosetta stone draft currently! What I expect is that
the MPLS-TP requirements draft be the definitive source of
terminology/definitions for the terms defined within it. If and when a
rosetta stone draft is produced it will reuse those terms defined in MPLS-TP
and enhance them as deemed necessary to map ITU & IETF terminology.

2) IB Comment: It seems that the definition of associated bidirectional path
as a bidirectional trail composed by two associated unidirectional network
connections. MPLS-TP requires only the support of unidirectional and
co-routed bidirectional transport paths.

BPN: You are correct in your interpretation of the definition of an
associated bidirectional path. Although ITU only requires unidirectional &
co-routed bidirectional paths other participants have expressed a
requirement for associated bidirectional paths (as is how MPLS achieves
bidirectionality today). Therefore including all 3 as requirements is
necessary but it is up to individual vendors/operators what they
implement/deploy.

3) IB Comment: The definition of the bidirectional path is not consistent
with the discussion on the mailing list. It is proposed to remove the
definition above.

BPN: I disagree, following discussion on the mailing list the terms I
thought we agreed were:
Unidirectional
Bidirectional
Associated bidirectional

Where bidirectional is synonymous with co-routed bidirectional. Some
confusion may have been caused by me accidentally leaving the definition of
co-routed bidirectional in draft -04.

I have therefore added the enhancement you suggested to the definition of
co-routed bidirectional to the definition of bidirectional.
 
4) You requested definitions for terms client layer network & server layer
network, so I propose the following:

Client layer network: In a client/server relationship (see G.805), the
client layer network receives a (transport) service from the lower server
layer network (usually the layer network under consideration).

Server layer network: In a client/server relationship (see G.805), the
server layer network provides a (transport) service to the higher client
layer network (usually the layer network under consideration).

5) IB Comment: Propose to replace "MUST reuse" with "SHOULD reuse" in
requirement 3:

Any new functionality that is defined to fulfil the requirements for MPLS-TP
MUST be agreed within the IETF through the IETF consensus process and MUST
re-use (as far as practically possible) existing MPLS standards.

BPN: Italo, this is a potential hot potato.

6)

Ben

BTW I don't know what you do with your Word documents but they always seems
to crash my version of Word.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 22 Feb 2009 20:38:34 +0000

Oops I pressed send too early.  I will continue from 5 in a different mail.
Ben

On 22/02/2009 20:37, "Ben Niven-Jenkins" <[email-masked]>
wrote:

> Italo,
> 
> I have incorporated most of your suggested edits but I left some existing text
> which you suggested deleting as I believe it adds emphasis and is important
> even if in some regards it is not strictly necessary.
> 
> BPN: Well there is no rosetta stone draft currently! What I expect is that the
> MPLS-TP requirements draft be the definitive source of terminology/definitions
> for the terms defined within it. If and when a rosetta stone draft is produced
> it will reuse those terms defined in MPLS-TP and enhance them as deemed
> necessary to map ITU & IETF terminology.
> 
> connections. MPLS-TP requires only the support of unidirectional and co-routed
> bidirectional transport paths.
> 
> BPN: You are correct in your interpretation of the definition of an associated
> bidirectional path. Although ITU only requires unidirectional & co-routed
> bidirectional paths other participants have expressed a requirement for
> associated bidirectional paths (as is how MPLS achieves bidirectionality
> today). Therefore including all 3 as requirements is necessary but it is up to
> individual vendors/operators what they implement/deploy.
> 
> 3) IB Comment: The definition of the bidirectional path is not consistent with
> the discussion on the mailing list. It is proposed to remove the definition
> above.
> 
> BPN: I disagree, following discussion on the mailing list the terms I thought
> we agreed were:
> Unidirectional
> Bidirectional
> Associated bidirectional
> 
> Where bidirectional is synonymous with co-routed bidirectional. Some confusion
> may have been caused by me accidentally leaving the definition of co-routed
> bidirectional in draft -04.
> 
> Client layer network: In a client/server relationship (see G.805), the client
> layer network receives a (transport) service from the lower server layer
> network (usually the layer network under consideration).
> 
> Server layer network: In a client/server relationship (see G.805), the server
> layer network provides a (transport) service to the higher client layer
> network (usually the layer network under consideration).
> 
> BTW I don't know what you do with your Word documents but they always seems to
> crash my version of Word.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 22 Feb 2009 21:08:05 +0000

[Apologies if my spelling is a bit off the 'k' key on my keyboard has
broken].

requirement 2:

BPN: Italo, this is a potential hot potato. I think MUST reuse must stay but
(as far a practically possible) allows for not reusing if it can be
justified.

6) IB Comment: The high-level requirement to have MPLS-TP interoperable with
MPLS and PWE3 is correct. However the requirement as specified here
[requirement 3] is too vague. There is a need to details the requirements
for interoperability (e.g. which mechanisms and capabilities MUST
interoperate).

Requirement 3: Mechanisms and capabilities MUST be able to interoperate,
without a gateway function, with existing IETF MPLS [RFC3031] and IETF PWE3
[RFC3985] control and data planes where appropriate.

BPN: Firstly following comment from Lou to align with MPLS-TP framework I
have changed requirement 3 to the following:

Mechanisms and capabilities MUST be able to interoperate with existing IETF
MPLS and IETF PWE3 control and data planes where appropriate.
  a.Data plane interoperability MUST NOT require a gateway function.

Basically the requirement is really stating that you must reuse as much as
possible and provide backwards compatibility where possible. I think trying
to define detailed interoperability requirements will be difficult and time
consuming to reach consensus on and I wouldn't like to see the MPLS-TP
Requirements document being held up by interoperability requirements.

If necessary I could add a sentence on backwards compatibility to the
requirement to make that clearer?

7) IB Comment: What is the difference between ³MUST support² in Req.7 and
³MUST allow² in Req.8?

BPN: Nothing. I have changed requirement 8 to "MUST support".

8) IB Comment: it is not clear what are "homogeneous domains".

BPN: homogeneous domains means domains of the same kind, e.g. Same
technology.

9) IB Comment: A multi-layer network that includes an MPLS-TP layer, can
also be operated according to the MRN. A requirement that allows integrated
management of several server layers should be added.

BPN: Lots of things can be done but it is my opinion that requirements
related to multi region networks are outside the scope of the MPLS-TP
Requirements at this time. I think it will be difficult and time consuming
to reach consensus on and I wouldn't like to see the MPLS-TP Requirements
document being held up by these requirements.

10) IB Comment: The requirements for bidirectional path (as defined above
[requirement 30]) are outside the scope of this document because they impact
not only the MPLS-TP layer network but also other layer networks.

BPN: I don't see how they affect other layer networks. Anyway, Although ITU
only requires unidirectional & co-routed bidirectional paths other
participants have expressed a requirement for associated bidirectional paths
(as is how MPLS achieves bidirectionality today). Therefore including all 3
as requirements is necessary but it is up to individual vendors/operators
what they implement/deploy.

11) IB Comment: Which is the relationship between this section [2.10
security requirements] and section 4 [security considerations]? They contain
the same text

BPN: Yes. Section 4 is mandatory for all Internet drafts but I thought it
worthwhile to have a dedicated section on security requirements to show that
security requirements hadn't been overlooked but the already documented ones
were sufficient. 

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Feb 2009 21:39:08 -0000

> 5) IB Comment: Propose to replace "MUST reuse" with "SHOULD
> reuse" in requirement 2:
>
> Any new functionality that is defined to fulfil the requirements for
> MPLS-TP MUST be agreed within the IETF through the IETF
> consensus process and MUST re-use (as far as practically possible)
> existing MPLS standards.
>
> BPN: Italo, this is a potential hot potato. I think MUST reuse
> must stay but (as far a practically possible) allows for not reusing
> if it can be justified.

Thanks, Ben.

Yes, I'd like to understand what the issue is here.

If the existing MPLS mechanisms do not satisfy the requirements then new 
mechanisms need to be developed. But if the existing mechanisms do satisfy 
the requirements why would they not be reused? And even if the existing 
mechanisms do not fully meet the requirements, why would we not extend them 
rather than inventing something new.

We need to be clear that a significant objective here is to ensure that 
MPLS-TP is a small step function on existing MPLS. This will enhance 
interworking, development, testing, deployment, and operations of MPLS-TP.

Adrian

---

From: <[email-masked]>
Date: Mon, 23 Feb 2009 12:04:52 -0000

Ben,

One comment...snipped to it:
 
Ben wrote 22 February 2009 21:08
> requirement to make that clearer?

Ben is right to urge caution here.  And I want to make a huge plea here
to think about what *interworking* really means, because we have a
watershed opportunity here with MPLS-TP to get some important things
done right....and it will be a tragedy if we fail to do this.

All layer networks that do not support end-system application adaption
functions directly have *no need whatsoever* to interwork as peers
across E-NNIs.  Moreover, this situation will become increasingly worse
wrt consequences if we try and peer interwork (i) different technologies
belonging to same mode or (ii) (worse case) technologies belonging to
different modes.

I personally think it's professionally questionable/unethical that there
are technology pressure groups out there pushing UNIs/E-NNIs in non
top-of-stack technologies....so today this would be MPLSF, MEF and OIF.
Sorry if that offends anyone, but it is a fact....these bodies will
create unnecessary work/problems/costs for operators where none should
exist.

The only purpose of networking it to allow external (to the network)
CPE/humans to have a communication (message/file/stream)...if not true
then networking serves no purpose.  This means that the layer network
technology that does provide these end-system application adaptation
functions *must* be present at the top-of-stack in *all* networking
scenarios...the prime examples of this today are the Internet (big I)
and the PSTN.  The only other technology that had any justifiable
top-of-stack claim was ATM (due to having AALs) but this technology is
no longer being advanced.

So even if we go through the grief/cost of attempting peer interworking
of non-top-of-stack layer networks, when we come to the end of such a
tandemed sequence we still have to pass the real communications task to
a higher layer top-of-stack network that MUST still be present and does
support the end-system application adaptation functions.  Ergo, we might
as well never have bothered interworking the lower layer networks but
simply terminated all their DP/CP/MP functions at the interworking point
and passed the real top-of-stack layer network across transparently.
Further, what we can see here is that the real 'interworking' need is
for a transparent client/server relationship between the true
top-of-stack (client) layer network and each of its lower
non-top-of-stack (server) layer networks.

Moreover, having realised this, we might also then apply Occam's razor
to the problem too and observe that '(i) since peer interworking of
non-top-of-stack layer networks serves no real purpose execept to
generate work/cost, and (ii) if the non-top-of-stack networks can be
made so alike that peer interworking is indeed possible, then we might
as well just select one of these are get rid of the rest'!

The logic here is irrefutably true.

Please note carefully that when we do interwork real top-of-stack layer
networks we usually do this *for practical/cost purposes* as a large
aggregate in a bottom-of-stack section layer of a transport network that
has real phyical interfaces.  This just provides a p2p (ie not
networked) physical bit pipe....and the key properties this has to have
are:
-	treats all client symbols equally;
-	preserves client symbol ordering;
-	makes no attempt to understand/change the client symbols;
-	and (from performance inheritance considerations) the traffic
behaviour of client X should have no impact on the performance
experienced by client Y. 

Put another way...this is *NOT* an E-NNI in this section layer
technology, it is a transparent DP only bit pipe (there is no CP or MP
interconnect here) simply because there has to be a real physical EM
wave interconnect for the higher layer top-of-stack communications
agreegate to pass across.  So the real E-NNI that covers DP/CP/MP
interworking as peers only occurs in the higher top-of-stack layer
network (though the MP is not usually interworked and there are
restrictions on the nature of the CP interworking).

So when we come to look at MPLS-TP it has no need to peer interwork with
MPLS...and neither of these have any need whatsover to interwork with
Ethernet (heaven help us if we allowed this).  As far as PWs are
concerned these are only an artefact of how MPLS was orginally
specified.....and there must be no *PW layer network* in MPLS-TP for
reasons I have explained in previous mails.  If there is then MPLS-TP
will have failed miserably as a transport network.  So if PWs remain
they must go back to a pure adaptation function in MPLS-TP....but to be
brutally honest they might as well be removed altogether as there is no
technical need for them at all.  Sorry again if this offends anyone, but
I am only working through the technical logic here.

What we should really concentrate on now is getting MPLS-TP specified to
its best possible case for a transport role, and we should not be
sidetracked by flawed arguments for lots of peer interworking with other
technologies....and this includes MPLS as-is (which BTW is not even
singular anyway), and esp Ethernet.

So for MPLS-TP lets concentrate on getting:
-	a good OOB CP/MP solution...and re-use GMPLS, which I believe is
also Ben's take on the difference between sensible functional re-use and
silly peer interworking arguments
-	incorporate a proper PID function......
-	...and get simple/sparse always-on defect detection/handling OAM
where the OAM indicate flag is part of the normal DP traffic header (no
extra headers inserted for OAM please).....and the proposal from John
Drake and myself covers both these latter points, but I am open to other
sensible suggestions here.

Sorry this another bit of a rant, but I feel very strongly about not
seeing MPLS-TP screwed-up when there is no need to.

regards, Neil

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 27 Feb 2009 17:34:11 +0100

In attachment the complete set of WG LC comments on
draft-ietf-mpls-tp-requirements-04.

I have prepared two versions of the comments: a .txt ASCII version and a
.doc Word version.

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 wish you all a nice week-end

Italo

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of BUSI ITALO
> Sent: Thursday, February 19, 2009 9:56 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] [PWE3] working group last call 
> ondraft-ietf-mpls-tp-requirements-04
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 27 Feb 2009 14:49:05 -0500

Italo,

Sorry for the delay, but it's not yet the 28th ... anyway, in a
separate email, I sent (a few minutes ago) Verizon's LC comments on
the draft.

Thanks,
Andy