Subject: [mpls-tp] -03 of requirements draft & actions still to be resolved

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 25 Jan 2009 16:40:01 +0000

Colleagues,

I have edited draft-ietf-mpls-tp-requirements as per the discussions in
Ipswich last week and posted a new version (-03).

When I was editing the document I realised we had introduced a new term
(associated unidirectional) which may not be obvious in its meaning so I
added the following definitions to the terminology section as a
clarification:

   Associated unidirectional path: A path that supports traffic flow in
   both directions but which is constructed from a pair of
   unidirectional paths (one for each direction) which are associated
   with one another at the path's ingress/egress points.  The forward
   and backward directions may not follow the same path (links and
   nodes) across the network.

   Bidirectional path: A path where the forward and backward directions
   follow the same path (links and nodes) across the network.

   Unidirectional path: A path that supports traffic flow in only one
   direction.

Also the following people volunteered to provide text on the following areas
which I have not yet received:

1) Layer network: A layer network as defined in G.805 [ITU.G805.2000]
   provides for the transfer of client information and independent
   operations (OAM) of the client OAM.  For an explanation of how a
   layer network as described by G.805 relates to the OSI concept of
   layering see Appendix I of Y.2611 [ITU.Y2611.2006].

   [Editors' Note: Eric Gray to provide text on what is a layer network
   in the context of MPLS-TP.]

2) 4   It MUST be possible to construct MPLS-TP networks from equipment
       supplied by different vendors and to interconnect MPLS-TP
       networks made wholly from equipment from different vendors.

       [Editors' note: Andy Mallis/Eric Gray to refine text of this
       requirement.]

Ben

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

---

From: <[email-masked]>
Date: Sun, 25 Jan 2009 18:42:14 -0000

Hi Ben,

I find the term 'associated unidirectional' is confusing and not at all
obvious.  I wonder if something like this might be better (and possibly
simpler):

unidirectional connection - only considers information transfer from A
to Z and not the return direction.

bidirectional connection, independent routing - considers information
transfer from both A to Z and Z to A, where each direction has
independent routing, ie a pair of unidirectional connections usually
independently set-up between A(Z) and Z(A). 

bidirectional connection, congruent routing - considers information
transfer from both A to Z and Z to A, where each direction has congruent
routing (at least in this layer network - see Note), ie a pair of
congruently routed connections between A(Z) and Z(A) in this layer
network, usually set-up as a single bidirectional connection entity.

Note - If one wants to control both performance inheritance and
failure/availability objectives in some layer network N then it will be
important to consider the nature of all lower layer networks, ie 'down
to the duct'.  In particular, if the performance of layer network N is
only to be a function of its own design and traffic loading then all
lower layer network must be either co-cs mode (where this requirement is
always assured) or co-ps (where this has to be ensured by careful
engineering).

BTW - I would suggest taking advice from the G.800 experts, especially
Andy Reid and Alan McGuire, on what constitutes a layer network (this
needs to be generic and not something unique to MPLS-TP). 

regards, Neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
> Sent: 25 January 2009 16:40
> To: [email-masked]
> Subject: [mpls-tp] -03 of requirements draft & actions still 
> to be resolved
> 
> Colleagues,
> 
> I have edited draft-ietf-mpls-tp-requirements as per the 
> discussions in Ipswich last week and posted a new version (-03).
> 
> When I was editing the document I realised we had introduced 
> a new term (associated unidirectional) which may not be 
> obvious in its meaning so I added the following definitions 
> to the terminology section as a
> clarification:
> 
> Also the following people volunteered to provide text on the 
> following areas which I have not yet received:
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 25 Jan 2009 19:35:43 -0000

Right.
We might learn from the terminology used in 
draft-ietf-ccamp-gmpls-vcat-lcas-07.txt.
Here, of course, we are dealing with a group of LSPs, but we have some 
useful terms...

co-signaled
co-routed
diversely-routed

A
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, January 25, 2009 6:42 PM
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to 
beresolved

---

From: Loa Andersson <[email-masked]>
Date: Sun, 25 Jan 2009 23:42:37 +0100

Neil,

the term "congruent routing" helps me quite a bit, I've been asking
how far the congruency should be taken, is it only routing, or is it
e.g. same bw, same jitter, same labels per hop, etc. People told me
that it is only routing, but naming it "congruent routing" makes this
explicit.

/Loa

-- 

Loa Andersson

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

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

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Mon, 26 Jan 2009 05:57:58 +0100

