Subject: [PWE3] Re: progress of G.8113 and G.8114

From: Stewart Bryant <[email-masked]>
Date: Wed, 19 Dec 2007 15:55:06 +0000

Huub

The change that you propose is a fundamental change
to the whole rational for designing an OAM specifically
for T-MPLS rather than reusing an existing pseudowire
OAM design.

It has always been asserted by the T-MPLS designers
that T-MPLS has special failure modes that did not
apply to PWE3/MPLS and therefore existing OAM
mechanisms such as RFC5085 (VCCV) were not appropriate.
When challenged to specify these, none have been provided
and now it is proposed to answer this long outstanding
AAP issue by changing the language to indicate that
there are no special T-MPLS failure modes.

This change to the requirements demonstrates that
the fundamental technical basis for rejecting the
IETF OAM methods was flawed, and this decision therefore
needs to be revisited.

G.8113 and G.8114 should now be put on hold whilst the
implications of this are properly evaluated.

The least that you should do is to change the text
of the requirement to

"T-MPLS provides a connection-oriented layer network and hence
there will be failure modes that are only relevant to
the T-MPLS layer. Detection of these failure modes is possible
through the use of RFC5085"

and then to add RFC5085 as a candidate solution in G.8114 using
the text that has already been provided.

However designing a second OAM for pseudowire is not in the
best interests of the operator community and it would be better
to abandon this approach and to bring any additional
requirements to the IETF for incorporation in VCCV.

Stewart

Huub van Helvoort wrote:
> Hello Steward,
>
> Thank you for helping me.
>
> You wrote:
>
>>> Unfortunately there are still comments that are not resolved.
>>> Are there any other proposals that will help to resolve the
>>> open issues and get G.8113 and G.8114 approved. 
>> Just looking at the first unresolved comment, you could list
>> the failure modes that apply to T-MPLS but not to MPLS
>> as requested in the issue.
>>
>> Alternatively you could state that there are no failure
>> modes that apply to T-MPLS that do not apply to
>> one or more MPLS modes.
>
> Your comment made me read the original text very carefully, and
> I found that the sentence:
>
> "T-MPLS provides a connection-oriented layer network and hence
> there will be failure modes that are only relevant to T-MPLS."
>
> is the cause of your question.
> It should have been:
> "T-MPLS provides a connection-oriented layer network and hence
> there will be failure modes that are only relevant to
> the T-MPLS layer."
>
> I will make this change to resolve this issue.
>
> Cheers, Huub.
>

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

---

From: <[email-masked]>
Date: Wed, 19 Dec 2007 17:45:25 -0000

Guys,

Think we need to be a little more precise here.  PWs may have started
life as some form of adaptation, primarily to deal with the fact that
MPLS does not treat all its clients the same (and some problems are
exposed when attempting to use ECMP techniques because of this), but PWs
are now developing into a full blown layer network in their own right.
More specifcally we cannot say that the functional components of MPLS
are the same as those of PWs.  And if we take the PW OAM component then
this runs in a muxed-in channel with the control-word.  Trying to be
even more accurate, what we have in the case of PWs (and only PWs, ie
does not apply to MPLS) is the emergence of a PID field occuring in the
first nibble after the PW labelled header...and it is this field (when
it takes on the value 0001) that indicates 'PW OAM'

So, to put this more succintly:  MPLS OAM != PW OAM.

If this is not clear, then consider the effect of misconnectivity beween
a LSP carrying a PW and a 'normal' MPLS LSP.  And to be super accurate
here, we should also note that the CI (Characteristic Information) of
the traffic unit in the 2 cases  is not the same in other respects, eg
the 'normal' label of an MPLS LSP is a proxy for a destination address
(ie forwarding semantic) whilst the label of a PW LSP is a proxy for a
source adddress (ie a demerging semantic....necessary if LDP is being
used). 

T-MPLS OAM is something else all together.  So we can extend to say:
MPLS OAM != PW OAM != T-MPLS OAM.

Then there is the issue of PWs over T-MPLS....so what do we have here?

Think some clarity is required in being precise as to *which* layer
network one is talking about when discussing the OAM.

