Subject: Re: [mpls-tp] [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

From: <[email-masked]>
Date: Thu, 5 Mar 2009 11:58:11 -0000

In previous mails to this list I have raised concerns about putting DP
OAM under the GAL, and having had no satisfactory answers to my concerns
I am now formally raising these against the last call on
draft-ietf-mpls-tp-gach-gal:

What is the key problem here?
----------------------------

The DP OAM that is used to detect/handle defects must have exactly the
same header structure as normal MPLS-TP DP traffic.  Moreover, there
should be clear separation of CP/MP protocols and MPLS-TP DP
traffic/OAM.  This means:
-	MPLS-TP DP OAM must not appear under the GAL
-	the GAL should only be used for CP/MP protocols

Further, although we do not yet have a formal proposal for the
incorporation of the PID function in the MPLS-TP traffic DP header
(though draft-bryant-pwe3-packet-pw would seem to setting itself up as
the prime candidate for this), we need to have the 'OAM indicate' flag
as part of the MPLS-TP traffic DP header (this could for example be a
specific 'OAM indicate' PID value).

Other comments on the draft:
---------------------------

1	Many types of DP OAM are mentioned in the draft (eg in the
Introduction).  The main problem with having lots of different types of
defect detection/handling DP OAM in the same network is that we cannot
predict a priori what sort of misconnectivity problems will occur.
Therefore it will be problem if the trail termination point of an
MPLS-TP LSP is expecting DP OAM of type X, but due to a misconnectivity
defect it receives a different DP OAM of type Y.  In general a given
layer network (any mode/technology, not just MPLS-TP) should use the
same type of DP OAM for defect detection/handling in all cases.  Perhaps
this issue needs to be formally captured in either
draft-ietf-mpls-tp-oam-requirements or draft-ietf-mpls-tp-requirements?

2	In section 2.1 it says:

"Note that for PWs, the PWE3 control word [6] MUST be present in the
encapsulation of user packets when the ACH is used to realize the
associated control channel"

Whilst this is true/understood for the case of MPLS as-is today due to
the use of ECMP (requiring the special treatment of the 1st nibble of
the payload), in MPLS-TP we have to remove all the conditions that gave
rise to PWs in MPLS, one of which is ECMP....if we do not do this then
MPLS-TP cannot be considered to be a transport network.  So in MPLS-TP
not only is there no need for PWs because all client must be treated
equally (and in particular we must not allow the creation of another
co-ps 'PW layer network' above MPLS-TP) there is no technical
justification for the CW either.  We might keep the CW under the
pretence that is providing an adaptation function, but things like the
1st nibble ECMP mitigation and sequence numbers have no role in MPLS-TP
if it is to assume a transparent transport network role (where one of
the key properties of transparency is that client symbol ordering must
be preserved, so CW sequence numbers have no role here).

Further, since the GAL acts a clear indicator that the G-ACh and CP/MP
protocols follow this also means the CW is not required to differentiate
DP traffic/OAM from CP/MP protocols. 

Now although the MPLS-TP team do not seem to have defined/agreed what
the client DP traffic header should be, as noted above it would seem
like draft-bryant-pwe3-packet-pw is setting itself up as the prime
candidate for this role.  If so, then there needs to be some good
technical explanation somewhere (eg in draft-ietf-mpls-tp-requirements
say) for why the CW has to be present in MPLS-TP LSPs.  Currently I can
see no good technical arguments for this as noted above.  So could
someone please explain the technical reason for retaining the CW in the
MPLS-TP DP please?

3	In section 4 it says:

   "The GAL provides an alert based exception mechanism to:

   o  differentiate specific packets (e.g. maintenance messages) from
      others, such as normal user-plane ones,

   o  indicate that the ACH appears immediately after the bottom of the
      label stack.

   The GAL MUST only be used where both of these purposes apply."

but in section 4.2 it says:

   "In MPLS-TP, the GAL MUST always be at the bottom of the label stack
   (i.e.  S bit set to 1).  However, in other MPLS environments, this
   document places no restrictions on where the GAL may appear within
   the label stack.

   The GAL MUST NOT appear in the label stack when transporting normal
   user-plane packets.  Furthermore, when present, the GAL MUST only
   appear once in the label stack."

and in section 4.2.1.1 it says (for a multiple hop sublayered LSP):

    "The S bit of the GAL MUST be set according to its position in the
     label stack."

and in section 4.2.1.2 it says (for a single hop non-sublayered LSP):

    "o  The S bit of the GAL MUST be set according to its position in
the
      label stack.  For MPLS Sections, the S bit MUST be set to 1."

Now I find all this rather confusing and it would be helpful if the
authors could explain why the GAL might possibly exist in a position
other than the BOS labelled header entry....though as noted above, for
the section 4.2 extract, it does state that for MPLS-TP the GAL can only
appear at the BOS position.  If we restrict the GAL to a clear logically
OOB CP/MP role as I strongly believe we should, then the GAL will indeed
only ever appear as a BOS labelled header entry (is S=1 always in the
GAL).

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: 24 February 2009 10:25
> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; ITU-T ad hoc team on MPLS-TP; George Swallow; 
> Ross Callon; David Ward; Malcolm Betts; VIGOUREUX MARTIN
> Subject: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
> 
> All,
> 
> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal
> has been published.
> 
> The draft is found at:
> 
> http://tools.ietf.org/html/draft-ietf-mpls-tp-gach-gal-02
> 
> Since the updates are significant this is to initiate a 2 week
> working group last call on the new version.
> 
> Please send your comments to the [email-masked] mailing list.
> 
> The working group last call will end on March 11.
> 
> /Loa
> -- 
> 
> 
> Loa Andersson
> 
> Sr Strategy and Standards Manager
> Ericsson ///                          phone:  +46 8 632 77 14
> 
>                                        email:  
> [email-masked]
>                                                
> [email-masked]
>                                                [email-masked]
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: "BOCCI Matthew" <[email-masked]>
Date: Thu, 5 Mar 2009 13:33:58 +0100

Neil, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 05 March 2009 11:58
> To: [email-masked]
> Subject: Re: [mpls-tp] [PWE3] 2nd wg last call on 
> draft-ietf-mpls-tp-gach-gal
> 
> In previous mails to this list I have raised concerns about 
> putting DP OAM under the GAL, and having had no satisfactory 
> answers to my concerns I am now formally raising these 
> against the last call on
> The DP OAM that is used to detect/handle defects must have 
> exactly the same header structure as normal MPLS-TP DP 
> traffic.  Moreover, there should be clear separation of CP/MP 
> protocols and MPLS-TP DP traffic/OAM.  This means:

Thanks very much for your comments on the applicability of the GAL. 

It's never going to be exactly the same as you always need some way of
demultiplexing OAM on the LSP/PW, so what we need is a mechanism that
allows OAM to fate-share along the path of the LSP/PW and that meets the
MPLS-TP OAM requirements, but that is also useful for MPLS in general
and that works with the current MPLS forwarding rules. 

You raise a couple of issues previously regarding the validity of using
a GAL to indicate the presence of OAM packets on  an MPLS-TP LSP. The
first is that the extra label means that the label stack is different
from or larger than normal user packets. In some cases you could argue
that adding an extra 32 bits to a packet is an issue for e.g. PM.
However, please remember that this is a packet network with a wide
distribution of packet sizes, and one in which the OAM packet size is
not related to the user packet size anyway, so I do not think that the
additional 32bits is significant. 

The second issue I think you raised, was regarding the different
processing with an extra label. The processing at the end points will
differ between OAM and other packets irrespective of what indication
mechanism is used, so I do not see how moving the alert mechanism into a
bit in an PID on the payload helps so long as fate sharing is achieved
along the path of the LSP. ECMP processing of the label is not relevant
here, since ECMP is disabled by default on an MPLS-TP LSP.  Indeed, if
you are suggesting using a bit in the CW from Stewart's packet PW draft,
are you not implying that all MPLS-TP LSPs should be PWs (or vice
versa)?

> 
> Further, although we do not yet have a formal proposal for 
> the incorporation of the PID function in the MPLS-TP traffic 
> DP header (though draft-bryant-pwe3-packet-pw would seem to 
> setting itself up as the prime candidate for this), we need 
> to have the 'OAM indicate' flag as part of the MPLS-TP 
> traffic DP header (this could for example be a specific 'OAM 
> indicate' PID value).
> 
> 
> Introduction).  The main problem with having lots of 
> different types of defect detection/handling DP OAM in the 
> same network is that we cannot predict a priori what sort of 
> misconnectivity problems will occur.
> Therefore it will be problem if the trail termination point 
> of an MPLS-TP LSP is expecting DP OAM of type X, but due to a 
> misconnectivity defect it receives a different DP OAM of type 
> Y.  In general a given layer network (any mode/technology, 
> not just MPLS-TP) should use the same type of DP OAM for 
> defect detection/handling in all cases.  Perhaps this issue 
> needs to be formally captured in either 

Thanks. I agree with you that it only makes sense to have one
mis-connectivity defect detection/handling mechanism operating at a
given layer. There are some rules in section 5 the draft regarding what
to do if you receive OAM of a type that you have not agreed to, but the
negotiation of which set of OAM mechanisms is out of scope. I agree with
you that it needs to be captured somewhere (the OAM requirements draft
is probably the right place) that only one mechanism of the same type
should be used at any given time, and it probably needs to be the same
across all LSPs/PWs in a given network.
 
> "Note that for PWs, the PWE3 control word [6] MUST be present 
> in the encapsulation of user packets when the ACH is used to 
> realize the associated control channel"
> 
> Whilst this is true/understood for the case of MPLS as-is 
> today due to the use of ECMP (requiring the special treatment 
> of the 1st nibble of the payload), in MPLS-TP we have to 
> remove all the conditions that gave rise to PWs in MPLS, one 
> of which is ECMP....if we do not do this then MPLS-TP cannot 
> be considered to be a transport network.  So in MPLS-TP not 
> only is there no need for PWs because all client must be 
> treated equally (and in particular we must not allow the 
> creation of another co-ps 'PW layer network' above MPLS-TP) 
> there is no technical justification for the CW either.  We 
> might keep the CW under the pretence that is providing an 
> adaptation function, but things like the 1st nibble ECMP 
> mitigation and sequence numbers have no role in MPLS-TP if it 
> is to assume a transparent transport network role (where one 
> of the key properties of transparency is that client symbol 
> ordering must be preserved, so CW sequence numbers have no role here).
> 
> Further, since the GAL acts a clear indicator that the G-ACh 
> and CP/MP protocols follow this also means the CW is not 
> required to differentiate DP traffic/OAM from CP/MP protocols. 
> 
> Now although the MPLS-TP team do not seem to have 
> defined/agreed what the client DP traffic header should be, 
> as noted above it would seem like draft-bryant-pwe3-packet-pw 
> is setting itself up as the prime candidate for this role.  
> If so, then there needs to be some good technical explanation 
> somewhere (eg in draft-ietf-mpls-tp-requirements
> say) for why the CW has to be present in MPLS-TP LSPs.  
> Currently I can see no good technical arguments for this as 
> noted above.  So could someone please explain the technical 
> reason for retaining the CW in the MPLS-TP DP please?

We want to avoid a complete redesign of MPLS/PWE3 and have a set of
tools that work for both MPLS-TP and MPLS in general. 

>     "o  The S bit of the GAL MUST be set according to its 
> position in the
> Now I find all this rather confusing and it would be helpful 
> if the authors could explain why the GAL might possibly exist 
> in a position other than the BOS labelled header 
> entry....though as noted above, for the section 4.2 extract, 
> it does state that for MPLS-TP the GAL can only appear at the 
> BOS position.  If we restrict the GAL to a clear logically 
> OOB CP/MP role as I strongly believe we should, then the GAL 
> will indeed only ever appear as a BOS labelled header entry 
> (is S=1 always in the GAL).

This is for non-TP MPLS networks where e.g hash labels might be used. I
agree it needs a sentence or two to explain this better.

Cheers

Matthew

> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Loa Andersson
> > [email-masked]; ITU-T ad hoc team on MPLS-TP; George Swallow; Ross 
> > Callon; David Ward; Malcolm Betts; VIGOUREUX MARTIN
> has been 
> > published.
> > Since the updates are significant this is to initiate a 2 
> week working 
> > group last call on the new version.
> > 
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 05 Mar 2009 14:02:36 +0000

Neil

SB> A first comment here. If you have alternative candidate
SB> designs it would be most helpful if you submitted them
SB> in the early stages of design as internet drafts, and
SB> argued for their acceptance by the community.
SB> 
SB> A second comment that would be most helpful to the
SB> authors and the chairs would be for others to comment
SB> on the validity of Neil's views so that we know
SB> what changes to the draft represent the consensus of
SB> the group.

The DP OAM that is used to detect/handle defects must have exactly the
same header structure as normal MPLS-TP DP traffic.

SB> In a network that is not doing ECMP - as is the case in
SB> MPLS-TP the requirements is that the structure is identical
SB> up to the point where equipment makes a data/OAM decision
SB> In TP this is the necessary and sufficient criteria for
SB> fate sharing.

Moreover, there

SB> You need to explain why it is not satisfactory to
SB> discriminate within the not-data multiplexer.
SB> In the design the delivery labels are the same for
SB> data and everything else. Then the data is distinguished
SB> from everything else. Then the OAM is distinguished from
SB> CP/MP.
SB> 

SB> That is not at all clear provided we fate share in
SB> the delivery system

SB> What is the agenda here? I hope that it is not to do per hop DPI
SB> to identify OAM, because that will burn cost/performance, and
SB> C/P is the key CSF for XPORT

defect it receives a different DP OAM of type Y.

SB> Given that the OAM is all self describing it will know if it
SB> has X or Y

In general a given

SB> This draft describes a mechanism that allows us to build a
SB> tool suite. If only one type of OAM gets qualified for MPLS-TP
SB> then we only need to build one mechanism. That does not mean
SB> that we should not design a general purpose discrimination
SB> mechanism.

justification for the CW either.

SB> CW is mandatory for some PW types
SB> CW is optional in all the rest.
SB> CW is the defined way of discrimination between DP and OAM
SB> for inband OAM in PWE3
SB> It seems more consistent to always require it than to require
SB> it on a case by case basis.

We might keep the CW under the

SB> No one want to turn SN on, but they are a way of verifying
SB> pkt order if needed. An example of where misordering could
SB> creep in is if what you thought was a wire provided by a third
SB> party tuned out to be PW/MPLS or even PW/L2TP.

SB> Again we have a major issue with the way that you are assuming
SB> DP and OAM are one group

candidate for this role.

SB> Actually the prime candidate is a PW of the same type as
SB> the attachment circuit.

If so, then there needs to be some good

SB> Reuse of the existing method of carrying attachment circuits
SB> over MPLS.

3    In section 4 it says:

appear at the BOS position.

SB> For MPLS-TP we currently see no circumstances why the GAL should
SB> be anywhere other than BOS. However we are designing a general
SB> purpose mechanism and wanted to give future designers the
SB> ability to use this tool for other purposes. We have no other
SB> purpose in mind, but such flexibility is always useful.

 If we restrict the GAL to a clear logically
OOB CP/MP role as I strongly believe we should, then the GAL will indeed
only ever appear as a BOS labelled header entry (is S=1 always in the
GAL).

SB> We should ask the MPLS chairs whether they would prefer that
SB> we leave the option open, of restrict GAL to BOS and require
SB> then to write an update to this draft (RFC) as an when they
SB> identify a need to place the it other than at BOS.

Regards

Stewart

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 16:12:17 -0000

Thank you Stewart,
 
> SB> argued for their acceptance by the community.

NH=> I was perhaps naively expecting that important issues like changes
made to the DP (eg inclusion of PID and how OAM indicate would be
handled) was what the MEAD team were supposed to be discussing.  Clearly
I was wrong.

> SB> what changes to the draft represent the consensus of

NH=> I agree.  But can I please ask we stick to the technical accuracy
of my observations.
> What is the key problem here?

NH=> Well, I have to disagree with you here Stewart.  I cannot
understand how we can be happy to make a major change to the DP by
adding a PID function and then fail to get the DP OAM correct.  This
does not make much sense to me, especially when there is no technical
reason whatsover to compromise this.

> SB> from everything else. Then the OAM is distinguished from

NH=> If the traffic header is N labels deep the OAM header is N+1 labels
deep.  Things like the S bit take on different values.  To be pedantic
here, the OAM proposed in this draft will test the GAL channel not the
traffic channel.  I seem to recall hearing cases of RSVP-TE saying an
LSP was 'up' when the DP was indeed failed...yet they fate shared on
lower layers.

It makes perfect sense to want the headers of OAM and traffic to be
identical...I mean why would you want to get this wrong when there is no
technical reason to?

Moreover, I think the onus is actually on other to explain why they
would be quite prepared to add a major change like a PID function to the
DP and then not be prepared to add an OAM function in here....this makes
no technical sense whatsover to me.

> SB> That is not at all clear provided we fate share in

NH=> Well, I am not over-impressed by all the arguments of fate
sharing....we also need within-layer identical node processing (re the
RSVP example above).  I am not at all clear why we would not get this
right (ie a clean seperation of CP/MP and DP functions) when there is no
technical reason not to.

> SB> C/P is the key CSF for XPORT

NH=> I have no hidden agenda at all....what I say is alwways what I
believe is correct technically.  And BTW DPI is something a transport
network *must not* do....recall the definition of transparency (because
if MPLS-TP is not transparent then it is not a transport network):
-	all client symbols treated equally
-	client symbol ordering preserved
-	no attempt made to infer the meaning of, or modify, the client
symbols
-	the traffic behaviour of client X should not impact the
performance experienced by client Y.

> different types of

NH=> I am not sure you get my point here by your comment.  Unless you
mean that all LSP trail termination points must be able to understand
any type of OAM it receives due to a miconnectivity defect.  If this is
what you mean then I think this would not be a sensible thing to do.
Defect detection/handling needs to consistent within a layer
network....indeed this is nothing specific to MPLS-TP, this applies to
any mode/technology.
 
> SB> that we should not design a general purpose discrimination

NH=>  I would recommend you make a very clear distinction between (i)
OAM used to detect/handle defects and (ii) OAM used to diagnose defects.
They are quite different and we want the former to be consistent (across
the network) and as simple/sparse as possible.
> SB> it on a case by case basis.

NH=> But Stewart, as unpalatable as it might be, we have to be
technically objective and face the facts here.  PWs are simply not
necessary in MPLS-TP...in fact if MPLS-TP has PWs then it will have
failed IMO in its objective.  PWs are only a symptom of certain things
that were done in MPLS.....and for MPLS-TP to assume a transport network
role we have to fix these things.  I can see no technical reason to have
the CW in MPLS-TP.  More crucially however, we simply cannot allow it
spawn another co-ps mode network above MPLS-TP, and so it must revert
back to an adaptation role.  But when we examine it as an adaptation
function we find it is not a good adaptation function.

If the MEAD team are doing a good job they should have considered GFP
here.  This is a good adaptation function and it is already the standard
adaptation function used by all current transport networks.  GFP also
has a PID function.  This should have at least been looked at by the
MEAD team and, if rejected, reasons given for its rejection.

> SB> pkt order if needed.

NH=> A transport network has to provide a transparent service to its
clients.  Preservation of client symbol ordering is an essential
requirement of a transport network.  We do not need Seq Nos in an
adaptation function for a transport network.

> An example of where misordering could

NH=> Quite...these are not transport networks....and they must never
claim to be such.  You are also now straying into another point I have
previously discussed about the importance of performance inheritance,
and why it is important to understand what you are getting down to the
duct.
> SB> DP and OAM are one group

NH=> And indeed DP traffic and DP defect detection/handling OAM are.  If
you think they are not they we are not providing a good design IMO.  And
what I find most disturbing about this is that there is no technical
reason not to get this right.  As I noted above, I am amazed we are
happy to add a major change like adding a PID to the DP but yet cannot
add a simple OAM indicate in here...I do find this very baffling.

> SB> the attachment circuit.

NH=> In the case of MPLS-TPoverMPLS-TP the attachment circuit, as you
call it, should be a simple p2p *lower server* layer network for
connecting a client MPLS-TP node to a server node.  If MPLS-TP is going
to be of any use as a transport network then it had better terminate the
'attachment circuit' between the client and server nodes...and it for
sure must not mandate that it goes end-end across a server MPLS-TP layer
network.  We need total flexibility in the technology of the 'attachment
circuit', and there should be no restrictions of what type of
'attachment circuit' can connect client and server layer networks.
> Currently I can

NH=> I am getting very confused and somewhat worried now wrt what you
think MPLS-TP needs to be and what I believe it must be if it is to be a
transport network.  We should (IMO must) be able to connect the node of
a client MPLS-TP to the node of a server MPLS-TP layer network using any
technology we like...and they can be different at either end.  This is
all about what a *client/server* relationship is and what *transparency*
means....both crucial points to any technology claiming to offer a
transport service to its clients.
> SB> be anywhere other than BOS.

NH=> I agree...which is why I raised this point.

> However we are designing a general

NH=> I also agree....but I also like being architecturally
correct/consistent when there is no need not get things right....and
this too also helps mitigate the design against unforseen future
problems.
	
> will indeed

NH=> But please remember we are designing MPLS-TP here.  And it will,
like it or not, be a different layer network to what MPLS as-is.  For
from the MPLS-TP perspective I believe we must only have the GAL as a
BOS entry, and as I have previously said, I would recommend this *only*
be used with CP/MP protocols in order to have a very clean architectural
separation.

Thanks for your comments Stewart,  regards, Neil

---

From: <[email-masked]>
Date: Thu, 5 Mar 2009 18:20:50 -0000

Thanks Matthew.....I responded to Stewart's comments on this earlier
today, hope you saw that.....so I apologise for repeating some of the
same arguments again below.

Have snipped this a bit.

> and that works with the current MPLS forwarding rules.

NH=> Firstly, let be very clear about what MPLS-TP needs to be if it is
to assume a transport role:
-	it has no need of PWs at all....in fact this is almost essential
by definition of what it is supposed to be achieving.  So we can remove
PWs from the MPLS-TP agenda.
-	it will form a different layer network to any of the types of
MPLS that exist today.....might not be so obvious to everyone, but it is
a fact
-	MPLS-TP must provide a transparent (see definition in response
to Stewart) client/server service to its clients.

So whilst we may re-use some of the components from MPLS we will not use
all of them and we will introduce new ones.

> additional 32bits is significant. 

NH=> This is not my point at all.  In my response to Stewart I was
making the observation that if we are prepared to make a very
significant change to the MPLS-TP DP by adding a PID function, as we
must, then it would be amazingly foolish of us not to get the DP OAM
right too....it only requires a very simple flag/indicate function here.
The technical fact is that the OAM required for
defect/detection/handling belongs to the DP, and if one can get this
right then one should get this right.  There is no technical excuse for
a poor design decision here IMO.

> are you not implying that all MPLS-TP LSPs should be PWs (or vice

NH=> Very glad you brought this point up.  As I noted above there can be
no PWs in MPLS-TP...because, as a transparent transport network, we are
going to treat all clients equally.  Indeed, we are forced to remove the
conditions that created PWs in MPLS in the 1st place...we have to, else
we won't be able to make MPLS-TP a transport network.  If you want to
call all clients PWs then OK, but this is just applying a name that is
not really appropriate....I'd just call the constructs MPLS-TP LSPs,
because they will be the same for all clients.  We don't need the CW, it
is hardly a good adaptation function.  If doing a thorough job the
design team should look at GFP, even if rejected...though technical
reasons for rejection should be clear....because this is what all
current *transport networks* use, and it already has a PID function
built-in.

<snipped> 
> given layer.

NH=> Thanks.  This is of course a quite general point for any layer
network mode/technology.  What I specifically want to avoid here is the
requirement for a MPLS-TP trail termination point to have to able to
handle any type of OAM structure we can (in principle) generate.  We
cannot know a priori what LSP source may become connected to what LSP
sink under defect conditions (and if you think about this, this is why
MPLS as-is now is not singular....an MPLS traffic unit only has context
wrt to the signalling agent that generated it ....and this is why you
will have heard me say in the past that even if we have non-consistent
charactersitic information of the DP traffic units, we really ought to
make sure the DP OAM is the same for all cases).  If we don't ensure
this we will just create a problem/cost that is not really necessary.
The DP defect detection/handling OAM  needs to be consistent and as
simple/sparse as we can make it.

<snipped>
> tools that work for both MPLS-TP and MPLS in general.
 
NH=> I have no problems with that aim....re-using *well designed*
CP/CP/MP components is a very good thing, eg re-use the CCAMPS GMPLS CP
components.  However, please note that MPLS-TP will create a disjoint
layer network to other spins of MPLS (eg MPLS-TP DP traffic units will
have a PID function that is not found in MPLS traffic units), so claims
of 'backwards compatibility' wrt peer interworking them have no
technical basis here....at least if we want to do a good job on MPLS-TP.
> agree it needs a sentence or two to explain this better.

NH=> If we apply good architectural design rules from the outset we can
mitigate problems that might arise downstream.  That is why:
-	I want DP OAM to be recognised *that it is DP* and needs to
look/feel/smell like normal DP traffic units
-	I want the CP/MP protocols kept cleanly seperated for the DP
traffic/OAM.

Not a lot to ask really IMO.  Why get it wrong now when there is no need
to?

regards, Neil

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 6 Mar 2009 14:00:00 +0000

I think this document is ready to progress forward.

	--Tom

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 06 Mar 2009 16:42:00 +0000

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without significant
changes to their existing support infrastructures.

Ben

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 8 Mar 2009 22:34:04 +0100

Agreed.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
ext Ben Niven-Jenkins
Sent: Friday, March 06, 2009 18:42
To: Thomas Nadeau; Loa Andersson
Cc: George Swallow; [email-masked]; ITU-T ad hoc team on MPLS-TP;
[email-masked]; [email-masked]; [email-masked]; David Ward; Malcolm
Betts; VIGOUREUX MARTIN
Subject: Re: [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without
significant
changes to their existing support infrastructures.

Ben

---

From: "BUSI ITALO" <[email-masked]>
Date: Tue, 10 Mar 2009 20:40:37 +0100

In attachment my LC comments.

They are minor comments, therefore I support this document moving
forward.

I also propose that ITU-T supports the document moving forward in the
reply to the IETF LS that was asking for ITU-T comments.

Italo

> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Tuesday, February 24, 2009 11:25 AM
> Subject: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal
> 
> All,
>

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 11 Mar 2009 08:59:32 +0100

Hej Loa,

> Please send your comments to the [email-masked] mailing list.

I have no further comments, I support approval.

Cheers, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 22:40:08 +0100

Support. 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Loa Andersson
Gesendet: Dienstag, 24. Februar 2009 11:25
An: [email-masked]; [email-masked]; [email-masked]; [email-masked]; ITU-T ad hoc team on MPLS-TP; George Swallow; Ross Callon; David Ward; Malcolm Betts; VIGOUREUX MARTIN
Betreff: [mpls-tp] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

All,

The draft is found at:

/Loa
-- 

Loa Andersson

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

---

From: "Luyuan Fang (lufang)" <[email-masked]>
Date: Thu, 12 Mar 2009 13:51:59 -0400

Agreed.
Luyuan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ben Niven-Jenkins
Sent: 06 March 2009 11:42
To: Thomas Nadeau; Loa Andersson
Cc: [email-masked]; ITU-T ad hoc team on MPLS-TP; [email-masked];
[email-masked]; [email-masked]; David Ward; Malcolm Betts; VIGOUREUX
MARTIN
Subject: Re: [mpls] [PWE3] 2nd wg last call on
draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to
MPLS-TP from their existing deployed MPLS & PW services without
significant changes to their existing support infrastructures.

Ben

On 06/03/2009 14:00, "Thomas Nadeau" <[email-masked]> wrote:

>> an updated version (-02) of the draft-ietf-mpls-tp-gach-gal has been 
>> published.
>> 
>> The draft is found at:
>> 

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

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Fri, 13 Mar 2009 09:31:20 +0100

Agreed
Annamaria 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luyuan Fang (lufang)
Sent: giovedì 12 marzo 2009 18.52
To: Ben Niven-Jenkins; Thomas Nadeau; Loa Andersson
Cc: [email-masked]; ITU-T ad hoc team on MPLS-TP; [email-masked]; [email-masked]; [email-masked]; David Ward; Malcolm Betts; VIGOUREUX MARTIN
Subject: Re: [PWE3] [mpls] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

Agreed.
Luyuan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: 06 March 2009 11:42
To: Thomas Nadeau; Loa Andersson
Cc: [email-masked]; ITU-T ad hoc team on MPLS-TP; [email-masked]; [email-masked]; [email-masked]; David Ward; Malcolm Betts; VIGOUREUX MARTIN
Subject: Re: [mpls] [PWE3] 2nd wg last call on draft-ietf-mpls-tp-gach-gal

Agreed.

It addresses a need and provides a solution for operators evolving to MPLS-TP from their existing deployed MPLS & PW services without significant changes to their existing support infrastructures.

Ben