Hi,
In principle I second these definitions.
The challenge we faced in Ipswich was whether the NEs (i.e. LSRs) need
to be aware of the "association" between two unidirectional congruent
LSPs that constitute bi-directional LSPs. Do we assume that in congruent
routing the NEs are aware of the association? I guess they are as they. 
For bidirectional LSPs, in independent routing - do we assume the LSPs
traverse the same route (although setup individually)?  
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Loa Andersson
Sent: Monday, January 26, 2009 00:43
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still tobe
resolved

Neil,

/Loa

> transfer from both A to Z and Z to A, where each direction has
congruent

-- 

Loa Andersson

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 26 Jan 2009 06:43:25 +0000

Colleagues,

OK, I tend to like co-routed so I propose the following definitions:

Bidirectional path: A path that supports traffic flow in both directions.
The forward and backward directions may not follow the same path (links and
nodes) across the network.
 
Co-routed bidirectional path: A bidirectional path where the forward and
backward directions follow the same path (links and nodes) across the
network.

Based on the above I propose rewording requirements 30 & 31 as follows

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

   31  The forward and backward directions of a bidirectional transport
       path MUST follow the same links and nodes within its (sub-)layer
       network.

NEW
   30  MPLS-TP MUST support unidirectional, bidirectional and co-routed
       bidirectional point-to-point transport paths.
 
   31  The forward and backward directions of a co-routed bidirectional
       transport path MUST follow the same links and nodes within its
       (sub-)layer network.

It is not clear to me whether requirement 31 is still necessary given it is
implicit in the definition of a co-routed bidirectional transport path but
leaving it in to be explicit does no harm.

Ben

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 08:50:02 -0000

Thanks Ben,
 
That is more clear IMO.  A few of further remarks:
 
(i) I am not sure why you inserted "(sub-)layer" in clause 31.  I would have thought 'layer' alone was OK.  Note - I am assuming (so I may be wrong here) that you are thinking about the fact that with the normal use of the S bit retained in MPLS-TP this creates sublayers (within the same parent MPLS-TP layer network).  If so then I think 'layer' alone is sufficient ( as a sublayer is still part of the same layer network)......but I have no strong feeling about this.
 
(ii) Do we need to be clear about whether a bidirectional congruently routed connection is set-up as a single paired entity or as 2 independent entities?  That is, there are the following possibilities that I tried to take into account:
- bidirectional pair of independently set-up and independently routed connections
- bidirectional pair of independently set-up but congruently routed connections
- bidirectional pair of simultaneously set-up (ie considered as a single entity) and congruently routed connections
(I think the 4th possibility makes no sense, ie simultaneous set-up as single entity but independently routed...so have excluded listing it here).
I was effectively not including the 2nd bullet case above, ie if congruently routed then always assume set-up as a paired single entity.
 
(iii) I would still advise getting G.800 experts to help with the definition of a layer network so we get it right.
 
(iv) I know it is not always under the control of one party to specify both the network mode/technology and the routing congruency of lower layer networks, but I still think there should be some form of 'health warning' on the performance inheritance and failure/availability impact of this...along the lines of the Note I gave.
 
regards, Neil

________________________________

From: Niven-jenkins,B,Ben,DMF R
Sent: Mon 26/01/2009 06:43
To: Loa Andersson; Harrison,N,Neil,CXM R
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to be resolved

Colleagues,

OLD

NEW

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 26 Jan 2009 14:52:10 +0000

Neil,

On 26/01/2009 08:50, "Harrison,N,Neil,CXM R" <[email-masked]> wrote:

> (i) I am not sure why you inserted "(sub-)layer" in clause 31.  I would have
> thought 'layer' alone was OK.  Note - I am assuming (so I may be wrong here)
> that you are thinking about the fact that with the normal use of the S bit
> retained in MPLS-TP this creates sublayers (within the same parent MPLS-TP
> layer network).  If so then I think 'layer' alone is sufficient ( as a
> sublayer is still part of the same layer network)......but I have no strong
> feeling about this.

This was purely because in Ipswich it was not clear to all present whether
every LSP at a different stack depth belonged to a new layer or not. As we
know LSPs a different stack depths are sublayers within a single MPLS layer
network so we inserted (sub-)layer to make this clearer.
 
> (ii) Do we need to be clear about whether a bidirectional congruently routed
> connection is set-up as a single paired entity or as 2 independent entities?
> That is, there are the following possibilities that I tried to take into
> account:
> - bidirectional pair of simultaneously set-up (ie considered as a single
> entity) and congruently routed connections
> (I think the 4th possibility makes no sense, ie simultaneous set-up as single
> entity but independently routed...so have excluded listing it here).
> I was effectively not including the 2nd bullet case above, ie if congruently
> routed then always assume set-up as a paired single entity.