Hope you can understand the points I'm making here.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of J. Rao Cherukuri
> Sent: 19 December 2007 16:52
> To: [email-masked]; Huub van Helvoort
> Cc: Q5/13; [email-masked]; pwe3
> Subject: RE: progress of G.8113 and G.8114
> 
> 
> Stewart,
> 
> I agree with your proposed suggestion. This is inline with 
> one of the Juniper AAP comment not yet resolved.
> 
> Regards
> Rao Cherukuri 
> 
> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Wednesday, December 19, 2007 10:55 AM
> To: Huub van Helvoort
> Cc: Q5/13; [email-masked]; pwe3
> Subject: Re: progress of G.8113 and G.8114
> 
> 
> 
> Huub
> 
> "T-MPLS provides a connection-oriented layer network and 
> hence there will be failure modes that are only relevant to 
> the T-MPLS layer. Detection of these failure modes is 
> possible through the use of RFC5085"
> 
> and then to add RFC5085 as a candidate solution in G.8114 
> using the text that has already been provided.
> 
> best interests of the operator community and it would be 
> better to abandon this approach and to bring any additional 
> >>> Unfortunately there are still comments that are not resolved. Are 
> >>> there any other proposals that will help to resolve the 
> open issues 
> >> Just looking at the first unresolved comment, you could list the 
> >> failure modes that apply to T-MPLS but not to MPLS as requested in 
> >> the issue.
> >>
> >> Alternatively you could state that there are no failure modes that 
> >> apply to T-MPLS that do not apply to one or more MPLS modes.
> >
> > Your comment made me read the original text very carefully, and I 
> > found that the sentence:
> >
> > "T-MPLS provides a connection-oriented layer network and 
> hence there 
> > will be failure modes that are only relevant to T-MPLS."
> >
> > "T-MPLS provides a connection-oriented layer network and 
> hence there 
> > will be failure modes that are only relevant to the T-MPLS layer."
> >

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 19 Dec 2007 13:36:21 -0500

> So, to put this more succintly:  MPLS OAM != PW OAM.

Agreed.

> MPLS OAM != PW OAM != T-MPLS OAM.

I am not sure I follow your argument here.

> Hope you can understand the points I'm making here.

	Partially. *)

	--Tom

---

From: <[email-masked]>
Date: Wed, 19 Dec 2007 19:09:18 -0000

Thanks Tom...please see in-line:

Thomas Nadeau wrote 19 December 2007 18:36
> > does not apply to MPLS) is the emergence of a PID field 
> occuring in  
> > the
NH=> All I am saying here is that, for whatever reason, the authors of
T-MPLS decided to generate a new form of OAM that does not have its
roots in MPLS nor PW.  Indeed T-MPLS was predicated on what had gone
before for Ethernet (in Y.1731)......which is clearly not the same as
MPLS OAM or PW OAM.  Moreover, the fact that Ethernet is cl-ps and
T-MPLS is co-ps seems to be dismissed as a 'minor issue'.....but not in
my mind it isn't.
> > Hope you can understand the points I'm making here.
NH=> Hope the above explanation helps.  The key points are this:
-	if one creates a layer network (any mode) it will have its own
OAM;
-	several technologies can belong to the same network mode but
they might not have the same OAM....or other func components for that
matter....that is largely an issue of which body specified the
technology (some are done better than others);
	technologies that do NOT belong to same network mode will have a
mismatch in func components....just the way it is (physics)....so trying
to force one component (eg OAM) to fit all modes is very silly.

regards, Neil
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of J. Rao Cherukuri
> and now it 
> >> is proposed to answer this long outstanding AAP issue by 
> changing the 
> >> language to indicate that there are no special T-MPLS 
> failure modes.
> >>
> needs to be 
> >> revisited.
> >> will be failure modes that are only relevant to the T-MPLS layer. 
> >> Detection of these failure modes is possible through the use of 
> >> RFC5085"
> >>
> >> However designing a second OAM for pseudowire is not in the best 
> >> interests of the operator community and it would be better 
> to abandon 
> >> this approach and to bring any additional requirements to the IETF 
> >> for incorporation in VCCV.
> >>
> >> Stewart
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Huub van Helvoort wrote:
> >>> Hello Steward,
> >>>
> modes that

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 19 Dec 2007 20:52:31 +0100

Hi Stewart,

> for T-MPLS rather than reusing an existing pseudowire