This is something I meant to write about but then didn't :-(

The vcat-lcas draft (which I stole co-routed from) also talks about
co-signaled which is where something (or a group of things) are signaled in
a single control plane control plane signalling exchange)

We need to decide how this applies.

I have worked under the assumption that co-routed paths are also co-signaled
(i.e. The forward and backward directions are signalled in one exchange like
GMPLS bidir LSPs) but that bidirectional paths may or may not be
co-signaled.

I can add text to clarify this assuming folks agree with my assumption
above.

> of a layer network so we get it right.

Indeed.  The document will go to ITU for review as part of last call anyway
(this new draft is supposed to put the draft in a state that it is ready for
last call)

Ben

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 26 Jan 2009 11:16:27 -0600

Neil,

	See comments in line below...

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Monday, January 26, 2009 3:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to
beresolved

Thanks Ben,

(i)   I am not sure why you inserted "(sub-)layer" in clause 31. I
      would have thought 'layer' alone was OK.  Note - I am assuming
      (so I may be wrong here) that you are thinking about the fact
      that with the normal use of the S bit retained in MPLS-TP this
      creates sublayers (within the same parent MPLS-TP layer network).
      If so then I think 'layer' alone is sufficient ( as a sublayer is
      still part of the same layer network)......but I have no strong
      feeling about this.

Eric >> I think Ben answered this.  One thing to bear in mind is that 
Eric >> in some cases there may be confusion between stack depth and
Eric >> network layer resulting from the fact that it is possible to
Eric >> include multiple labels explicitly as part of the same layer.
Eric >> Hence the inclusion of "(sub-)layer" allows for fuzziness.
 
(ii)  Do we need to be clear about whether a bidirectional congruently
      routed connection is set-up as a single paired entity or as 2
      independent entities?

      That is, there are the following possibilities that I tried to
      take into account:

      - bidirectional pair of independently set-up and independently
        routed connections
      - bidirectional pair of independently set-up but congruently
        routed connections
      - bidirectional pair of simultaneously set-up (ie considered as a
        single entity) and congruently routed connections

      (I think the 4th possibility makes no sense, ie simultaneous
set-up
      as single entity but independently routed...so have excluded
listing
      it here).

      I was effectively not including the 2nd bullet case above, ie if
      congruently routed then always assume set-up as a paired single
      entity.

Eric >> This (set of) definitions appears to assume "set up" as an
Eric >> activity that is explicitly restricted to the control plane.
Eric >> Since - last I heard - we are still assuming that it is one
Eric >> of the use cases under consideration that MPLS-TP paths may
Eric >> be setup via configuration, this (set of) defintions doesn't
Eric >> seem to fit generally.  For example, "simultaneous set-up"
Eric >> is an interesting distinction in the context of configured
Eric >> MPLS-TP LSPs.
Eric >>
Eric >> If the distinction is - as I believe Nurit was getting at -
Eric >> that one case is that each node (in a layer network) along
Eric >> and MPLS-TP LSP "knows" the co-routed bi-directional nature
Eric >> of the LSP, then that is the distinction we should make.
Eric >>
Eric >> (As a side comment, I am not certain of the value - and the
Eric >> presumed associated responsibility - of having each node in
Eric >> an LSP "knowing" this is.  Are there alarm, monitoring and
Eric >> protection activities the node inherits fom this knowledge?
Eric >> Does the node have a status reporting responsibility that
Eric >> derives from this?  What does the technology gain?)
Eric >>
Eric >> Assuming we want to make the implied distinction, and that
Eric >> we're only talking about bi-directional paths, the set
Eric >> should become:
Eric >> 
Eric >> - Independently Routed
Eric >> - Congruently Routed and associated at the Layer Network level
Eric >> - Congruently Routed and associated at the Node level
Eric >>
Eric >> Where the distinction between the latter two cases is as
Eric >> shown in your list above (independent verses simultaneous)
Eric >> in the signaling case, and as follows in the configuration
Eric >> case:
Eric >>
Eric >> - If associated at the Layer Network level, there is some
Eric >>   logical construct that associates the two bi-directional
Eric >>   MPLS-TP LSPs, configured at LSP termination nodes.
Eric >> - If associated at the Node level, a similar construct is
Eric >>   needed at each node along the MPLS-TP LSP.
Eric >> 
Eric >> Note that the above (configuration) constructs may very well
Eric >> be required even if MPLS-TP LSPs are universally signaled.
Eric >>
Eric >> Note also that "congruent routing" does not imply any form
Eric >> of required dynamic behavior, nor the existence of a control
Eric >> plane.  It refer entirely to the presumption that the path
Eric >> in each direction follows the same list of nodes and links
Eric >> (though obviously in reverse order).
Eric >> 
Eric >> Note finally that combining a notion of node-level awareness
Eric >> of LSP bi-directionality with configured MPLS-TP LSPs makes
Eric >> it no longer possible to entirely dismiss the analogous 4th
Eric >> case since - in the configured case - it is possible to have
Eric >> node-level congruency for an LSP that is not necessarily 
Eric >> congruently routed at the layer network (MPLS-TP LSP) level.