[hvh] This is NOT a fundamental change, it is a clarification because I
detected a mis-interpretation.
T-MPLS is developed by SG15, SG15 uses layered network models, hence
T-MPLS is one of the layer technologies they develop. And reference
to T-MPLS implies the T-MPLS layer, to make sure that everybody
understands that I made the correction.

> mechanisms such as RFC5085 (VCCV) were not appropriate.

[hvh] Indeed. The failure modes of T-MPLS are related to the transport
functionality and based on the experience with other transport
technologies.

> there are no special T-MPLS failure modes.

[hvh] Then you are still mis-interpreting the sentence, It is stating
that the failure modes are confined to the T-MPLS layer.
(and this is a generic requirement for layered transport networks).

What the failure modes are is out of scope for these recommendations,
that is the responsability of the equipment specification G.8121.

> IETF OAM methods was flawed, and this decision therefore

[hvh] Again, there is NO change, it is a correction to avoid
mis-interpretation. (as is clear from your comment)

> implications of this are properly evaluated.

[hvh] There are NO implications that need to be re-evaluated.

> through the use of RFC5085"

[hvh] the addition of the last sentence restricts the requirement by
providing a solution, solutions are out of scope for G.8113.

> the text that has already been provided.

[hvh] this is a technical change beyond what can be addressed by
AAP comments.

> requirements to the IETF for incorporation in VCCV.

[hvh] there was already a response from an operator confirming that the
correction I propose is in line with transport technology.

Reagrds, Huub.

>================================= 
> Huub van Helvoort wrote:
>> Hello Steward,
>>

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 19 Dec 2007 15:03:33 -0500

On Dec 19, 2007, at 2:09 PM, <[email-masked]> wrote:

> roots in MPLS nor PW.

	True!

> Indeed T-MPLS was predicated on what had gone

	OK.  My confusion was in thinking that T-MPLS <= MPLS. If it is defined
in this way, then the PW OAM + MPLS OAM will work just fine. BUT if T- 
MPLS > MPLS,
then you are right, you get some strange variant.

	--Tom

---

From: <[email-masked]>
Date: Thu, 20 Dec 2007 09:13:51 -0000

Thanks Tom,

Let me try and see if I can help a bit further here with this
observation you made:

> My confusion was in thinking that T-MPLS <= MPLS. 
> If it is defined in this way, then the PW OAM + MPLS OAM will 
> work just fine. BUT if T- 
> MPLS > MPLS,

If one understands what is becoming increasingly clear from the work on
unified modelling, there is a deeper physics (with its roots in
Information Theory) to the way in which networks are forced to be
created......this is all about how one carves-up space, freq or time
resource partitions and labels them (so that multiple users of the
network resource can be distinguished and, where appropriate/required,
allocated adequate resource).  Indeed, this is precisely why we see the
3 network modes of cl-ps, co-ps and co-cs in the real world.

One of the biggest mistakes we can make is to assume that one
mode/technology can do-it-all.  A related mistake is to assume that we
can impose the same/identical set of functional components on all the
modes.  If I look to the IETF for example, they have been wrestling for
many years now with the notion of forcing a common CP on networks (IP to
Optics).....but it won't work (for many reasons, and not just technical
ones).  And in relation to this topic, some folks in ITU hold the
mistaken view that we can have a common type of OAM component in all
modes/technologies.....this too is just plain wrong.

As a general observation the 3 network modes arise, and are different,
for very good reasons (of physics)....so folks should stop trying to
unify them, and instead seek ways of optimally specifying them so that
their unique/different properties can be optimally exploited when the 3
modes work in concert.  There is a better way...we have all just not
seen it yet.

So that is the general framework.  Now let's consider the co-ps mode.
*In principle* there is a best-of-breed solution here (in terms of DP
traffic unit structure and selection of DP/CP/MP components).  So far
however, as an industry, we have not been able to create this beast.
And the reason for this is that each co-ps technology (examples being
X.25, FR, ATM, MPLS, T-MPLS, PBB-TE) has been designed by folks with a
specific set of goals in mind.....they did not design these technologies
with the principles of unified modelling in mind (though to be strictly
accurate PBB-TE was conceived with these principles strongly in mind).

So it is no surprise to find that the DP addressing, the traffic unit
structure, the higher 'message/file/stream application to 1st layer
adaptations' and OAM (and indeed all the CP and MP components) are all
somewhat different for each of these co-ps mode technologies.  And no
one really baulks when we observe that they form different co-ps layer
networks....we can intuitively see they are 'different' (and by design).