(iii) I would still advise getting G.800 experts to help with the
      definition of a layer network so we get it right.

Eric >> We refer to the definition which I assume is the one provided 
Eric >> by these experts.  We found that definition insufficiently 
Eric >> clear in the context of MPLS-TP, MPLS and - generally - in the
Eric >> IETF.  As I recall, the intention is not for us to change the 
Eric >> definition, but to provide examples to clarify it.
Eric >> 
Eric >> If this is the case, then of course it makes sense to have 
Eric >> our clarifying examples reviewed by these experts to make 
Eric >> sure we've not misinterpretted the definition provided by 
Eric >> the experts.  However, asking these same experts to help in  
Eric >> providing examples may not be the most efficient way to come 
Eric >> up with useful examples in this context.
 
(iv)  I know it is not always under the control of one party to specify
      both the network mode/technology and the routing congruency of
      lower layer networks, but I still think there should be some form
      of 'health warning' on the performance inheritance and failure/
      availability impact of this...along the lines of the Note I gave.

Eric >> I'm not sure what this means.
 
regards, Neil

From: Niven-jenkins,B,Ben,DMF R
Sent: Mon 26/01/2009 06:43
To: Loa Andersson; Harrison,N,Neil,CXM R
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still to be
resolved

Colleagues,

Bidirectional path: A path that supports traffic flow in both
directions.
The forward and backward directions may not follow the same path (links
and
nodes) across the network.

OLD

NEW

It is not clear to me whether requirement 31 is still necessary given it
is
implicit in the definition of a co-routed bidirectional transport path
but
leaving it in to be explicit does no harm.

Ben

congruent

---

From: <[email-masked]>
Date: Mon, 26 Jan 2009 20:06:44 -0000

Thank you Eric for a most comprehensive set of comments.  There are some
points I feel I need to come-back on and/or seek further clarification,
so please see in-line (snipped where I am happy with your remarks) 

Eric Gray wrote 26 January 2009 17:16
> Eric >> activity that is explicitly restricted to the control plane.
NH=> Not at all.  A CP is only a special subset of the MP IMO anyway.  I
would also make the distinction of decoupling the routing and signalling
components....route calculation may be best accomplished centrally (MP)
whilst signalling can still be a distributed component/agent (CP). 

> Eric >> of the LSP, then that is the distinction we should make.
NH=> I would say core nodes should generally just 'do as they are told'
by the CP/MP.  But this has some interesting consequences when we come
to consider nested OAM sublayers (TCM) as I'll come on to shortly.

> Eric >> derives from this?  What does the technology gain?)
NH=> A good set of questions.  You may also like to consider the
consequences of embedding MEP/MIP OAM sublayers in connections in the
context of your questions....esp when such nested MEPs/MIPs can be owned
by different parties, as those who think E-NNI peering of different
party owned MPLS-TP networks is a good idea (and to be clear, I don't).
We will have an interesting set of dynamic nodal configurations to deal
with here because the only points of a connection (or indeed a cl-ps
flow) that remain invariant under failures/restores are the end-point
trail (flow) terminations...everything in the middle can change...indeed
we want maximum flexibility (of routing choice) here in order to
optimise availability performance.  So I wonder how is the CP/MP going
to handle this?  Also how do the new nodes (on the restored path) know
that they will need to be capable of being configured with MEPs/MIPs
that may 'belong' to another party from the one who owns the node?  And
to add a little icing on the dynamic nested MEP/MIP
activation/deactivation cake, we would also have to consider how we
would synchronise/correlate any nested performance measurements across
dynamic routing changes.

> Eric >> - Congruently Routed and associated at the Layer Network level
NH=> Not sure what you mean by this.....are you simply meaning 'only
known about in the DP at the trail termination points at the ends of the
connection'?  The CP/MP would have to know what the core nodal routing
was.

> Eric >>   logical construct
NH=> What do mean by 'some logical construct'?  Just trying to
understand your intent here....can you give me an example?

> that associates the two bi-directional
NH=> As I noted previously the CP is only a specialised set of MP
functions....that in some cases benefit from being a distributed rather
than a centralised function.

> Eric >> congruently routed at the layer network (MPLS-TP LSP) level.
NH=> I have no idea what you mean by this.  Can you please expand on
what you mean to help me understand your intent?

> Eric >> I'm not sure what this means.
NH=> It is simply 2 factors:
-	achieving routing congruency at layer N is no assurance of
having routing congruency in layer N-1, etc down to the duct.  It may be
the case that one wants (bottom-of-stack) physical layer failures to
take down both directions at layer N and not just one direction.
-	that the performance experienced by layer N may not be solely a
function of its own design and traffic vectors if the lower layer
networks are anything other than co-cs (and to the duct).

And in a little more detail wrt to the last point:

When we define the required performance behaviour of a layer network
(any) we often make an unconscious assumption about the nature of the
lower layer networks that are in place......and this has certainly been
the case in the past wrt ITU performance HRXs for various technologies
and the partitioned breakdown of their objective allocations.

Now a link connection (== hop) at layer N is formed by a lower level
network connection (if co) or connectionless flow (if cl) at layer N-1.
Similarly a link connection at layer N-1 is formed by a network
connection/flow at layer N-2....and this relationship recurses to the
bottom-of-stack section layer, ie it recurses 'to the duct'.

What this means in practice is that the performance experienced by the
layer N network is not only a function of impairments sourced from
within the layer N nodes (which includes the effects of congestion due
to peaks in layer N traffic load, eg delay, loss) but also impairments
from the layer N link connections which are inherited from *all* the
lower layer network right down to the duct.

Now some impairments are environmental (eg lightning strikes causing
error/loss events) but some impairments are a function of the traffic
load in the layer network being considered (ie delay/loss)....the key
point being that whilst we might have little control over the former
type of impairment (and which are generally rare) we can exercise
control over the impairments due to (variable) traffic load.

Now the party owning the layer N network would normally require that its
performance is independent of the effects of lower level traffic load,
noting that the party owning the layer N network won't be able to
control this if they do not also own these lower layer networks.  An
alternative way to put this, which may be more striking, is to say that
the performance experienced by client X should not be a function of the
traffic behaviour of clients Y, Z, etc (who are also using the services
of the lower layer network).

The only way to ensure that the performance specification of layer N is
a function of its own traffic load and not the traffic load of any lower
layer networks is to require:
-	that all the link connections in layer N are served by
connections (which have a specific definition, principle of which is
that a connection can only have a single source) in layer N-1....this is
a necessary condition;
-	that the resources of the connections in layer N-1 are not
overbooked.....this is a full sufficiency condition. 

These requirements are always assured (ie there is no choice) when the
layer N-1 connections use a co-cs mode technology.....and this is the
unconscious (ie unstated) assumption in all ITU performance HRXs to
date.  These requirements can also be assured by suitable engineering of
a co-ps mode technology at layer N-1.  These requirement however cannot
be assured by a cl-ps mode server layer technology.

And clearly these requirements are recursive through all lower layer
networks to the duct.

Hope that helps.

regards, Neil

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 26 Jan 2009 16:24:44 -0600

Eric >> 

Certainly.

What does it mean to have a bi-directional LSP?  Is this just a 
convenient notion, an interesting concept that we can talk about
all day, or is it important because having such a thing makes it 
possible for something - presumably a client, or higher level 
service to treat this construction as a single entity?

I assume the purpose is the latter and - in fact - know that to 
be the case in at least some important areas.  If I want to treat 
a bi-directional set of whozits (E-G. - LSPs) as a single whatzit
(interface), something needs to perform that mapping.

The question I was trying illustrate was whether this mapping (or
one like it) is present only at the whozit end-points, or at each
node along the path.  

If you assume signaling, the existence of this mapping at each node
(in some cases at least) is implicit in the model where congruency 
is assured on a node-by-node basis.  Similarly, the existence of
such a mapping is implicit at end-points if signaling is used, even
in the case where congruency is assured only by end-points.

In the configuration case, the association is obviously not implicit 
and must therefore be made explicit.
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 26 Jan 2009 16:42:08 -0600

SNAFUd the answer to this one previosuly, see the _real_ answer
at the end...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Eric Gray
Sent: Monday, January 26, 2009 5:25 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] -03 of requirements draft & actions still
toberesolved

Eric >> 

Certainly.

=====================================================================

So, the real answer to this question (for which the above was meant
only to provide context), is:

If there is a construction at each node that maps the node-level
notion of a bi-directional whozit to the same node-level notion of
a single whatzit, there is no particular reason why I cannot use 
that construction at one or more nodes on a path and not at others 
- at least in the configuration case.