Now in the case of MPLS and T-MPLS we can observe that they start with
the same DP traffic unit.  And so there is a tendency to jump to the
conclusion that 'they should be the same, or at least as closely
harmonised as possible'....but this does not follow.  One can have a
completely different set of functional components applied to T-MPLS from
those applied to MPLS (DP, CP and MP).  Is this a good thing?  Well, it
depends on whether you consider the functional components of MPLS or
T-MPLS to be 'better'.  If I am brutally honest here I would say that
from an objective appraisal of each technology's components neither is
very good...when compared to what the ideal co-ps mode should look like.
Now I'm not going to provide such an analysis here...it is not
appropriate.

However, I think folks are currently talking past each other.
Bottom-line:  There is no need for T-MPLS to look the same as
MPLS.....indeed, there is no such thing as 'MPLS singular'....and
although different spins of MPLS may share the same DP traffic unit they
do diverge quite significantly thereafter (in CP components, OAM, label
semantics).  

So it is wrong to claim that T-MPLS is subset of MPLS *if* there are
conscious decisions being made to have quite different functional
components and behaviours....here OAM is the component at issue, but as
I've tried to show its a more complex issue that just this.  They may
start with the same DP traffic unit but thereafter one can diverge as
much as one chooses.

Hope that helped.

regards, Neil

> From: Thomas Nadeau [mailto:[email-masked]] 
> Sent: 19 December 2007 20:04
> To: Harrison,N,Neil,DMN R
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [PWE3] RE: progress of G.8113 and G.8114
> 
> 
> 
> >>> exposed when attempting to use ECMP techniques because of 
> this), but 
> >>> PWs are now developing into a full blown layer network in their
> >> own right.
> >>> are the same as those of PWs.  And if we take the PW OAM 
> component 
> >>> then this runs in a muxed-in channel with the 
> control-word.  Trying 
> >>> to be even more accurate, what we have in the case of PWs (and
> >> only PWs, ie
> >>> If this is not clear, then consider the effect of misconnectivity 
> >>> beween a LSP carrying a PW and a 'normal' MPLS LSP.  And to be
> >> super accurate
> 	OK.  My confusion was in thinking that T-MPLS <= MPLS. 
> If it is defined in this way, then the PW OAM + MPLS OAM will 
> work just fine. BUT if T- 
> MPLS > MPLS,
> for T-MPLS 
> >>>> rather than reusing an existing pseudowire OAM design.
> >>>>
> >>>> mechanisms such as RFC5085 (VCCV) were not appropriate. When 
> >>>> challenged to specify these, none have been provided
> >> and now it

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 20 Dec 2007 10:36:13 +0000

> understands that I made the correction.
SB>The original text said
SB>
SB>The major motivations for T-MPLS OAM are discussed further below.
SB>1) T-MPLS provides a unique connection-oriented layer network and hence
SB>there will be failure modes that are only relevant to T-MPLS
SB>
SB>Are there failure modes that apply to T-MPLS but do not apply
SB>to PWE3/MPLS?
> functionality and based on the experience with other transport
SB> Either T-MPLS is a subset (i.e. profile ) of PWE3/MPLS or it is not.
SB> If it is, then the failure modes ought to be the failure modes that
SB> you get in PWE3 over connection oriented MPLS. If there are
SB> other failure modes then please list them. If you are unable to
SB> list them, then we have to conclude that there are none.
SB>
SB> On the other hand you may assert that T-MPLS is not a subset of
SB> PWE3/MPLS. In which case you have two choices:
SB> Bring the requirements to the IETF and use the MPLS change
SB> process to enhance PWE3/MPLS, or take Option2.
SB>

> that is the responsability of the equipment specification G.8121.

SB> This is supposed to be the requirements document. How can
SB> the failure modes be out of scope?
SB> If they are in G.8121, then please provide the section
SB> references and add them to G.8113.