At the moment, I cannot think of an advantage to doing this, other
than maybe some cases where doing so at some un-avoidable node may 
make configuration simpler (depending on how much has to be done 
to configure a whatzit at any transit node and whether or not some
form of whatzit - either uni-directional or bi-directional - needs
to be configured at transit nodes), but that doesn't mean it cannot
be done.

---

From: <[email-masked]>
Date: Tue, 27 Jan 2009 00:02:36 -0000

OK thanks Eric....but this still does not make any sense to me wrt to
what you originally wrote, ie

"it is possible to have node-level congruency for an LSP that is not
necessarily 
congruently routed at the layer network (MPLS-TP LSP) level." 

'Layer Network' has a specific meaning (eg see chapter 3 of Reid/Sexton
'BB networking' which has a good introduction to transport network func
arch).  So I cannot understand how a connection that goes though a
specific sequence of nodes and is congruently (bidirectionally) routed
in each node is also not congruently routed at *this layer network*
level.  What you could correctly say is that congruent routing at *this
layer network* level does not imply conguent routing in *lower layer
networks*....which is really where I came in on the performance
inheritance and availability point.  

Couple of further remarks in-line.

> and must therefore be made explicit.
NH=> I'd read this as the act of configuring forwarding tables against
some port. 
> At the moment, I cannot think of an advantage to doing this,
NH=> Which is why I discounted this option originally.  Though I also
feel that we may have slightly different models in our heads as to what
is (or what should be) going on here in (something that is supposed to
be) a transport network.

Don't think this point is worth pursuing further however.  But thanks
for trying to help me understand you.

regards, Neil
 <snipped to end>

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 27 Jan 2009 09:52:20 -0600

Neil,

	I don't think you've quite captured my point, but - as you
say - this isn't worth pursuing further. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 26, 2009 7:03 PM
To: Eric Gray
Cc: [email-masked]
Subject: RE: [mpls-tp] -03 of requirements draft & actions still
toberesolved
Importance: High

regards, Neil
 <snipped to end>

---

From: "Rolf Winter" <[email-masked]>
Date: Thu, 29 Jan 2009 11:45:46 +0100

Ben,

Very detailed set of requirements. I sometimes have the feeling that a bunch of these can be condensed for clarity but I need at least one more pass over the document to make a (good) suggestion.

Some more detailed comments on the requirements draft:

Requirement 4:

I find this requirement odd, after all this is what a standard is for. I know that this is not the situation in the optical space where equipment from different vendors does not get along and similar issues exist in 3GPP, but spelling this out in this way seems odd. Do you think for MPLS-TP this could become an issue as we are aiming for MPLS forwarding compatibility?

Requirement 15:

Why is this SHOULD and not MUST. The requirement itself is written so fuzzily that a MUST seems appropriate.

Requirement 18/46:

Seems rather obvious to me. MPLS-TP needs to be scalable in every aspect. Why reiterating this requirement? There are a number of generally applicable requirements which I think can be omitted or just mentioned in the main text. 

Requirement 33/64/75/90:

Things that "MAY" are not requirements in my opinion and SHOULD not be included. These aspects SHOULD be mentioned in solution drafts.

Requirement 54 c, 55 c:

Are non-requirements in scope of this document? This list could become long but I generally see that in those places they are there for completeness sake, right?

I hope these comments are helpful. 

Best,

	Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> Behalf Of Ben Niven-Jenkins
> Sent: Sonntag, 25. Januar 2009 17:40
> To: [email-masked]
> Subject: [mpls-tp] -03 of requirements draft & actions still to be
> resolved
> 
> Colleagues,
>

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jan 2009 15:11:45 +0100

Ben,

In the document you define 

1) segment as follows:

"Segment: The part of an LSP that traverses a single link or the part
   of a PW that traverses a single link (i.e. that connects a pair of
   adjacent {S|T}-PEs)."

In G.805 terminology, this "segment" would be called "link connection". Is
this correct?
If so, can you add to the document that a "segment" and a "link connection"
are two terms for the same transport entity.

2) concatenated segment as follows:

"Concatenated Segment: A contiguous part of an LSP or mult-segment PW
   that comprises a set of segments in sequence." 

In G.805 terminology, this "concatenated segment" would be called
"serial-compound link connection". Is this correct? If so, can you add to
the document that a "concatenated segment" and a "serial-compound link
connection" are two terms for the same transport entity.

If correct, then the definition of concatenated segment is not complete. It
should include besides the "link connections/segments" also the "matrix
connections" (or more general the "subnetwork connections") which
interconnect two "link connections/segments" in equipment.

3) tandem connection as follows:

"Tandem Connection: A tandem connection is an arbitrary part of a
   transport path that can be monitored (via OAM) independently from the
   end-to-end monitoring (OAM).  It may be a segment, a concatenated
   segment or any other ordered sequence of contiguous links and/or
   segments of a transport path."

The term "links" should not appear in the definition of tandem connection as
a link is a topological component and not a transport entity (tandem
connection is one of the transport entities). It could perhaps be simpler to
state that a Tandem Connection is a Monitored Concatenated Segment (or
Monitored Serial-Compound Link Connection or Monitored SubNetwork
Connection).

In addition, a tandem connection includes besides link connections/segments
also matrix connections/subnetwork connections. If you do not define tandem
connection as a monitored "XXX connection", then it is important to include
the matrix connections as an element within a tandem connection.

4) domain as follows:

"   Domain: A domain represents a collection of entities (for example
   network elements) that are grouped for a particular purpose, examples
   of which are administrative and/or managerial responsibilities, trust
   relationships, addressing schemes, infrastructure capabilities,
   survivability techniques, distributions of control functionality,
   etc.  Examples of such domains include IGP areas and Autonomous
   Systems."

Another example of domain based grouping is access domains between
T-PE/NTU/MTU nodes and first office with S-PE, metro domains between
successive S-PEs located at metro edge (connecting to access domain) and
metro core (connecting to core domain) and core domains between successive
S-PEs located at metro core locations. These domains are characterized by
their tunnels (MPLS-TP Path layer connections); those tunnels terminate at
the domain edges. I propose to add a few words to include those tunnel
connection based domains.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jan 2009 15:34:23 +0100

Ben,

I would like to have the following requirements added to the document:

Section 2.1:

   A   Mechanisms and capabilities MUST be able to interoperate at the
Transport
	 Service Layer, with a minimal gateway function capable to translate
packet/frame
       headers, with existing Ethernet VLAN data planes where appropriate.

   B   MPLS-TP MUST support traffic engineered multipoint to multipoint
(MP2MP) and
       rooted multipoint (RMP) transport paths in its Transport Service
Layer to
	 support E-TREE and E-LAN services. 

   C   MPLS-TP MUST support transport paths at the Transport Service Layer
through
	 multiple heterogenous domains (Ethernet, MPLS-TP).

These requirements make sure that the 'MPLS-TP solution' will be able to: 

- support all service types, including the mp2mp and rmp E-LAN and E-TREE
type services, and

- interoperate in today's multi-technology packet transport network
environment in which Ethernet is significantly present and Service VLANs are
used in the Transport Service Layer within Ethernet domains to support p2p,
p2mp, rmp and mp2mp services.

Complying with those requirements prevents that unnecessary layers will be
present in MPLS-TP domains to support UNI-to-UNI service monitoring. 

Regards,
Maarten

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 30 Jan 2009 14:46:13 -0000

Hi,

I think I agree with Maarten on 1) and 2).
This was the conclusion that Q12/15 came to as we produced RFC 4397.

On item 3) I have always found the term "tandem connection" unhelpful, but 
if we have to retain it, then this definition is not bad. Maybe substitute 
"hops" for "links" which Maarten is right shouldn't be in the definition.

On 4) be careful to avoid attempting an exhaustive list of examples!
You may find the definition of domain in RFC 4726 and RFC 4655 useful.

Cheers,
Adrian

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jan 2009 15:43:21 +0100

Ben,

Can you clarify for me the intention behind data plane requirement 27: "A
transport path's source MUST be identifiable at its destination within its
layer network.". Specifically, to what level this identification is
required?

The label in the data plane represents under fault free conditions the
source-destination information; the specific source and destination
identifiers (the so called "Access Point Identifiers") are hold in the
management plane, not in the data plane however. During fault conditions,
e.g. configuration faults in the network, the label at the destination node
not longer identifies the intended source.

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jan 2009 15:52:20 +0100

Ben,

Can you describe how we should treat "associated unidirectional paths" from
an OAM perspective?

Should such path be treated as two independent unidirectional paths, in
which case there is no Remote Defect/Error Information to exchange between
the two endpoints? Additionally, any tandem connection monitoring will only
be unidirectional as the other direction of such associated unidir paths
will not pass through the same nodes.

Or, should such path still support Remote Defect/Error Information between
the two endpoints of this path?

Note that SNC type protection switching of the 1:1 type will not be able to
work on such associated unidir paths as such protection requires APS signals
to flow over both direction of the path.

Regards,
Maarten

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 30 Jan 2009 16:27:44 +0100