> mis-interpretation. (as is clear from your comment)
SB> I disagree.
> [hvh] There are NO implications that need to be re-evaluated.
SB> Again I disagree
> providing a solution, solutions are out of scope for G.8113.
SB> The scope of G.8113 is the surely the OAM requirements
SB> for a profile of PWE3/MPLS. How can the use of IETF
SB> OAMs be out of scope?
SB>
SB> The only way that they can be out of scope is either:
SB>
SB> a) If the scope of G.8113 is to create an OAM that is different
SB> from the IETF OAMs, or
SB>
SB> b) T-MPLS is not a profile of PWE3/MPLS.
> [hvh] this is a technical change beyond what can be addressed by
SB> In which case the document should be pulled out of AAP and
SB> corrected.
> correction I propose is in line with transport technology.
SB> Firstly one responder is not consensus, and so cannot be used
SB> to claim closure of the issue.
SB>
SB> Secondly I believe that same operator suggested that T-MPLS != MPLS
SB> in which case, if you follow that line, you are into option 2.

Stewart
>
> Reagrds, Huub.
>
>> ================================= Huub van Helvoort wrote:
>>> Hello Steward,
>>>

---

From: "J. Rao Cherukuri" <[email-masked]>
Date: Wed, 19 Dec 2007 08:52:10 -0800

Stewart,

I agree with your proposed suggestion. This is inline with one of the
Juniper AAP comment not yet resolved.

Regards
Rao Cherukuri 

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Wednesday, December 19, 2007 10:55 AM
To: Huub van Helvoort
Cc: Q5/13; [email-masked]; pwe3
Subject: Re: progress of G.8113 and G.8114

Huub

Stewart

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 20 Dec 2007 17:26:19 +0100

Hello Stewart,

> SB>Are there failure modes that apply to T-MPLS but do not apply

[hvh2] the word "unique" was removed and agreed by LC2-1 a).
The last word "T-MPLS" has to be replaced by "the T-MPLS layer"
because it causes confusion.
It is a generic transport network requirement that failuire modes
applicable to a certain layer shall be confined to that particular
layer. Different layers can have the same, or totally different,
or partially different, or partially equivalent failure modes.

> SB> process to enhance PWE3/MPLS, or take Option2.

[hvh2} The following is extracted from the Q5/13 meeting report
(SG13 plenary meeting April 2007):
"The Q5/13 experts spent a significant amount of time considering
the IETF specified MPLS OAM for inclusion and concluded that thes
cannot be used in the way they are currently defined. Understanding
and, if necessary, adapting the current IETF definitions to match
the Y.17tom OAM functions described in clauses 7, 8 and 9 will
require close cooperation with IETF. Q5/13 is willing to work
together with the IETF experts to resolve the issues.  Input by
contribution for the next meeting is invited."

This text was reviewed and accepted without objection.

> SB> references and add them to G.8113.

[hvh2] the OAM requiremnts are intended to be used to develop OAM
mechanisms. The equipemt specification wil refer to the OAM mechnisms
that are used by specific (adaptation/termination/connection) functions.

Both G.8113 and G.8114 were liaised to Q9/15 for commnets. The reponse
liaison (TD 196 wp4/13) states that G.8114 contains a comprehensive set
of T-MPLS OAM PDUs. There were no objections in the SG15 meeting to
send this liaison.

>> mis-interpretation. (as is clear from your comment)

[hvh2] this change is to improve the quality, this is not a
technological change.

> SB> b) T-MPLS is not a profile of PWE3/MPLS.

[hvh2] during the evaluation (as mentioned above) they do not
comply with the generic transport requirement that they should
be confined to a single layer.

> SB> In which case the document should be pulled out of AAP and

[hvh2] what you propose is not a correction, it is an addition.
additions can be made after a recommendation has been approved.

> SB> in which case, if you follow that line, you are into option 2.

[hvh2] I read someting else:

"Think we need to be a little more precise here"
"MPLS OAM != PW OAM != T-MPLS OAM"
"Think some clarity is required in being precise as to
*which* layer network one is talking about when discussing the OAM

The suggestion is:
The OAMs are not equal because they are confined to their own layer.

Regards, Huub.

---

From: Monique Morrow <[email-masked]>
Date: Thu, 20 Dec 2007 06:07:53 -0800

Huub,

> correction I propose is in line with transport technology.

I am unsure whether or not I saw a confirmation from an operator to this
effect.  I have seen dialogue from an operator but NOT a confirmation
therein.

Could please point out specifically where there is actually a confirmation?

Regards,

Monique