Maarten,

My understanding is that associated unidirectional paths are two
unidirectional paths (treated as unidirectional from OAM, CP and
protection perspective) that are just associated at the end-points.

Italo 

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: Friday, January 30, 2009 3:52 PM
> To: 'Ben Niven-Jenkins'
> Cc: [email-masked]
> Subject: Re: [mpls-tp] -03 of requirements draft & actions 
> still to beresolved
> 
> Ben,
>

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 30 Jan 2009 16:54:10 +0100

Italo,

Thanks for this clarification. 
In this case I would like to ask the question what the application is of
such paths? I.e. when would one want to use such paths, instead of just two
unidirectional paths or of one co-routed bidirectional path.

Regards,
Maarten

-----Original Message-----
From: BUSI ITALO [mailto:[email-masked]] 
Sent: vrijdag 30 januari 2009 16:28
To: Maarten Vissers; Ben Niven-Jenkins
Cc: [email-masked]
Subject: RE: [mpls-tp] -03 of requirements draft & actions still to
beresolved

Maarten,

My understanding is that associated unidirectional paths are two
unidirectional paths (treated as unidirectional from OAM, CP and protection
perspective) that are just associated at the end-points.

Italo 

> Can you describe how we should treat "associated unidirectional paths" 
> from an OAM perspective?
> 
> Should such path be treated as two independent unidirectional paths, 
> in which case there is no Remote Defect/Error Information to exchange 
> between the two endpoints? Additionally, any tandem connection 
> monitoring will only be unidirectional as the other direction of such 
> associated unidir paths will not pass through the same nodes.
> 
> Or, should such path still support Remote Defect/Error Information 
> between the two endpoints of this path?
> 
> Note that SNC type protection switching of the 1:1 type will not be 
> able to work on such associated unidir paths as such protection 
> requires APS signals to flow over both direction of the path.
> 
> Regards,
> Maarten
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 30 Jan 2009 17:12:27 +0100

Boh (dunno)

I would leave to the people supporting this option to clarify the
application: there were quite a few within MEAD.

I do not see any harm in supporting associated unidirectional transport
paths, as long as we keep a clear definition and distinction wrt
bidirectional transport paths.

Italo

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: Friday, January 30, 2009 4:54 PM
> To: BUSI ITALO; 'Ben Niven-Jenkins'
> Cc: [email-masked]
> Subject: RE: [mpls-tp] -03 of requirements draft & actions 
> still to beresolved
> 
> Italo,
>

---

From: "BUSI ITALO" <[email-masked]>
Date: Fri, 30 Jan 2009 16:59:41 +0100

Maarten,

I see the usage of the label to identify the source at the destination
as the solution to meet requirement 27.

The requirement states that the identification is required at the
transport path's layer network. I interpret this as at the LSP layer
network for MPLS-TP LSPs and at the PW layer network for MPLS-TP PWs.

I do not think the requirement mandates to encode the "Access Point
Identifiers" within the packet format.

I wonder whether rephrasing the requirements as proposed below can solve
your comment:

"
Under fault free conditions (i.e. in absense of misconnections), the
transport path's source MUST be identifiable at its destination within
its layer network.
"

Italo

> Sent: Friday, January 30, 2009 3:43 PM
> To: 'Ben Niven-Jenkins'
> Cc: [email-masked]

---

From: "Rolf Winter" <[email-masked]>
Date: Fri, 30 Jan 2009 17:26:17 +0100

Maarten,

According to the current requirements draft, AFAICT, there is only one requirement that explicitly mentions associated unidirectional paths, and that is the requirement to support it. No other requirement, again as far as I can tell, makes an explicit reference to them. I could see that in the management plane, for OAM purposes etc. you might want to retain this notion as there is a coupling implied that simply two unidirectional path do not imply. Once you want to imply it you need a word for this. And currently we are discussing just that.

Cheers,

	Rolf

> Behalf Of BUSI ITALO
> Sent: Freitag, 30. Januar 2009 17:12
> > unidirectional s (treated as unidirectional from OAM, CP
> > and protection

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 30 Jan 2009 16:53:18 +0000

Maarten,

Please remember that the work on MPLS-TP is pulled in two directions
depending on the requirements and strategy of the different participants

1) Those who want to drive additional MPLS-TP functionality to match that of
transport networks to date
2) Those who want to drive additional MPLS-TP functionality to match that of
packet networks to date.

Associated uni-directional paths is how MPLS supports bi-directional
connectivity today ad some participants would like to retain that behaviour
as it is how their network operates today, what their operations are
familiar with etc.

Ben