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

From: Monique Morrow <[email-masked]>
Date: Fri, 04 Jan 2008 03:39:43 -0800

Huub,

Firstly a a very Happy New Year to you!

Could you please expand specifically where RFC 5085 does not apply?

Why for example  RFC 5085 is not considered as a candidate solution for
G.8114 given the technical changes that are currently being discussed for
y.1374?

Also, to the assertion that T-MPLS OAM is defined in y.1711 <2002>,

"6.2.1.1            T-MPLS OAM

T-MPLS OAM is specified in [ITU-T Y.1711]. Figure 6-13 illustrates the set
of T-MPLS OAM and their format. "

I may have missed a reference to TMPLS OAM in y.1711-- where specifically in
y.1711 is there such a specific reference to TMPLS OAM?

Thanks always!

monique

On 12/19/07 11:52 AM, "Huub van Helvoort" <[email-masked]> wrote:

> Hi Stewart,
> 
> See my repondse to your reply in-line [hvh]:
> 
>> 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.
> 
> [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.
> 
>> 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.
> 
> [hvh] Indeed. The failure modes of T-MPLS are related to the transport
> functionality and based on the experience with other transport
> technologies.
> 
>> 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.
> 
> [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.
> 
>> 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.
> 
> [hvh] Again, there is NO change, it is a correction to avoid
> mis-interpretation. (as is clear from your comment)
> 
>> G.8113 and G.8114 should now be put on hold whilst the
>> implications of this are properly evaluated.
> 
> [hvh] There are NO implications that need to be re-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"
> 
> [hvh] the addition of the last sentence restricts the requirement by
> providing a solution, solutions are out of scope for G.8113.
> 
>> and then to add RFC5085 as a candidate solution in G.8114 using
>> the text that has already been provided.
> 
> [hvh] this is a technical change beyond what can be addressed by
> AAP comments.
> 
>> 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.
> 
> [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,
>>> 
>>> 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: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 12:29:21 +0000

Huub van Helvoort wrote:
> Hello Stewart,
> You replied:
>> 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?
>
> [hvh2] the word "unique" was removed and agreed by LC2-1 a).
SB> Sorry, I do not recall seeing an agreement. Please can you point to me
SB> to the email thread where consensus on that was achieved?
SB>
SB> The important point point is that this word was in the requirements
SB> when certain critical design decisions were made. As a native
SB> English speaker, I would take this to mean that there are
SB> failure modes that only apply to T-MPLS, therefore I need
SB> new OAM functionality. Now we have agreed that this is
SB> not the case and that there are no failure modes present
SB> in T-MPLS that are not also present in PWE3/MPLS
SB> we need to revisit the consequences.
> 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> I am not sure how you confine failure modes to a layer. Say
SB> you run T-MPLS/T-MPLS/...., how do you prevent failures
SB> at one layer from being observed at the higher layers?
>>> functionality and based on the experience with other transport
SB> .... and failure modes in PWE3/MPLS are related to packet functionality
SB> and are based on many year of deployment experience with packet
SB> technology.
>> 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.
>
> [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."
SB> Unfortunately you did not follow through on this. As you
SB> are aware the correct approach was to submit a requirements
SB> draft into the MPLS change process, and use the IETF
SB> process to modify IETF MPLS technology.
SB>
>
> This text was reviewed and accepted without objection.
SB> I need to ask those present to confirm that.
>> 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.
>
> [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.
>
>> SB> I disagree.
> [hvh2] this change is to improve the quality, this is not a
> technological change.
SB> On the contrary. It previously stated that there were elements of
SB> the T-MPLS design that had failure modes that were not present
SB> in other similar packet technologies. Now it says that the
SB> failure modes are identical.
>> SB> Again I disagree
>> 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.
>
> [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> Please explain to me the technical basis for that conclusion.
>> SB> In which case the document should be pulled out of AAP and
>> SB> corrected.
>
> [hvh2] what you propose is not a correction, it is an addition.
> additions can be made after a recommendation has been approved.
SB> There are many changes that have been proposed for these documents
SB> after approval. I do not see what is special about this on. Indeed
SB> it is a simplification because it says that instead of designing
SB> lots of new technology, you can also use existing deployed
SB> technology to the same effect.
>> 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.
>
> [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.
>
SB> On the one hand you tell me T-MPLS <= PWE3/MPLS, and then
SB> you tell me that PWE3/MPLS is different and therefore the OAM is
SB> not suitable.
SB>
SB> A very simple yes/no question - T-MPLS a subset of PWE3/MPLS or not?

Regards

Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 4 Jan 2008 15:42:33 +0100

Monique,

RFC 5085 defines only tools that can run over IP.

One of the main requirements for T-MPLS is to be able to run the network without
IP.

Therefore RFC 5085 is not in line with one of the main requirements for T-MPLS.

Italo

> -----Original Message-----
> From: Monique Morrow [mailto:[email-masked]] 
> Sent: Friday, January 04, 2008 12:40 PM
> To: Huub van Helvoort
> Cc: Q5/13; [email-masked]; pwe3; [email-masked]
> Subject: [PWE3] Re: progress of G.8113 and G.8114
> 
> Huub,
>

---

From: Monique Morrow <[email-masked]>
Date: Fri, 04 Jan 2008 06:53:53 -0800

Italo,

Thanks again for your quick response.

Please explain why IP cannot be used or perhaps where in y.1373 this
requirement is specifically stated?  <I may have missed it in the draft
recommendation itself>.

Thanks.

Monique

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 15:06:39 +0000

> RFC 5085 defines only tools that can run over IP.
No, it can be statically configured to carry IP-free BFD (for example)
> One of the main requirements for T-MPLS is to be able to run the network without
a) Interestingly I can't see that requirement in G.8113. Can you point 
to it?
b) Why is that a requirement?
c) Doesn't G.8114 actually call up IP as an address as one of the 
addressing formats?
> Therefore RFC 5085 is not in line with one of the main requirements for T-MPLS.
No Italo - we fixed all that so that we could comply with the no-IP
requirement as part of our work on the MPLS transport draft - and
if you had used the MPLS change process we would have fixed
it earlier.

Stewart
>>> [hvh] This is NOT a fundamental change, it is a 
>>>       
>> clarification because I
>>     
>>> [hvh] Indeed. The failure modes of T-MPLS are related to 
>>>       
>> the transport
>>     
>>> [hvh] Then you are still mis-interpreting the sentence, It 
>>>       
>> is stating
>>     
>>> What the failure modes are is out of scope for these 
>>>       
>> recommendations,
>>     
>>> [hvh] there was already a response from an operator 
>>>       
>> confirming that the
>>

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 4 Jan 2008 16:07:34 +0100

See clause 8 of Y.1372:
"
13)	The functionality of T-MPLS OAM should not be dependent on any specific
server or client layer network. This is architecturally critical to ensure that
layer networks can evolve without impacting other layer networks

14)	The functionality of T-MPLS OAM should be sufficiently independent of
any specific control plane such that any changes in the control plane do not
impose changes in user-plane OAM (including the case of no control plane). Like
the previous requirement, this is also architecturally critical to ensure that
user-plane and control-plane protocols can evolve without impacting each other.
" 

ITU-T has always communicated in the last two years that this is the one of the
main requirements for MPLS in transport networks.

Italo

> Sent: Friday, January 04, 2008 3:54 PM
> To: Italo Busi; 'Huub van Helvoort'
> Cc: 'Q5/13'; [email-masked]; 'pwe3'; [email-masked]
> Subject: Re: [PWE3] Re: progress of G.8113 and G.8114
> 
> Italo,
> 
> > One of the main requirements for T-MPLS is to be able to 
> run the network
> > without
> > IP.
> > 
> > Therefore RFC 5085 is not in line with one of the main 
> requirements for
> > T-MPLS.
> > 
> > Italo
> >

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 15:15:56 +0000

> layer networks can evolve without impacting other layer networks
Carrying IP encoded OAM messages over the OAM channel says nothing about
the client or the server layer - it just says how the OAM info is encoded.

> user-plane and control-plane protocols can evolve without impacting each other.
Again I do not see that there is a conflict here.

You can run foo traffic over TMPLS over bar PSN with CLNS as the control 
protocol
and STILL use IP as the encoding for OAM.

However not withstanding the above - you can run foo' over RFC5085 and 
it will
still work.

Stewart
>>>> On 12/19/07 11:52 AM, "Huub van Helvoort" 
>>>>         
>> <[email-masked]> wrote:
>>     
>>>>> Hi Stewart,
>>>>>
>>>>> T-MPLS is developed by SG15, SG15 uses layered network 
>>>>>           
>> models, hence
>>     
>>>>> T-MPLS is one of the layer technologies they develop. And 
>>>>>           
>> reference
>>     
>>>>> (and this is a generic requirement for layered transport 
>>>>>           
>> networks).
>>     
>>>>> [hvh] the addition of the last sentence restricts the 
>>>>>           
>> requirement by
>>

---

From: Monique Morrow <[email-masked]>
Date: Fri, 04 Jan 2008 07:18:49 -0800

Italo,

I do NOT see anything specific that asserts suppression of  IP in this
Clause as per your previous comment; and fail to understand technically why
there is a conflict here.

Regards,

Monique

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 15:19:22 +0000

> layer networks can evolve without impacting other layer networks
Oh and I forgot to mention, that statement  does not endorse inventing a 
new PSN type -
"label 14 transport" - which is what seems to be happening.

Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 4 Jan 2008 16:23:18 +0100

> From: Stewart Bryant [mailto:[email-masked]] 
> Sent: Friday, January 04, 2008 4:07 PM
> To: Italo Busi
> Cc: 'Monique Morrow'; 'Huub van Helvoort'; 'Q5/13'; 
> [email-masked]; 'pwe3'

[ib] I cannot find this option in RFC 5085 but only in other I-Ds

> run the network without
> requirements for T-MPLS.

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 4 Jan 2008 16:27:24 +0100

> Sent: Friday, January 04, 2008 4:16 PM
> To: Italo Busi

It requires to support another technology (i.e. IP) in addition to T-MPLS.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 15:41:28 +0000

> [ib] I cannot find this option in RFC 5085 but only in other I-Ds

10.  Security Considerations

   Routers that implement VCCV create a Control Channel (CC) associated
   with a pseudowire.  This control channel can be signaled (e.g., using
   LDP or L2TPv3 depending on the PWE3) or statically configured.  

>> c) Doesn't G.8114 actually call up IP as an address as one of the 

You omitted to answer the above.

Stewart

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 4 Jan 2008 16:56:43 +0100

> Sent: Friday, January 04, 2008 4:41 PM
> To: Italo Busi

[ib] Yes but there is no definition of IP-free BFD

> >> a) Interestingly I can't see that requirement in G.8113. Can 

[ib] I am answering in another thread

> >> b) Why is that a requirement?

[ib] I need some time to prepare a clear answer to this question. However this
requirement must not be new because it has been communicated by ITU-T for the
last two years

> >> c) Doesn't G.8114 actually call up IP as an address as one of the 

[ib] Yes and I was originally against it. The reasons why I removed my
opposition were:

1) this is just an identifier and does not require to implement an IP protocol
stack

2) this is an option (not the only way to assign such an identifier) that could
be used typically if an IP address is available (if not, you can avoid to use
it)

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 16:34:33 +0000

Italo Busi wrote:
>>> 13)	The functionality of T-MPLS OAM should not be dependent 
>>>       
>> on any specific
>>     
>>> server or client layer network. This is architecturally 
>>>       
>> critical to ensure that
>>     
So it's better to invent a whole new technology that hardly anyone 
understands
and has not been completed, than it is to reuse a tiny element from the most
successful, and the most well known, communications technology in 
history - hm?

At the level that you need IP to make this work it is little more than 
an encoding,
and I have yet to see any good technical reason for this reinvention of 
the wheel.

Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 4 Jan 2008 11:45:05 -0500

> RFC 5085 defines only tools that can run over IP.

	Why we need to continue wasting time trying to split hairs is beyond  
me.

	RFC5085 defines a control channel for use wherever pseudowires
are used. If the PW is configured statically (i.e.: without a control  
plane),
then VCCV can still run just fine.  This is in fact, explicitly  
spelled out
in a number of sections within the document.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 4 Jan 2008 11:47:44 -0500

> user-plane and control-plane protocols can evolve without impacting  

	Yes, and RFC5085 (and the subsequent BFD+VCCV document) explain how
such a tool exists for either the case where a control plane is used  
or if
one is not. That seems to cover all the cases, no?

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 4 Jan 2008 11:50:22 -0500

> It requires to support another technology (i.e. IP) in addition to T- 

	Please read the draft. The draft explains clearly how to use BFD + VCCV
*without* the IP headers.  Running the BFD state machine within VCCV  
is not really
"supporting IP" at that point.

	--Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 4 Jan 2008 11:51:18 -0500

> [ib] Yes but there is no definition of IP-free BFD

draft-ietf-pwe3-vccv-bfd-00.txt

---

From: Monique Morrow <[email-masked]>
Date: Fri, 04 Jan 2008 09:00:25 -0800

> requirement must not be new because it has been communicated by ITU-T for the

Thanks again for your quick response but I do not see specifically where
suppression of IP has been a requirement in the ITU-T <if anything I see the
opposite>, and why technically.

Further, it seems now that in addition to statically provisioning a path,
e.g. Say TMPLS  that the direction ultimately is to use GMPLS for dynamic
path signalling, correct?

Ciao,

Monique

---

From: "Italo Busi" <[email-masked]>
Date: Fri, 4 Jan 2008 18:02:29 +0100

> From: Thomas Nadeau [mailto:[email-masked]] 
> Sent: Friday, January 04, 2008 5:51 PM
> To: Italo Busi
> Cc: 'Monique Morrow'; [email-masked]; 'pwe3'; 'Q5/13'; 
> [email-masked]

[ib] This confirms my original reply ("I cannot find this option in RFC 5085 but
only in other I-Ds"). Are you proposing RFC 5085 or
draft-ietf-pwe3-vccv-bfd-00.txt?

> > requirement must not be new because it has been 
> communicated by ITU- 
> > T for the
> > last two years
> >
> > 2) this is an option (not the only way to assign such an 
> identifier)  
> > that could

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 17:10:24 +0000

A couple of comments from a college:

>13 The functionality of T-MPLS OAM should not be dependent 
>on any specific
>critical to ensure that layer networks can evolve without 
>impacting other layer networks

This is of course the GMPLS model; viz, each layer may have
ts own instance of the GMPLs control plane, and each control 
plane instance may have different functionality.  The fact that
the same protocols are re-used in multiple layers is due to a number of
pragmatic considerations detailed in:
http://tools.ietf.org/html/draft-awduche-mpls-te-optical-02

Similarly, instances of RFC 5085 can be implemented in multiple layer
networks independently.

With regard to the more extensive reuse of IEFT protocols 
and IP in particular. The very reason that MPLS was a 
success, and you are therefore using it here, is that it
reused the IP protocol suite rather than inventing
a new one.

Thus for both consistency with MPLS and to maximize
the probability of success for this protocol, it should
re-use the IP protocol suite.

Stewart

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 4 Jan 2008 09:12:05 -0800

>From: Italo Busi [mailto:[email-masked]] 
>Sent: Friday, January 04, 2008 7:57 AM
>To: [email-masked]
>Cc: 'Monique Morrow'; [email-masked]; 'pwe3'; 'Q5/13'
>Subject: RE: [PWE3] Re: progress of G.8113 and G.8114
>
> 
>

JD:  The requirements you quoted do not equate to 'IP-free'.  They
merely indicated that each layer network needs to be self-sufficient and
not dependent upon other layer networks. 

>> >> a) Interestingly I can't see that requirement in G.8113. Can you 
>> >> point to it?
>
>[ib] I need some time to prepare a clear answer to this 
>question. However this requirement must not be new because it 
>has been communicated by ITU-T for the last two years
>
>[ib] Yes and I was originally against it. The reasons why I 
>removed my opposition were:
>
>1) this is just an identifier and does not require to 
>implement an IP protocol stack
>
>identifier) that could be used typically if an IP address is 
>available (if not, you can avoid to use
>it)
>
>> 
>> >> if you had used the MPLS change process we would have fixed it 
>> >> earlier.
>> >>     
>> 
>> Stewart
>> 
>> >> Stewart
>> >>     
>> >>> Italo
>> >>>
>> >>>   
>> >>>       
>> >>>> G.8114 given the technical changes that are currently being 
>> >>>> discussed for y.1374?
>> >>>>
>> >>>> T-MPLS OAM is specified in [ITU-T Y.1711]. Figure 6-13 
>> >>>> illustrates the set of T-MPLS OAM and their format. "
>> >>>>
>> >>>>>> 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.
>> >>>>>>         
>> >>>>>>             
>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.
>> >>>>>>         
>> >>>>>>             
>> >>>>>> The least that you should do is to change the text of the 
>> >>>>>> requirement to
>> >>>>>>
>> >>>>>> there will be failure modes that are only relevant to the 
>> >>>>>> T-MPLS layer. Detection of these failure modes is possible 
>> >>>>>> ================================= Huub van Helvoort wrote:
>> >>>>>>         
>> >>>>>>             
>> >>>>>>> Hello Steward,
>> >>>>>>>
>> >>>>>>>> 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.
>> >>>>>>>>             
>> >>>>>>>>                 
>> >>>>>>> there will be failure modes that are only relevant to the 
>> >>>>>>> T-MPLS layer."
>> >>>>>>>

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 04 Jan 2008 18:18:48 +0100

Hello Stewart,

See inline answers: [hvh3]

> SB> to the email thread where consensus on that was achieved?

[hvh3] This agreement was reached between the editor and the
[hvh3] commenter in the first step of the AAP.

> SB> when certain critical design decisions were made.

[hvh3] And the meaning of that word was fully comprehended by
[hvh3] the designers of G.8114 and the reviewers in Q9/15 and Q12/15.

> SB> As a native
> SB> new OAM functionality.

[hvh3] And I explained several times that it means that the
[hvh3] failure modes are confined to the T-MPLS *layer*.

> SB> Now we have agreed that this is

[hvh3] As a native Dutch speaker I can interpret *present*
[hvh3] in two ways:
[hvh3] =1= that they are defined in both technologies
[hvh3]     this is possible, there is a lot of *re-use*
[hvh3] =2= that they co-exist at the same time in two layers.
[hvh3]     this could be possible, e.g. if a physical link is
[hvh3]     broken the physical layer will be in the signal fail
[hvh3]     mode, the layers above will be in server layer failure
[hvh3]     mode. If in one layer a connectivity error exists then
[hvh3]     the layers above will have a server layer failure mode
[hvh3]     and the layers below can be faultless.

> SB> at one layer from being observed at the higher layers?

[hvh3] as I have tried to explain above in =2=
[hvh3] the server layer failure mode can have different
[hvh3] consequent actions, depending on the technilogy.

> SB> and are based on many year of deployment experience with packet

[hvh3] .... and the transport functionality uses the layered network
[hvh3] model and operators require that new technologies conform to
[hvh3] this. It is a requirement that exists since SDH was started.

> SB> process to modify IETF MPLS technology.

[hvh3] the invitation for contributions still stands.
[hvh3] there was no contribution in the previous plenary
[hvh3] requesting the approach you mention.

> SB> failure modes are identical.

[hvh3] see above

> SB> Please explain to me the technical basis for that conclusion.

[hvh3] this was discussed by a break-out group and reported
[hvh3] in the Q5/13 meeting with all participants of the break-out
[hvh3] group present.

> SB> you tell me that PWE3/MPLS is different and therefore the OAM is

[hvh3] you are mixing again layering and technologies

Regards, Huub.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 17:25:31 +0000

Italo
> [ib] Yes but there is no definition of IP-free BFD
However unlike some of the outstanding issues with G.8114, we do
understand the technical design and are confident that there are no
technical show-stoppers.
> requirement must not be new because it has been communicated by ITU-T for the
It would be really useful for you to explain the technical rational 
here. After all
as soon as you move to a GMPLS control plane you are going to need IP.
> 1) this is just an identifier and does not require to implement an IP protocol
Though I fail to see what the big deal in implementing it is. It is 
available for every OS
and does not take much memory.
> be used typically if an IP address is available (if not, you can avoid to use

This sounds a very thin argument from a group that is trying to move to
IETF technology.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jan 2008 17:38:37 +0000

Huub
> [hvh3] in the Q5/13 meeting with all participants of the break-out
I was not at that meeting, nor were many of the people subscribed
to the lists that this is being discussed on.

So that we can make progress, please summarize the technical
reasons for this decision.

Thank you

Stewart

---

From: David Ward <[email-masked]>
Date: Tue, 8 Jan 2008 10:24:25 -0600

Maarten -

inline

On Jan 8, 2008, at 9:11 AM, VISSERS Maarten wrote:

> Stewart,
>
> WD09r2 from the April 2007 SG13 meeting
> (http://ties.itu.int/u/tsg13/sg13/xchange/wp4/q5/0704_Geneva/wd09R2- 
> tmpl
> s-oam-y17tom(mpls-consid)-02.ppt) presents an analysis of the use  
> of BFD
> within T-MPLS networks and concludes that BFD is not capable to  
> meet the
> requirements.
>

DW: Has this been liased to the IETF, sent to the BFD WG, WG chairs  
or authors? Note that I don't have access to the above referenced ppt.

> As far as the participants understood the BFD specification, use of  
> BFD
> within T-MPLS instead of use of CV would have introduced a security  
> risk
> in T-MPLS networks.
>

DW: I'll bite. How so? I don't see this point mentioned anywhere else  
in the thread nor have I ever received any information on this topic.  
Also, none is on the BFD WG email list.

> Furthermore, one of the requirements of T-MPLS OAM is to be backward
> compatible with G.8112 defined T-MPLS OAM and G.8121 (03/2006)  
> specified
> T-MPLS trail termination (TM_TT) functions. Use of BFD does not  
> provide
> this backward compatibility, while the TM_TT function in G.8121
> (03/2006) does not support BFD.
>

DW: This point is not a BFD issue as no extensions have been requested.

> Please review WD09r2:
> - slides 3/4 present the T-MPLS atomic functions and the allocation of
> T-MPLS OAM to these functions for both the initial G.8112 and the
> extended G.8114 (Y.17tom) based T-MPLS OAM
>
> - slide 5 illustrates the connectivity check mechanism when a TM_TT
> function (version 1) or TM_TT function (version 2) is misconnected  
> with
> a version 2 TM_TT function. Version 1 TM_TT generates CVv0 OAM and is
> able to receive CVv0 and CVv1 OAM. Version 2 TM_TT function generates
> CVv1 OAM and is able to receive CVv0 and CVv1 OAM.
>
> - slide 6 illustrates the T-MPLS atomic functions of slide 3 with its
> T-MPLS OAM extended with label14-BFD OAM. The assumption was that the
> deployment of BFD in T-MPLS would need to make use of the same OAM
> header (i.e. label14) as the other T-MPLS OAM defined in G.8112.
>
> - slide 7 illustrates the connectivity check mechanism like in slide 5
> and identifies some issue:
> 	1) if BFD would be used, then CVv0 must still be present to be
> backward compatible with G.8112/G.8121. As a result you would have to
> generate two connectivity check OAM frames: CVv0 and BFD.
> 	2) BFD contains a MyDiscriminator/YourDiscriminator field which
> could be used as replacement of the MEGID/MEPID. Slide 16 presents  
> some
> text of bfd-base-06 in which these fields are defined as a "field for
> demultiplexing received BFD packets to the proper session". I.e. these
> fields a not meant to be used as MEGID/MEPID, these fields are used  
> as a
> demultiplexing label. In T-MPLS the demultiplexing label is a label
> field in the label stack entry header of the frame (including in  
> the OAM
> frames). The MyDiscriminator/YourDiscriminator fields are an  
> unnecessary
> duplicate of the main label field. The conclusion was therefore  
> that the
> absence of BFD can be used to represent the Loss of Continuity (LOC)
> defect, but that BFD does not support a MisMatch/MisMerge (MMT/MMG)
> defect and could not replace the CV OAM function. Furthermore, BFD is
> not backward compatible with the G.8112 CV OAM.
>

DW: Discrim values are not labels whatsoever or have any semantic  
meaning analogous to a label whatsoever.

DW: The repeated lack of backward compatibility argument is specious  
as no attempt has been made to discuss and any extensions w/ BFD  
experts.

> In April 2007 it was clear that BFD OAM was not designed to operate  
> in a
> transport network, and as such could not be included as a T-MPLS OAM
> frame. It would have been necessary to change the BFD frame structure
> and the BFD processing to create a transport network compliant BFD
> frame.
>

DW: The below is making the point that no extensions, modifications  
or discussions w/ BFD experts occurred. The conclusion that there has  
been no progress in the area of BFD for transport networks is  
primarily due to the fact that no discussions or requests have occurred.

> ----
>
> Looking at the webpages for BFD and PWE3 WGs I find:
> "BFD for MPLS LSPs"
> http://www.ietf.org/internet-drafts/draft-ietf-bfd-mpls-05.txt
> "RFC5085 Pseudowire Virtual Circuit Connectivity Verification  
> (VCCV): A
> Control Channel for Pseudowires"
> http://www.ietf.org/rfc/rfc5085.txt?number=5085
> "Bi-directional Forwarding Detection (BFD) for the Pseudowire Virtual
> Circuit Connectivity Verification (VCCV)"
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-00.txt
>
> RFC5085 specifies VCCV/LSP-Ping and VCCV/ICMP-Ping. It does not  
> specify
> VCCV/BFD and is as such not applicable to the G.8114 discussion.
>
> BFD for MPLS LSPs specifies in section 5 that "A BFD session may be
> established for a FEC associated with a MPLS LSP". T-MPLS has no
> "FEC"s... As such it seems this i-d is not applicable to G.8114
> discussion. The BFD session seems to start/end above the T-MPLS Path
> layer trail termination (TMP_TT) function in the IP layer environment.
> I.e. a control plane function in the IP layer network seems to be the
> source/destination of BFD sessions (see "Generic Application of BFD,
> section 5, draft-ietf-bfd-generic-03.txt)". Different control plane
> functions may each generate their own BFD session and run those  
> over the
> same MPLS LSP. The T-MPLS CV OAM starts/ends in the TMP_TT functions,
> not in functions in one fo the TMP's client layers. Conclusion is that
> on the basis of this i-d, BFD can not be deployed in a T-MPLS Path
> layer.
>
> There is no BFD i-d to address deployment of BFD in the transmission
> media layer, e.g. in the T-MPLS section layer.
>
> BFD for PW VCCV extends RFC5085 with a VCCV/BFD capability. Section  
> 3.1
> specifies: "In order to use BFD, both ends of the PW connection must
> have signaled the existence of a control channel and the ability to  
> run
> BFD on it". In absence of a control plane in T-MPLS, there will be no
> signalling capability as specified here.
>
> Furthermore, the next paragraph in this section describes "When the
> downstream PE (D-PE) does not receive control messages from its  
> upstream
> peer PE (U-PE) during a certain number of transmission intervals (a
> number provisioned by the operator), D-PE declares that the PW in its
> receive direction is down." This confirms that BFD can detect a  
> loss of
> continuity (LOC) fault condition, but it fails to detect a  
> misconnection
> fault condition. In order to detect a misconnection, the BFD  
> process for
> the PW must check if there are other BFD OAM frames present that do  
> not
> belong to the PW.
>
>
> Section 6 of Generic Application of BFD states: "BFD can provide
> liveness detection for OAM-like functions in tunneling and pseudowire
> protocols.  Running BFD inside the tunnel is recommended, as it
> exercises more aspects of the path.  One way to accommodate this is to
> address BFD packets based on the tunnel endpoints, assuming that they
> are numbered.". This paragraph confirms that is limited to loss of
> continuity detection, and is missing the ability to detect
> misconnections. This is confirmed in draft-ietf-bfd-base-06.txt, where
> it is stated that the BFD process discards BFD packets that have  
> not the
> exact match.
>
>
> CONCLUSION:
> In April 2007 BFD was not meeting the connectivity check  
> requirements of
> the transport network. Today it seems that there has been no  
> progress on
> BFD in this area, and BFD is still not meeting the transport network
> requirements. Therefore, BFD can not be deployed as T-MPLS OAM.
>
> It would be interesting to know if the CV PDU with appropriate header
> can be deployed in MPLS networks at the interface/transmission media
> layer, the MPLS tunnel layer and the MPLS PW layer. With CV there  
> would
> be only the need for one CV OAM "session" per interface, per  
> tunnel, per
> pw instead of potentially multiple BFD sessions per interface, per
> tunnel, per pw.
>

DW: I think you misunderstand how BFD can and is being deployed in  
current IP/MPLS networks.

-DWard

> Maarten
> From: [email-masked] [mailto:[email-masked]] On  
> Behalf Of
> Stewart Bryant
> Sent: vrijdag 4 januari 2008 18:39
> To: Huub van Helvoort
> Cc: Q5/13; [email-masked]; pwe3
>>>>>>> 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"
>>>>>>
>>>>>> [hvh] the addition of the last sentence restricts the requirement
>>>>>> by providing a solution, solutions are out of scope for G.8113.
>>>>> SB> The scope of G.8113 is the surely the OAM requirements for a
>>>>> SB> profile of PWE3/MPLS. How can the use of IETF OAMs be out of
>>>>> SB> scope?
>>>>> SB>
>>>> comply
>>>> with the generic transport requirement that they should be confined
>>>> to a single layer.
>>
>> [hvh3] this was discussed by a break-out group and reported [hvh3] in
>> the Q5/13 meeting with all participants of the break-out [hvh3] group
>> present.
> T-mpls-dt mailing list
> [email-masked]
> http://mail.testbed.se/mailman/listinfo/t-mpls-dt

---

From: David Ward <[email-masked]>
Date: Tue, 8 Jan 2008 11:51:50 -0600

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

> [mv] I am not an IP/MPLS expert, so it is well possible that I do not
> have the correct understanding. I am a transport network expert, and I
> know that G.8114 specifies the set of OAM that a packet transport
> network using MPLS frame structures needs. After talking with  
> Stewart in
> Shenzhen, I also understand that there are numorous differences  
> between
> IP/MPLS and Transport (e.g. T-MPLS) networks in the operation and
> maintenance space; e.g. in the OAM, protection, network management,
> control plane areas. Trying to port OAM developed for one area in the
> other area is a true challenge, and is most likely not possible; the
> starting points are too different. I expect that there is also a
> misunderstanding of how transport OAM can and is deployed in current
> transport networks, which makes it impossible to port anything in  
> either
> direction.
>

DW: I haven't reached this conclusion yet. :-) Given we want TMPLS  
interoperability w/ MPLS/PWE networks, we have to find a way to  
interoperate OAM as well as control and forwarding planes.

> [mv] As IP/MPLS networks are migrating towards the transport space,
> IP/MPLS networks will in future be confronted with transport specific
> requirements, including transport OAM. G.8114 provides all  
> necessary OAM
> PDUs that will help IP/MPLS networks to meet these future transport
> network OAM requirements. E.g. the Service OAM work in MEF will add a
> significant number of additional OAM requirements in the IP/MPLS
> network. I.e. for point-to-point services that are supported with  
> MS-PW
> connections you will have to extend the PW OAM up to the level of T- 
> MPLS
> OAM.
>

DW: True but, that is the VCCV issue that is being discussed elsewhere.

> [mv] In addition, IP/MPLS equipment will already be confronted with
> transport OAM in its VPLS space. Y.1731 Ethernet OAM is required to be
> supported by IP/MPLS equipment as proposed by your colleague (refer to
> http://www.ietf.org/internet-drafts/draft-mohan-l2vpn-vpls- 
> oam-00.txt).
> G.8114 T-MPLS OAM is mainly a copy of this Y.1731 Ethernet OAM; Q.5/13
> essentially replaced the Ethernet specific OAM header by a T-MPLS
> specific OAM header.
>

DW: That doc is not a WG doc yet afaik and certainly given the -00  
nature, far from considered a standard.

> [mv] One of the reasons to do this is to reduce complexity of MPLS  
> frame
> based transport equipment (e.g. T-MPLS) that supports p2p and mp
> services. While MPLS (and thus T-MPLS) does not have natural  
> support for
> mp2mp and rmp connection services, Ethernet is incorporated to support
> those advanced connection types. The network service layer will as  
> such
> contain two technologies: MPLS frame based (MPLS PW, T-MPLS  
> Channel) and
> Ethernet VLAN frame based (ETH). Each and every PW within a MPLS
> Tunnel/T-MPLS Path connection can be associated with either a 2-port
> MS-PW/TMC connection or an n-port Ethernet VLAN connection. This
> requires that MEP and MIP functions in this network service layer must
> be configurable to be MS-PW or ETH (IP/MPLS case), or TMC or ETH (T- 
> MPLS
> case). As the OAM processing is a main part of the required  
> processing,
> it is smart to have a common OAM PDU format for both technologies.  
> This
> significantly reduces the complexity of the circuits.
>

DW: BFD can handle p2mp circuits with the same PDU fwiw.

> [mv] The T-MPLS OAM specified in G.8114 (and the T-MPLS protection
> specified in G.8131) also allows to have seamless interworking between
> Ethernet and T-MPLS networks. When a network deploys Ethernet in the
> access and T-MPLS in the metro/core hybrid VLAN/T-MPLS Channel
> connections can be supported, preventing to introduce additional  
> layers
> in the network. Point-to-point connections using VLANs in one part and
> T-MPLS Channel in another part are easy to set up. Interworking is
> simply the replacement of the label and the OAM header; very simple  
> and
> very low complexity. Impossible today to do this with IP/MPLS  
> instead of
> T-MPLS.
>
>

Are you suggesting that Enet OAM 802.1ag and TMPLS OAM have complete  
interworking? If so, great. The issue we are also discussing is the  
interoperability of TMPLS and MPLS/PWE technology as has been  
discussed at the last several IETF meetings and in Stuttgart. We must  
find a solution.

...snip ...

-DWard

---

From: Monique Morrow <[email-masked]>
Date: Wed, 09 Jan 2008 00:53:22 -0800

Maarten,

I refer you to the meeting report itself from April 2007, TD 185 (WP
4/13,specifically Section 3.2.4:

"TD151R1(WP4) (editor): Draft new Y.17tor at the end of the correspondence
period as agreed in the December 2006 interim meeting.
C.047 (Juniper Networks, Cisco): From the proposals, the first is already
covered by clause 13 of G.8110.1 Amendment 1 clause 13. Based on the
successive proposals clause 10 was revised. And the last proposal was
considered to be out of scope of this recommendation.
C.048 (Juniper Networks, Cisco): Proposals 3.2 and 3.3 were used as input
for drafting.
Proposal 3.1 was not accepted for the following reasons: as stated in the
report of the joint meeting of Q5/13 with the colleagues from Q9/15 and
Q12/15, i.e. TD132(WP4) clause II.1, Q5/13 was requested to develop Y.17tom
as follows:
Q.5/13 shall prepare draft Rec. Y.17tom according to the Option 1 described
in the Liaison statement they sent in July 2006 to Q.9 & 12/15. The document
will be developed re-using the existing OAM mechanisms defined in G.8112
(i.e. subset of the mechanisms defined in Y.1711). Additionally new
mechanisms will be introduced, as appropriate, (e.g. Loopback) re-using as
much as possible what is currently defined in Y.1731"OAM mechanisms for
Ethernet based networks". Q.5/13 will also consider to which extend results
from IETF work on MPLS OAM can be taken into account in this activity.
It was proposed to add a requirement to clause 7 as follows: ³Additional new
mechanisms shall be based on currently defined Y.1731 and IETF work on MPLS
OAM². This was rejected because this is considered to be a working
assumption.

The Q5/13 experts spent a significant amount of time considering the IETF
specified MPLS OAM for inclusion and concluded that these 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.

C.050 (Fujitsu): Proposals in 2.1, 2.2, 2.3, 2.3, 2.4, 2.5 and 2.7 were
accepted for drafting. It was agreed to reject proposals 2.6 after providing
clarification of the CFM functionality.
After drafting was completed on Y.17tor, uploaded as TD 189 (WP4), it was
proposed to go for consent. Two companies objected to this proposal."

Now as to claims of  issues with current IETF mechanisms, has there been a
liaison sent to the IETF pointing these claims out and with a request to
work on them? 

 I believe that this has not been the case.

Further, it may be useful to understand what is specifically meant by "Q5/13
is willing to work together with the IETF experts to resolve the issues."

If the IETF has NOT been notified, e.g via the liaison process, and as per
the IETF change process to "resolve an issue" how can it do so?

The discussion is very much open and not at all closed .

Regards,

Monique

On 1/8/08 7:11 AM, "VISSERS Maarten" <[email-masked]>
wrote:

> (http://ties.itu.int/u/tsg13/sg13/xchange/wp4/q5/0704_Geneva/wd09R2-tmpl
> s-oam-y17tom(mpls-consid)-02.ppt) presents an analysis of the use of BFD
> within T-MPLS networks and concludes that BFD is not capable to meet the
> requirements. 
> 
> As far as the participants understood the BFD specification, use of BFD
> within T-MPLS instead of use of CV would have introduced a security risk
> in T-MPLS networks.
> 
> compatible with G.8112 defined T-MPLS OAM and G.8121 (03/2006) specified
> T-MPLS trail termination (TM_TT) functions. Use of BFD does not provide
> function (version 1) or TM_TT function (version 2) is misconnected with
> could be used as replacement of the MEGID/MEPID. Slide 16 presents some
> fields a not meant to be used as MEGID/MEPID, these fields are used as a
> field in the label stack entry header of the frame (including in the OAM
> frames). The MyDiscriminator/YourDiscriminator fields are an unnecessary
> duplicate of the main label field. The conclusion was therefore that the
> In April 2007 it was clear that BFD OAM was not designed to operate in a
> "RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV): A
> RFC5085 specifies VCCV/LSP-Ping and VCCV/ICMP-Ping. It does not specify
> functions may each generate their own BFD session and run those over the
> BFD for PW VCCV extends RFC5085 with a VCCV/BFD capability. Section 3.1
> have signaled the existence of a control channel and the ability to run
> downstream PE (D-PE) does not receive control messages from its upstream
> receive direction is down." This confirms that BFD can detect a loss of
> continuity (LOC) fault condition, but it fails to detect a misconnection
> fault condition. In order to detect a misconnection, the BFD process for
> the PW must check if there are other BFD OAM frames present that do not
> belong to the PW.
> 
> 
> it is stated that the BFD process discards BFD packets that have not the
> exact match.
> 
> 
> CONCLUSION:
> In April 2007 BFD was not meeting the connectivity check requirements of
> the transport network. Today it seems that there has been no progress on
> layer, the MPLS tunnel layer and the MPLS PW layer. With CV there would
> be only the need for one CV OAM "session" per interface, per tunnel, per
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stewart Bryant
>>>> [hvh2] during the evaluation (as mentioned above) they do not comply
> 
> I was not at that meeting, nor were many of the people subscribed to the
> lists that this is being discussed on.
> 
> So that we can make progress, please summarize the technical reasons for
> this decision.
> 
> Thank you
> 
> Stewart
>

---

From: Monique Morrow <[email-masked]>
Date: Wed, 09 Jan 2008 00:55:45 -0800

Maarten,

In the spirit of the intent of the ITU to collaborate with the IETF, can you
please refrain from such statements such as :

"Sometimes I have the feeling that MPLS OAM addresses yesterdays
requirements and T-MPLS (and Ethernet) OAM addresses tomorrows
 requirements... as well known, it is possible to go from yesterday to
 tomorrow, but it is not possible to go from tomorrow to yesterday..."

And keep your discussion technical -- this is not a marketing group.

Regards.

Monique
On 1/8/08 11:34 AM, "VISSERS Maarten" <[email-masked]>
wrote:

>  David,
> 
> Sometimes I have the feeling that MPLS OAM addresses yesterdays
> requirements and T-MPLS (and Ethernet) OAM addresses tomorrows
> requirements... as well known, it is possible to go from yesterday to
> tomorrow, but it is not possible to go from tomorrow to yesterday...
> 
> To address the interoperability between TMPLS and MPLS/PWE, we can learn
> from the interoperability between ATM and FR, ATM and MPLS. TMPLS has a
> much richer OAM set then MPLS/PWE and as long as this is the case,
> interoperability will require an interworking function that is able to
> translate the common OAM functions and terminate all other OAM
> functions. Once MPLS/PWE OAM has been extended and supports "tomorrows
> OAM set", this interworking function can become trivial, and become like
> the Ethernet to T-MPLS interworking function (i.e. just replace the OAM
> header). 
> If you look at slide 20 of WD09 you find a list of OAM functions and the
> OAM PDUs that support those functions in Ethernet, T-MPLS and MPLS. The
> MPLS column is almost empty as there was not enough knowledge of MPLS
> OAM present in the April 2007 meeting. Perhaps you can help to fill in
> this column, which allows us to identify the missing functions in
> MPLS/PWE OAM. I have attached a pdf version of this table to this email
> for people that have no access to WD09.
> 
> And it is not only the OAM that has to be addressed. It is also the
> protection switching. Transport networks provide 50 ms protection
> switching performance by operating protection switching bridge/selector
> functions and supporting MEPs at the protection domain boundary only;
> the intermediate nodes are agnostic to this protection switching.
> MPLS/PWE requires that both the boundary nodes of and the intermediate
> nodes in the the protected domain support protection functions (FRR) to
> meet the 50 ms switch performance. MPLS protection is as such more
> complicated than TMPLS protection; or stated it differently, TMPLS
> protection is less complex than MPLS protection. This reduced complexity
> is possible due to the more advanced TMPLS OAM (e.g. CV OAM and multiple
> MEG levels).
> 
> 
> The above is certainly for the longer term given the extensions
> necessary to MPLS/PWE OAM. For the short term, we must make sure that
> unintended interconnections between MPLS/PWE and TMPLS networks can be
> detected and consequent actions (including repair) can be initiated.
> 
> It would be a fantastic help if you could describe the behaviour of
> MPLS/PWE nodes when such node would unintendendly be interconnected to a
> TMPLS node. Two cases are to be distinguished to begin with:
> A) the MPLS/PWE node's interface was previously not connected
> B) the MPLS/PWE node's interface was previously connected to another
> MPLS/PWE node interface.
> Two types of interfaces should be considered: POS and 802.3.
> Questions I have is what would happen at the
> - physical layer for the case of the POS interface
> - MPLS interface level (where TMPLS has its TMPLS Section OAM) for both
> POS and 802.3 interfaces
> - MPLS tunnel level for POS and 802.3 interfaces
> - MPLS pseudowire level for POS and 802.3 interfaces.
> In normal transport networks, such miswiring fault should be detected at
> the physical or interface/section layer level, which then blocks the
> traffic such that the higher layers (tunnel, pseudowire) are just seeing
> a discontinuity (LOC). What will MPLS/PWE nodes do in this case?
> 
> Note that TMPLS deploys typically GFP-F instead of PPP/HDLC on STM-N
> interfaces. So in most cases a misconnection of a STM-N interface will
> result in a paylaod mismatch (PLM) detection by inspecting the signal
> label at the VC-n layer.
> 
>> Are you suggesting that Enet OAM 802.1ag and TMPLS OAM have
>> complete interworking? If so, great.
> 
> Y.1731 Ethernet OAM and TMPLS OAM have complete interworking. 802.1ag
> has fewer OAM PDUs than Y.1731 and a number of 802.1ag OAM PDUs have
> additional TLVs that are not supported in Y.1731 (don't make sense in a
> transport network, are present for use in enterprise networks that lack
> a good network management system). Those additional TLVs when present in
> a transport network after a misconnection are simply ignored by the
> ITU-T Ethernet MEP and MIP functions (G.8021). And vice versa, 802.1ag
> MEP functions ignore the additional Y.1731 OAM frames, and simply
> discard those frames when crossing an MD level or crossing a layer
> boundary.
> 
> This latter behaviour is also what I would expect that MPLS/PWE nodes
> perform when interconnected unintendendly with a TMPLS node/network.
> Similarly, TMPLS nodes will ignore MPLS/PWE OAM, and discard it at layer
> boundaries. Besides this, TMPLS nodes will detect either a TIM fault
> (POS, GFP-F), a PLM fault, or a LOC condition when and raise an alarm to
> make the operator aware of the miswiring. If MPLS/PWE nodes would do the
> same at the physical layer or at the interface layer due to loss of BFD,
> miswiring between MPLS/PWE and TMPLS nodes will be no issue at all.
> 
> Regards,
> Maarten
> 
> From: David Ward [mailto:[email-masked]]
> Sent: dinsdag 8 januari 2008 18:52
> To: VISSERS Maarten
> Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;
> [email-masked]; pwe3
> Subject: Re: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114
> 
> Maarten -
> 
> 
> 
>> network using MPLS frame structures needs. After talking with Stewart
>> in Shenzhen, I also understand that there are numorous differences
>> between IP/MPLS and Transport (e.g. T-MPLS) networks in the operation
>> and maintenance space; e.g. in the OAM, protection, network
>> management, control plane areas. Trying to port OAM developed for one
>> area in the other area is a true challenge, and is most likely not
>> possible; the starting points are too different. I expect that there
>> is also a misunderstanding of how transport OAM can and is deployed in
> 
>> current transport networks, which makes it impossible to port anything
> 
>> in either direction.
>> 
> 
>> requirements, including transport OAM. G.8114 provides all necessary
>> OAM PDUs that will help IP/MPLS networks to meet these future
>> transport network OAM requirements. E.g. the Service OAM work in MEF
>> will add a significant number of additional OAM requirements in the
>> IP/MPLS network. I.e. for point-to-point services that are supported
>> with MS-PW connections you will have to extend the PW OAM up to the
>> level of T- MPLS OAM.
>> 
> 
>> frame based transport equipment (e.g. T-MPLS) that supports p2p and mp
> 
>> services. While MPLS (and thus T-MPLS) does not have natural support
>> for mp2mp and rmp connection services, Ethernet is incorporated to
>> support those advanced connection types. The network service layer
>> will as such contain two technologies: MPLS frame based (MPLS PW,
>> T-MPLS
>> Channel) and
>> MPLS case). As the OAM processing is a main part of the required
>> processing, it is smart to have a common OAM PDU format for both
>> technologies.
>> This
>> layers in the network. Point-to-point connections using VLANs in one
>> part and T-MPLS Channel in another part are easy to set up.
>> Interworking is simply the replacement of the label and the OAM
>> header; very simple and very low complexity. Impossible today to do
>> this with IP/MPLS instead of T-MPLS.
>> 
>> 
> 
> interoperability of TMPLS and MPLS/PWE technology as has been discussed
> at the last several IETF meetings and in Stuttgart. We must find a
> solution.
> 
> ...snip ...
> 
> 
> -DWard

---

From: Monique Morrow <[email-masked]>
Date: Wed, 09 Jan 2008 01:49:24 -0800

Maarten,

Let's focus please on the meeting report content as I have previously
pointed out as not to cloud the issues here.

Back to the original question:

And please do highlight what is meant by Further, it may be useful to
understand what is specifically meant by "Q5/13
 is willing to work together with the IETF experts to resolve the issues."

The topic again is still very much open Maarten....

Monique

On 1/9/08 1:30 AM, "VISSERS Maarten" <[email-masked]>
wrote:

> Monique,
> 
> Q.5/13 is not responsible for issues in IETF OAM tools. Q.5/13 is responsible
> for ITU-T OAM tools, and has to review OAM tools that are being proposed for
> inclusion in its Recommendations.
> 
> Q.5/13 did this review with respect to the proposal from two companies to add
> BFD to the T-MPLS OAM recommendation. Q.5/13 concluded that the BFD tool as
> specified in internet-drafts does not comply with the transport network OAM
> requirements, and as such could not be added to G.8114. Q.5/13 indicated its
> willingness to help IETF enhance this BFD tool. As BFD is a tool under
> development in IETF, it is not Q.5/13's responsibility to tell IETF that their
> BFD tool must be modified in order to be used in the T-MPLS network. The
> proposal to add BFD to the T-MPLS OAM set was not made by two companies
> (including your company), and it is the responsibility of those companies to
> raise the issue in IETF. If IETF would accept the issue that BFD has within
> T-MPLS networks and would want to modify BFD such that it complies with the
> transport network OAM requirements, then after a liaison from IETF to Q.5/13
> it would be possible for Q.5/13 to work together with the IETF to resolve the
> issues.
> 
> Neither of the two companies (including your company) has requested the IETF
> to enhance their BFD OAM tool to meet the transport network OAM requirements
> in the last 9 months. That means that the issue of inclusion of BFD in the
> first version of G.8114 is closed; you can not expect ITU-T to wait when your
> and the other company did not work on this item for the last 9 months.
> 
> After the first G.8114 version, Q.5/13 will work on further
> enhancements/extensions based on received contributions and the results of the
> review of those contributions. Once IETF has decided to enhance/extend BFD and
> has liaised this decision to Q.5/13, Q.5/13 can help IETF to make these
> enhancements/extensions. I suggest that you write a contribution into the next
> IETF meeting to raise this issue.
> 
> Regards,
> Maarten
> PS. I am working with a colleague of you to make him aware of the detailed
> issues of BFD deployment in a transport network.
> 
> Sent: woensdag 9 januari 2008 9:53
> To: VISSERS Maarten; Stewart Bryant; Huub van Helvoort
> C.048 (Juniper Networks, Cisco): Proposals 3.2 and 3.3 were used as input for
> drafting.
> Q12/15, i.e. TD132(WP4) clause II.1, Q5/13 was requested to develop Y.17tom as
> follows:
> Q.5/13 shall prepare draft Rec. Y.17tom according to the Option 1 described in
> the Liaison statement they sent in July 2006 to Q.9 & 12/15. The document will
> be developed re-using the existing OAM mechanisms defined in G.8112 (i.e.
> subset of the mechanisms defined in Y.1711). Additionally new mechanisms will
> be introduced, as appropriate, (e.g. Loopback) re-using as much as possible
> what is currently defined in Y.1731"OAM mechanisms for Ethernet based
> networks". Q.5/13 will also consider to which extend results from IETF work on
> MPLS OAM can be taken into account in this activity.
> OAM². This was rejected because this is considered to be a working assumption.
> 
> 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.
> 
> liaison sent to the IETF pointing these claims out and with a request to work
> on them? 
> 
> If the IETF has NOT been notified, e.g via the liaison process, and as per the
> IETF change process to "resolve an issue" how can it do so?
> 
>> s-oam-y17tom(mpls-consid)-02.ppt) presents an analysis of the use of
>> BFD within T-MPLS networks and concludes that BFD is not capable to
>> meet the requirements.
>> 
>> BFD within T-MPLS instead of use of CV would have introduced a
>> security risk in T-MPLS networks.
>> 
>> specified T-MPLS trail termination (TM_TT) functions. Use of BFD does
>> not provide this backward compatibility, while the TM_TT function in
>> G.8121
>> with a version 2 TM_TT function. Version 1 TM_TT generates CVv0 OAM
>> and is able to receive CVv0 and CVv1 OAM. Version 2 TM_TT function
>> generates
>> 2) BFD contains a MyDiscriminator/YourDiscriminator field which could
>> be used as replacement of the MEGID/MEPID. Slide 16 presents some text
>> of bfd-base-06 in which these fields are defined as a "field for
>> fields a not meant to be used as MEGID/MEPID, these fields are used as
>> a demultiplexing label. In T-MPLS the demultiplexing label is a label
>> field in the label stack entry header of the frame (including in the
>> OAM frames). The MyDiscriminator/YourDiscriminator fields are an
>> unnecessary duplicate of the main label field. The conclusion was
>> therefore that the absence of BFD can be used to represent the Loss of
>> Continuity (LOC) defect, but that BFD does not support a
>> MisMatch/MisMerge (MMT/MMG) defect and could not replace the CV OAM
>> function. Furthermore, BFD is not backward compatible with the G.8112 CV OAM.
>> 
>> In April 2007 it was clear that BFD OAM was not designed to operate in
>> a transport network, and as such could not be included as a T-MPLS OAM
>> "RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV):
>> A Control Channel for Pseudowires"
>> specify VCCV/BFD and is as such not applicable to the G.8114 discussion.
>> 
>> functions may each generate their own BFD session and run those over
>> the same MPLS LSP. The T-MPLS CV OAM starts/ends in the TMP_TT
>> functions, not in functions in one fo the TMP's client layers.
>> Conclusion is that on the basis of this i-d, BFD can not be deployed
>> in a T-MPLS Path layer.
>> 
>> run BFD on it". In absence of a control plane in T-MPLS, there will be
>> no signalling capability as specified here.
>> 
>> upstream peer PE (U-PE) during a certain number of transmission
>> intervals (a number provisioned by the operator), D-PE declares that
>> the PW in its receive direction is down." This confirms that BFD can
>> detect a loss of continuity (LOC) fault condition, but it fails to
>> detect a misconnection fault condition. In order to detect a
>> misconnection, the BFD process for the PW must check if there are
>> other BFD OAM frames present that do not belong to the PW.
>> 
>> 
>> it is stated that the BFD process discards BFD packets that have not
>> the exact match.
>> 
>> 
>> CONCLUSION:
>> In April 2007 BFD was not meeting the connectivity check requirements
>> of the transport network. Today it seems that there has been no
>> progress on BFD in this area, and BFD is still not meeting the
>> transport network requirements. Therefore, BFD can not be deployed as T-MPLS
>> OAM.
>> 
>> would be only the need for one CV OAM "session" per interface, per
>> tunnel, per pw instead of potentially multiple BFD sessions per
>> interface, per tunnel, per pw.
>> 
>> Regards,
>> Maarten
>> 
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Stewart Bryant
>>>>>> SB> a) If the scope of G.8113 is to create an OAM that is
>>>>>> SB> different
>> 
>> I was not at that meeting, nor were many of the people subscribed to
>> the lists that this is being discussed on.
>> 
>> So that we can make progress, please summarize the technical reasons
>> for this decision.
>> 
>> Thank you
>> 
>> Stewart
>> 
>

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Jan 2008 09:58:21 +0000

Maarten
> for people that have no access to WD09.
Some of these are not OAM functions at all, for example

The architected way to find out what % of user data is at the gross
level to look in the MIB at the packet counters in the two PEs,
and at the micro level to turn on the sequence number mechanism
in the PWE3 control word and look in the MIB at the number of
frame sequence errors.

> is possible due to the more advanced TMPLS OAM (e.g. CV OAM and multiple
If you want fast detection with robust protection the commonly
deployed MPLS-TE one hop tunnel approach gives you that. It is
faster than the T-MPLS approach because the detection packet has
less distance to travel, and if the fault is LOL, it is resolved locally.
It is more robust because the domain of the SRLG is more compact,
and because the repair paths are shorter there is less chance of
an accidental SRLG. Furthermore because we are only repairing
a single hop, there is less chance of a remote double failure
taking causing the path to go down because you can do
concatenated repairs.

On the other hand you can also (in the current IETF design)
install diverse MPLS-TE paths between the PEs which is what
T-MPLS proposes. However the detection time  for this will
be longer (due to the physics) in both of these end to end
designs than it is for the  widely deployed local repair
approach.

> result in a paylaod mismatch (PLM) detection by inspecting the signal
Surely the T-MPLS OAM behavior should be invariant with the
physical and the virtual layer that it is mapped to. If there is
any interaction that is a layer violation, and you do not have a
layered network. The only exception to that I can see is SSM which
required virtual layer continuity, but the mechanism for doing that
have not yet been worked out (and hence have been removed from
G.8114).

- Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 09 Jan 2008 10:09:06 +0000

Maarten
> Neither of the two companies (including your company) has requested the IETF to enhance their BFD OAM tool to meet the transport network OAM requirements in the last 9 months. That means that the issue of inclusion of BFD in the first version of G.8114 is closed; you can not expect ITU-T to wait when your and the other company did not work on this item for the last 9 months.
>   
What have individual companies got to do with this?
The meeting concluded that ITU needed to work with the IETF.
That required a request under the MPLS Change Process.

There was no change request and no liaison to the IETF
BFD WG.

> After the first G.8114 version, Q.5/13 will work on further enhancements/extensions based on received contributions and the results of the review of those contributions. Once IETF has decided to enhance/extend BFD and has liaised this decision to Q.5/13, Q.5/13 can help IETF to make these enhancements/extensions. I suggest that you write a contribution into the next IETF meeting to raise this issue.
>   
No the right thing to do is to put G.8114 on hold until the
technical issues are resolved.
> PS. I am working with a colleague of you to make him aware of the detailed issues of BFD deployment in a transport network.
>
>   
The details of the concerns that you have about the BFD design should
be discussed on the IETF BFD WG list.

Stewart

---

From: Mark Townsley <[email-masked]>
Date: Wed, 09 Jan 2008 12:43:00 +0100

VISSERS Maarten wrote:
>  As I have indicated, your company should have raised the issue in the IETF. Your company did not do this. So for this version of G.8114 this issue is closed.
>   
Maarten, companies are not members of the IETF, and have no special 
standing in the IETF Standards Process. Individuals do. You, or anyone 
else, can bring any issue you like to the IETF via a simple email (just 
as we are exchanging now). The overhead of this initial step is so small 
that the only reasons I can think of for anyone not having taken this 
step is ignorance, lack of will, or perhaps the expectation that it was 
someone else's responsibility. It sounds to me like you believe raising 
this issue was someone else's responsibility rather than your own. In 
fact, it is the responsibility of the one who desires to make changes to 
IETF protocols to bring those change requests to the IETF - I don't 
think we could expect to function as an organization otherwise.

- Mark

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 09 Jan 2008 13:47:06 +0100

Hello Mark,

You wrote:

> VISSERS Maarten wrote:
>>  As I have indicated, your company should have raised the issue in the 
>> IETF. Your company did not do this. So for this version of G.8114 this 
>> issue is closed.
>>   

In the ITU-T the experts represent their company.
If it is necessary to communiucate with other SDOs we have to
use liaisons.
In this particular case there was a company contribution proposing
to add a reference to Y.1714, this is proposal 3.1 of C049.

The meeting report says:
------------------------------------------------------------------
C.048 (Juniper Networks, Cisco):
Proposal 3.1 was not accepted for the following reasons: as stated
in the report of the joint meeting of Q5/13 with the colleagues
from Q9/15 and Q12/15, i.e. TD132(WP4) clause II.1, Q5/13 was
requested to develop Y.17tom as follows:
Q.5/13 shall prepare draft Rec. Y.17tom according to the Option 1
described in the Liaison statement they sent in July 2006 to Q.9 &
12/15. The document will be developed re-using the existing OAM
mechanisms defined in G.8112 (i.e. subset of the mechanisms defined
in Y.1711). Additionally new mechanisms will be introduced, as
appropriate, (e.g. Loopback) re-using as much as possible what is
currently defined in Y.1731"OAM mechanisms for Ethernet based
networks". Q.5/13 will also consider to which extend results from
IETF work on MPLS OAM can be taken into account in this activity.
It was proposed to add a requirement to clause 7 as follows:
*Additional new mechanisms shall be based on currently defined Y.1731 
and IETF work on MPLS OAM*.
This was rejected because this is considered to be a working
assumption.

The Q5/13 experts spent a significant amount of time considering
the IETF specified MPLS OAM for inclusion and concluded that these 
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.
---------------------------------------

What I tried to express in my non-native english is that the
proposed addition was rejected because the OAM in Y.1714 does
not meet the transport requirements (the conclusion from the
break-out group) and for that reason cannot be used.

If the company that submitted the contribution desires that a
change is made to comply with the transport requirements
than it is their responsability to find a solution.
If they have one they can submit a new contribution.

If it is necessary to explain to the IETF experts what
the transport requiremnts are, the ITU-T experts are willing
to do that.

So, if you want to blame anyone for ignorance, lack of will,
or perhaps the expectation that it was someone else's
responsibility, *don't blame me*.

Regards, Huub.

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

---

From: "VISSERS Maarten" <[email-masked]>
Date: Wed, 9 Jan 2008 12:07:42 +0100

Stewart,

> That required a request under the MPLS Change Process.

The Q.5/13 meeting received a vocal proposal (not a written
contribution) to add BFD to the TMPLS OAM tool set. The meeting reviewed
and rejected the proposal to add the BFD as specified in the
internet-drafts to the TMPLS toolset going for consent in April 2007.

The Q.5/13 meeting has developed a TMPLS OAM toolset that is meeting the
requirements. If the companies proposing BFD wanted to see BFD in future
being included in the TMPLS OAM toolset, then Q.5/13 will work with IETF
to resolve the issues. The meeting did not conclude that ITU will take
the lead.

There is as such no reason to keep G.8114 on hold.

Regards,
Maarten

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 11:09
To: VISSERS Maarten
Cc: Monique Morrow; Huub van Helvoort; Q5/13; [email-masked]; pwe3
Subject: Re: [PWE3] Re: progress of G.8113 and G.8114

Maarten
> Neither of the two companies (including your company) has requested
the IETF to enhance their BFD OAM tool to meet the transport network OAM
requirements in the last 9 months. That means that the issue of
inclusion of BFD in the first version of G.8114 is closed; you can not
expect ITU-T to wait when your and the other company did not work on
this item for the last 9 months.

There was no change request and no liaison to the IETF BFD WG.

> After the first G.8114 version, Q.5/13 will work on further
enhancements/extensions based on received contributions and the results
of the review of those contributions. Once IETF has decided to
enhance/extend BFD and has liaised this decision to Q.5/13, Q.5/13 can
help IETF to make these enhancements/extensions. I suggest that you
write a contribution into the next IETF meeting to raise this issue.
No the right thing to do is to put G.8114 on hold until the technical
issues are resolved.
> PS. I am working with a colleague of you to make him aware of the
detailed issues of BFD deployment in a transport network.
The details of the concerns that you have about the BFD design should be
discussed on the IETF BFD WG list.

Stewart

---

From: "VISSERS Maarten" <[email-masked]>
Date: Wed, 9 Jan 2008 14:04:39 +0100

Mark,

Thanks for this information. I was not aware of this approach in IETF.
So you are allowed to use your companies budget to propose changes to
IETF standards that are not supported by your company. I am not. To
propose e.g. changes to BFD, I need company approval before I can send
this simple email you refer to. Furthermore, in ITU-T companies are
member, not individuals.

With respect to BFD, I have no idea if the current BFD specification
within the scope of the IP/MPLS network has any issues. I assume it
hasn't. 
I know that the use of BFD within the scope of T-MPLS network has
several issues. I am only not the one that proposes to use BFD in T-MPLS
networks. So again, I have no issues with the use of BFD in IP/MPLS
networks.
Q.5/13 has developed a set of OAM requirements and a set of tools that
implement those requirements. BFD is not part of the tools defined by
Q.5/13, so also Q.5/13 is not having any issues with the current BFD
specification as intended to be used in IP/MPLS networks for which
Q.5/13 has no responsibility.

That in my understanding leaves the responsibility to raise in IETF the
issue that BFD has when it has to operate in a T-MPLS network to
individuals of the companies in ITU-T that proposed to use BFD in TMPLS.
Perhaps individuals of these companies can raise this issue in IETF by
sending the simple email. Let me offer a part of my time for further
consulting on this matter to the IETF. I am not on the IETF
mailinglists, so please contact me directly if my contribution is
appreciated.

Regards,
Maarten

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 12:43
To: VISSERS Maarten
Cc: Monique Morrow; Stewart Bryant; Huub van Helvoort; Q5/13;

- Mark

---

From: "VISSERS Maarten" <[email-masked]>
Date: Wed, 9 Jan 2008 10:30:49 +0100

Monique,

Q.5/13 is not responsible for issues in IETF OAM tools. Q.5/13 is responsible for ITU-T OAM tools, and has to review OAM tools that are being proposed for inclusion in its Recommendations. 

Q.5/13 did this review with respect to the proposal from two companies to add BFD to the T-MPLS OAM recommendation. Q.5/13 concluded that the BFD tool as specified in internet-drafts does not comply with the transport network OAM requirements, and as such could not be added to G.8114. Q.5/13 indicated its willingness to help IETF enhance this BFD tool. As BFD is a tool under development in IETF, it is not Q.5/13's responsibility to tell IETF that their BFD tool must be modified in order to be used in the T-MPLS network. The proposal to add BFD to the T-MPLS OAM set was not made by two companies (including your company), and it is the responsibility of those companies to raise the issue in IETF. If IETF would accept the issue that BFD has within T-MPLS networks and would want to modify BFD such that it complies with the transport network OAM requirements, then after a liaison from IETF to Q.5/13 it would be possible for Q.5/13 to work together with the IETF to resolve the issues.

Regards,
Maarten

-----Original Message-----
From: Monique Morrow [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 9:53
To: VISSERS Maarten; Stewart Bryant; Huub van Helvoort
Cc: Q5/13; [email-masked]; pwe3
Subject: Re: [PWE3] Re: progress of G.8113 and G.8114

Maarten,

I refer you to the meeting report itself from April 2007, TD 185 (WP 4/13,specifically Section 3.2.4:

"TD151R1(WP4) (editor): Draft new Y.17tor at the end of the correspondence period as agreed in the December 2006 interim meeting.
C.047 (Juniper Networks, Cisco): From the proposals, the first is already covered by clause 13 of G.8110.1 Amendment 1 clause 13. Based on the successive proposals clause 10 was revised. And the last proposal was considered to be out of scope of this recommendation.
C.048 (Juniper Networks, Cisco): Proposals 3.2 and 3.3 were used as input for drafting.
Proposal 3.1 was not accepted for the following reasons: as stated in the report of the joint meeting of Q5/13 with the colleagues from Q9/15 and Q12/15, i.e. TD132(WP4) clause II.1, Q5/13 was requested to develop Y.17tom as follows:
Q.5/13 shall prepare draft Rec. Y.17tom according to the Option 1 described in the Liaison statement they sent in July 2006 to Q.9 & 12/15. The document will be developed re-using the existing OAM mechanisms defined in G.8112 (i.e. subset of the mechanisms defined in Y.1711). Additionally new mechanisms will be introduced, as appropriate, (e.g. Loopback) re-using as much as possible what is currently defined in Y.1731"OAM mechanisms for Ethernet based networks". Q.5/13 will also consider to which extend results from IETF work on MPLS OAM can be taken into account in this activity.
It was proposed to add a requirement to clause 7 as follows: ³Additional new mechanisms shall be based on currently defined Y.1731 and IETF work on MPLS OAM². This was rejected because this is considered to be a working assumption.

The Q5/13 experts spent a significant amount of time considering the IETF specified MPLS OAM for inclusion and concluded that these 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.

C.050 (Fujitsu): Proposals in 2.1, 2.2, 2.3, 2.3, 2.4, 2.5 and 2.7 were accepted for drafting. It was agreed to reject proposals 2.6 after providing clarification of the CFM functionality.
After drafting was completed on Y.17tor, uploaded as TD 189 (WP4), it was proposed to go for consent. Two companies objected to this proposal."

Now as to claims of  issues with current IETF mechanisms, has there been a liaison sent to the IETF pointing these claims out and with a request to work on them? 

Further, it may be useful to understand what is specifically meant by "Q5/13 is willing to work together with the IETF experts to resolve the issues."

If the IETF has NOT been notified, e.g via the liaison process, and as per the IETF change process to "resolve an issue" how can it do so?

Regards,

Monique

On 1/8/08 7:11 AM, "VISSERS Maarten" <[email-masked]>
wrote:

> transport network requirements. Therefore, BFD can not be deployed as T-MPLS OAM.
>

---

From: "VISSERS Maarten" <[email-masked]>
Date: Tue, 8 Jan 2008 18:22:34 +0100

David,

inline... 

-----Original Message-----
From: David Ward [mailto:[email-masked]] 
Sent: dinsdag 8 januari 2008 17:24
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

inline

> BFD within T-MPLS networks and concludes that BFD is not capable to 

DW: Has this been liased to the IETF, sent to the BFD WG, WG chairs or
authors? Note that I don't have access to the above referenced ppt.

[mv] I have emailed you a copy of this WD. It has not been sent to the
IETF, while there was no need for in April 2007. G.8114 has a fully
functional and compliant CV OAM frame that does the job. There was no
need from a transport network to complicate T-MPLS with another OAM
frame that does not add anything to the set of OAM frames. Cisco and
Juniper representatives have been pushing for BFD inclusion, and if
their representatives haven't brought the BFD issues into the IETF
meetings in the last 9 months, then there seems to be no need to use BFD
in T-MPLS networks. If there would have been a need, the technical
deficiencies of BFD within the scope of a transport network would
otherwise be contributed to IETF and resolved.

> security risk in T-MPLS networks.

DW: I'll bite. How so? I don't see this point mentioned anywhere else in
the thread nor have I ever received any information on this topic.  
Also, none is on the BFD WG email list.

[mv] I am surprised. This issue was made very clear to those pushing for
BFD inclusion in T-MPLS networks. I would have expected that those
people would have brought this into IETF to resolve this issue. As this
is not done, I can only conclude that there is no real desire to deploy
BFD in T-MPLS networks.

[mv] SG13 has consented G.8114 in April 2007. BFD is not included for
the mentioned reasons. If the proponents of BFD deployment in T-MPLS
have not addressed the shortcomings of BFD, including the backward
compatibility with TM_TT functions, then there seems to be no desire to
deploy BFD in T-MPLS networks. As such, it is best for BFD to ignore
those transport network related issues.

> 	2) BFD contains a MyDiscriminator/YourDiscriminator field which
could 

[mv] A label in general is a "demultiplexer" and the text I quoted from
bfd-base-06 refers to the discrim field as a "demultiplexing" field.

DW: The repeated lack of backward compatibility argument is specious as
no attempt has been made to discuss and any extensions w/ BFD experts.

[mv] You have to talk with your colleagues who have been pushing for BFD
in T-MPLS. I am surprised that they did not work with you the last 9
months to address those issues.

> and the BFD processing to create a transport network compliant BFD 

DW: The below is making the point that no extensions, modifications or
discussions w/ BFD experts occurred. The conclusion that there has been
no progress in the area of BFD for transport networks is primarily due
to the fact that no discussions or requests have occurred.

[mv] I understand the situation. T-MPLS does not need BFD, as G.8112 and
G.8114 already provide OAM that performs the BFD function. Please talk
with your colleagues as to why they did not raise the BFD deficiencies
in transport networks with you.

[mv] I am not an IP/MPLS expert, so it is well possible that I do not
have the correct understanding. I am a transport network expert, and I
know that G.8114 specifies the set of OAM that a packet transport
network using MPLS frame structures needs. After talking with Stewart in
Shenzhen, I also understand that there are numorous differences between
IP/MPLS and Transport (e.g. T-MPLS) networks in the operation and
maintenance space; e.g. in the OAM, protection, network management,
control plane areas. Trying to port OAM developed for one area in the
other area is a true challenge, and is most likely not possible; the
starting points are too different. I expect that there is also a
misunderstanding of how transport OAM can and is deployed in current
transport networks, which makes it impossible to port anything in either
direction.

[mv] As IP/MPLS networks are migrating towards the transport space,
IP/MPLS networks will in future be confronted with transport specific
requirements, including transport OAM. G.8114 provides all necessary OAM
PDUs that will help IP/MPLS networks to meet these future transport
network OAM requirements. E.g. the Service OAM work in MEF will add a
significant number of additional OAM requirements in the IP/MPLS
network. I.e. for point-to-point services that are supported with MS-PW
connections you will have to extend the PW OAM up to the level of T-MPLS
OAM.

http://www.ietf.org/internet-drafts/draft-mohan-l2vpn-vpls-oam-00.txt).

[mv] One of the reasons to do this is to reduce complexity of MPLS frame
based transport equipment (e.g. T-MPLS) that supports p2p and mp
services. While MPLS (and thus T-MPLS) does not have natural support for
mp2mp and rmp connection services, Ethernet is incorporated to support
those advanced connection types. The network service layer will as such
contain two technologies: MPLS frame based (MPLS PW, T-MPLS Channel) and
Ethernet VLAN frame based (ETH). Each and every PW within a MPLS
Tunnel/T-MPLS Path connection can be associated with either a 2-port
MS-PW/TMC connection or an n-port Ethernet VLAN connection. This
requires that MEP and MIP functions in this network service layer must
be configurable to be MS-PW or ETH (IP/MPLS case), or TMC or ETH (T-MPLS
case). As the OAM processing is a main part of the required processing,
it is smart to have a common OAM PDU format for both technologies. This
significantly reduces the complexity of the circuits.

[mv] The T-MPLS OAM specified in G.8114 (and the T-MPLS protection
specified in G.8131) also allows to have seamless interworking between
Ethernet and T-MPLS networks. When a network deploys Ethernet in the
access and T-MPLS in the metro/core hybrid VLAN/T-MPLS Channel
connections can be supported, preventing to introduce additional layers
in the network. Point-to-point connections using VLANs in one part and
T-MPLS Channel in another part are easy to set up. Interworking is
simply the replacement of the label and the OAM header; very simple and
very low complexity. Impossible today to do this with IP/MPLS instead of
T-MPLS.

Regards,
Maarten

-DWard

>>>>> different

---

From: "VISSERS Maarten" <[email-masked]>
Date: Tue, 8 Jan 2008 20:34:08 +0100

David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]] 
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: "VISSERS Maarten" <[email-masked]>
Date: Tue, 8 Jan 2008 16:11:55 +0100

Stewart,

Please review WD09r2:

----

CONCLUSION:

Regards,
Maarten

-----Original Message-----

Huub

Thank you

Stewart

---

From: "VISSERS Maarten" <[email-masked]>
Date: Wed, 9 Jan 2008 10:55:18 +0100

Monique,

As you have suggested, let's stay with technical OAM issues.
Your question is not a technical OAM question, it's about who should have done what and when and how many interpretations can we give to words in a report. As I have indicated, your company should have raised the issue in the IETF. Your company did not do this. So for this version of G.8114 this issue is closed.

I look forward to a technical OAM contribution from you.

Regards,
Maarten 

-----Original Message-----
From: Monique Morrow [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 10:49
To: VISSERS Maarten; Stewart Bryant; Huub van Helvoort
Cc: Q5/13; [email-masked]; pwe3
Subject: Re: [PWE3] Re: progress of G.8113 and G.8114

Maarten,

Let's focus please on the meeting report content as I have previously pointed out as not to cloud the issues here.

And please do highlight what is meant by Further, it may be useful to understand what is specifically meant by "Q5/13  is willing to work together with the IETF experts to resolve the issues."

Monique

On 1/9/08 1:30 AM, "VISSERS Maarten" <[email-masked]>
wrote:

> Monique,
> 
> Q.5/13 is not responsible for issues in IETF OAM tools. Q.5/13 is 
> responsible for ITU-T OAM tools, and has to review OAM tools that are 
> being proposed for inclusion in its Recommendations.
> 
> Q.5/13 did this review with respect to the proposal from two companies 
> to add BFD to the T-MPLS OAM recommendation. Q.5/13 concluded that the 
> BFD tool as specified in internet-drafts does not comply with the 
> transport network OAM requirements, and as such could not be added to 
> G.8114. Q.5/13 indicated its willingness to help IETF enhance this BFD 
> tool. As BFD is a tool under development in IETF, it is not Q.5/13's 
> responsibility to tell IETF that their BFD tool must be modified in 
> order to be used in the T-MPLS network. The proposal to add BFD to the 
> T-MPLS OAM set was not made by two companies (including your company), 
> and it is the responsibility of those companies to raise the issue in 
> IETF. If IETF would accept the issue that BFD has within T-MPLS 
> networks and would want to modify BFD such that it complies with the 
> transport network OAM requirements, then after a liaison from IETF to 
> Q.5/13 it would be possible for Q.5/13 to work together with the IETF to resolve the issues.
> 
> the IETF to enhance their BFD OAM tool to meet the transport network 
> OAM requirements in the last 9 months. That means that the issue of 
> expect ITU-T to wait when your and the other company did not work on this item for the last 9 months.
> 
> enhancements/extensions based on received contributions and the 
> results of the review of those contributions. Once IETF has decided to 
> "TD151R1(WP4) (editor): Draft new Y.17tor at the end of the 
> correspondence period as agreed in the December 2006 interim meeting.
> C.047 (Juniper Networks, Cisco): From the proposals, the first is 
> already covered by clause 13 of G.8110.1 Amendment 1 clause 13. Based 
> on the successive proposals clause 10 was revised. And the last 
> proposal was considered to be out of scope of this recommendation.
> Proposal 3.1 was not accepted for the following reasons: as stated in 
> the report of the joint meeting of Q5/13 with the colleagues from 
> Q9/15 and Q12/15, i.e. TD132(WP4) clause II.1, Q5/13 was requested to 
> develop Y.17tom as
> follows:
> 12/15. The document will be developed re-using the existing OAM mechanisms defined in G.8112 (i.e.
> subset of the mechanisms defined in Y.1711). Additionally new 
> mechanisms will be introduced, as appropriate, (e.g. Loopback) 
> re-using as much as possible what is currently defined in Y.1731"OAM 
> mechanisms for Ethernet based networks". Q.5/13 will also consider to 
> which extend results from IETF work on MPLS OAM can be taken into account in this activity.
> ³Additional new mechanisms shall be based on currently defined Y.1731 
> and IETF work on MPLS OAM². This was rejected because this is considered to be a working assumption.
> 
> The Q5/13 experts spent a significant amount of time considering the 
> IETF specified MPLS OAM for inclusion and concluded that these 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.
> C.050 (Fujitsu): Proposals in 2.1, 2.2, 2.3, 2.3, 2.4, 2.5 and 2.7 
> were accepted for drafting. It was agreed to reject proposals 2.6 
> after providing clarification of the CFM functionality.
> After drafting was completed on Y.17tor, uploaded as TD 189 (WP4), it 
> was proposed to go for consent. Two companies objected to this proposal."
> 
> 
> Now as to claims of  issues with current IETF mechanisms, has there 
> been a liaison sent to the IETF pointing these claims out and with a 
> request to work on them?
> 
> Further, it may be useful to understand what is specifically meant by 
> "Q5/13 is willing to work together with the IETF experts to resolve the issues."
> 
> If the IETF has NOT been notified, e.g via the liaison process, and as 
> per the IETF change process to "resolve an issue" how can it do so?
> 
>> (http://ties.itu.int/u/tsg13/sg13/xchange/wp4/q5/0704_Geneva/wd09R2-t
>> m
>> pl
>> - slides 3/4 present the T-MPLS atomic functions and the allocation 
>> of T-MPLS OAM to these functions for both the initial G.8112 and the 
>> - slide 7 illustrates the connectivity check mechanism like in slide 
>> 5 and identifies some issue:
>> be used as replacement of the MEGID/MEPID. Slide 16 presents some 
>> demultiplexing received BFD packets to the proper session". I.e. 
>> these fields a not meant to be used as MEGID/MEPID, these fields are 
>> used as a demultiplexing label. In T-MPLS the demultiplexing label is 
>> a label field in the label stack entry header of the frame (including 
>> in the OAM frames). The MyDiscriminator/YourDiscriminator fields are 
>> an unnecessary duplicate of the main label field. The conclusion was 
>> therefore that the absence of BFD can be used to represent the Loss 
>> of Continuity (LOC) defect, but that BFD does not support a 
>> in a transport network, and as such could not be included as a T-MPLS 
>> OAM frame. It would have been necessary to change the BFD frame 
>> structure and the BFD processing to create a transport network 
>> compliant BFD frame.
>> 
>> 
>> ----
>> 
>> run BFD on it". In absence of a control plane in T-MPLS, there will 
>> be no signalling capability as specified here.
>> 
>> exercises more aspects of the path.  One way to accommodate this is 
>> to address BFD packets based on the tunnel endpoints, assuming that 
>> they are numbered.". This paragraph confirms that is limited to loss 
>> of continuity detection, and is missing the ability to detect 
>> misconnections. This is confirmed in draft-ietf-bfd-base-06.txt, 
>> where it is stated that the BFD process discards BFD packets that 
>> have not the exact match.
>> 
>> 
>> CONCLUSION:
>>>>>>> requirement by providing a solution, solutions are out of scope for G.8113.
>>>>> with the generic transport requirement that they should be 
>>>>> confined to a single layer.
>>> 
>>> [hvh3] this was discussed by a break-out group and reported [hvh3] 
>>> in the Q5/13 meeting with all participants of the break-out [hvh3] 
>>> group present.

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 9 Jan 2008 17:01:01 +0200

Maarten and all,
I have looked up the PDF table you've attached to your message, and at
least one row - Security - looks highly suspicious to me.

This row states (unless I've missed something) that the security
function for ETH OAM a is based on the ME Level check, and that for
T-MPLS - on label stacking.  AFAIK, both ME levels and stacked labels
are transmitted in cleartext. 
I am neither a security expert nor a professional hacker, but it seems
to me that snooping upon and spoofing of such messages is pretty trivial
while the impact on the OAM function is potentially disastrous (consider
a malicious user spoofing CCM frames/ CV packets with the RDI flag set).
The BFD authentication procedures that use field-proven digital
signature techniques look much more robust to me.

To me as an individual (my company is not an ITU-T member), this
observation, combined with your statement from another email on this
thread:

<quote>
	As far as the participants understood the BFD specification, use
of BFD
	within T-MPLS instead of use of CV would have introduced a
security risk
	in T-MPLS networks. 
<end quote>

raises the question of overall soundness of the technical analysis that
has resulted in the decision to reject usage of BFD in T-MPLS: If
something so easy to catch has passed unnoticed, what else has been
possibly mis-judged? 

The gut feeling (triggered by David's emails on the same thread) that
the IETF BFD experts (either as a body or as individuals) have not been
consulted makes this question even more relevant.

Regardless of the formal procedures, IMHO the "right and proper" thing
to do would be to present your analysis (with sufficient technical
details) to the relevant IETF WGs, (BFD, MPLS and PWE3) and to ask for
their feedback. It would be definitely better to do so before taking the
decision, but late is better than never. 

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]] 
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]] 
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Wed, 9 Jan 2008 11:13:16 -0600

Maarten,

I think what Mark was saying is what we have been encouraging in ccamp -
if individuals/companies determine new applications (or identify
errors/implementation problems) for GMPLS (and here,
MPLS/T-MPLS/X-MPLS), it would greatly speed up the process for
consideration if they circulated their requirements/proposals on the
IETF lists. Of course, it also can be done more formally via an ITU
liaison (and the (G)MPLS change process). New network
applications/requirements (by individuals/companies/SDOs) are encouraged
on protocols for which IETF has responsibility for extensions.

Deborah

-----Original Message-----
VISSERS Maarten
Sent: Wednesday, January 09, 2008 8:05 AM
To: Mark Townsley

Mark,

Regards,
Maarten

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 12:43
To: VISSERS Maarten
Cc: Monique Morrow; Stewart Bryant; Huub van Helvoort; Q5/13;

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Wed, 09 Jan 2008 18:49:50 +0100

Yes, thank you Deborah.

Maarten, to further clarify... if during an ITU meeting there is a 
question, requirement, need, or objection with respect to an IETF 
protocol, it would help greatly if an action item was taken at the 
meeting for someone to take that question, requirement, need or 
objection to the IETF. My other point is that the person to do that, 
from the perspective of the IETF, can be anyone, and the overhead in 
doing so is very low. I'm not fully up to date on who did what and when 
with respect to BFD and the ITU, but it certainly seems like that if 
there were reasons that it didn't work for what the ITU needed, that the 
folks who could best articulate those limitations should be the ones to 
do so to the IETF so that they could be responded to one way or another 
(including, "nope, sorry, BFD wasn't designed to do that"). Kind of like 
the technical discussions between you and Dave right now. So, whether 
you intend to or not, you are participating in the IETF Standards 
Process already ;-)

- Mark

---

From: David Ward <[email-masked]>
Date: Wed, 9 Jan 2008 13:08:58 -0600

Maarten -

On Jan 9, 2008, at 12:36 PM, VISSERS Maarten wrote:

> Sasha,
>
> The security issue in BFD is related to the unability of BFD to  
> detect a
> misconnection/mismerge condition. BFD only allows the detection of a
> Loss Of Continuity (LOC) condition, not of a MisMerGe/MisMaTch (MMG/ 
> MMT)
> condition. WD09 presents this issue.
>

DW: Agreed that BFD itself doesn't complete this functionality in IP/ 
MPLS networks. The functionality is covered via a layered architecture.

> Hackers are no concern to the data plane of transport networks due to
> the security mechanism that are build into the architecture. Transport
> networks, including the SDH, OTN, ATM, Ethernet and T-MPLS networks,
> provide access to the network via UNI ports. Any frame received via  
> such
> UNI port, that meets the agreed bandwidth profile for the service is
> accepted and transported transparently to the far end UNI. When the
> customer exceeds the agreed bandwidth, the excess part is discarded.
>
> If in the future a T-MPLS UNI is added to the T-MPLS network, then the
> customer (or a hacker at the customer premise) may send T-MPLS OAM
> frames into the network. The T-MPLS MEP function at the edge of the
> network provides OAM filtering, to make sure that any customer OAM  
> frame
> is "demoted" and will not be visible as T-MPLS OAM inside the network.
> The transport network does not care if the frames arriving at the UNI
> are 100% OAM, 100% non-OAM, or a mix. All those frames are transported
> as non-OAM type frames through the network to the egress UNI in a
> transparent manner.
>
> If the hacker could bypass the UNI and have access to e.g. the access
> line, the transport network will provide encryption on this access  
> line;
> e.g. MAC-Sec should be deployed in those cases. If hackers could have
> access to the NNIs between the operator's offices, then the operator
> will also provide encryption on these NNIs.

DW: Towards this end, BFD uses the auth header to prevent an unknown  
peer from spoofing a session.

> Clause 13 of G.8110.1 describes some other cases and how T-MPLS  
> networks
> (like any other transport network, including SDH, ATM, OTN, Ethernet)
> deal with it.
>
> I hope this indicates that "spoofing of such messages is" NOT  
> "trivial"
> and that "the impact on the OAM function is" NON EXISTING. I.e. the
> opposite of your assumptions/gut feeling.
>

DW: I'd say that the assumptions of the attack vector of the networks  
is different and the architectural approach to solve the problem in  
transport and IP/MPLS specifications. The issue w/ the table is that  
it focuses on one protocol in the IP/MPLS solution vs the entire  
solution: VCCV + BFD + interaction w/ control/signaling protocols. I  
can see how folks would be confused with the comparison to one piece  
of the architecture.

-DWard

> Note that T-MPLS deploys the same security measures as Ethernet and  
> that
> T-MPLS OAM is a copy of Ethernet OAM.
>
> Regards,
> Maarten
>
>
> From: Alexander Vainshtein [mailto:[email-masked]]
> Sent: woensdag 9 januari 2008 16:01
> To: VISSERS Maarten
> Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
>> interworking? If so, great.
>
> discussed

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 9 Jan 2008 22:51:16 +0200

Maarten,
Thanks a lot for a very prompt response.

Unfortunately I cannot say it addresses my concerns, because I read it part of it as a statement that "Hackers shall never gain access to transport networks because these are transport networks; and if/when they gain such access, we shall employ some other tools that are not related to OAM". Personally I do not find this argument convincing; it would be interesting to hear the opinion of the IETF Security Directorate on this (or the opinoin of the ITU-T security experts' team if such a team exists there - I simply do not know).
 
And why have you decided that BFD is not capable of detecting mis-merge and mis-connection?
 
BFD packets carry both the identification of the intended receiver node (depends on the BFD profile), a local (within the receiving node) unique identifier of the BFD session ("Your identifier") and the the transmitter's identifier of the BFD session ("My identifier"). And BFD also has a built-in authentication mechanism which allows you to detect BFD packets that do not belong to the specific session; all you need is to configure a separate authentication key per connection and to report arrival of unauthenticated packets. So I would say that the basics for detection of mis-connection and mis-merge are there. 
 
Please note also that:

*	
	BFD resolves the mis-configuration problem because the receiver's identifier are allocated by the receiver and signaled to the transmitter during the BFD session setup. AFAIK, ETH OAM (and, by implication, T-MPLS OAM) rely exclusively on manual configuration in this regard and hence is prone to mis-configuration errors 
*	
	BFD can exist in many profiles, if T-MPLS REALLY requires something special it could added to the appropriate profile.

Regards,
                Sasha

________________________________

From: VISSERS Maarten [mailto:[email-masked]]
Sent: Wed 1/9/2008 8:36 PM
To: Alexander Vainshtein
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Sasha,

The security issue in BFD is related to the unability of BFD to detect a
misconnection/mismerge condition. BFD only allows the detection of a
Loss Of Continuity (LOC) condition, not of a MisMerGe/MisMaTch (MMG/MMT)
condition. WD09 presents this issue.

provide access to the network via UNI ports. Any frame received via such

network provides OAM filtering, to make sure that any customer OAM frame

line, the transport network will provide encryption on this access line;

Clause 13 of G.8110.1 describes some other cases and how T-MPLS networks
(like any other transport network, including SDH, ATM, OTN, Ethernet)
deal with it.

I hope this indicates that "spoofing of such messages is" NOT "trivial"
and that "the impact on the OAM function is" NON EXISTING. I.e. the
opposite of your assumptions/gut feeling.

Note that T-MPLS deploys the same security measures as Ethernet and that
T-MPLS OAM is a copy of Ethernet OAM.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: Monique Morrow <[email-masked]>
Date: Wed, 09 Jan 2008 17:43:09 -0800

Maarten,

You should be aware of this approach as members from your company
participate in the IETF.

Having said this and as you very well know, the contributions submitted in
April proposed that IETF OAM mechanisms be considered as an alternative to
TMPLS OAM.

Now as we are on the topic for BFD usage and applicability here, you will
agree that this is still an open discussion since the draft recommendations
in the ITU have not been approved.

Monique

---

From: Monique Morrow <[email-masked]>
Date: Wed, 09 Jan 2008 18:06:18 -0800

Huub et al,

To focus further and in the spirit of collaboration:

>From the SDO <IETF and IAB here> it has been very clear in terms of raising
issues via liaisons associated with TMPLS specifically and sourced from
various meetings including SG 15 interim meeting where IETF experts had been
engaged and from where there was an agreement reached on October 16 2007 as
follows:

"Experts from the standardization sector of ITU (ITU-T) and the Internet
Engineering Task Force (IETF) have agreed to recommend progression of
Transport-MPLS (T-MPLS) standards work in a way that ensures compatibility,
consistency, and coherence of MPLS technology when used in transport
networks. The recommended approach, which recognizes and leverages ITU-T and
IETF design expertise and authority, is expected to resolve concerns raised
regarding usage of common Ethertypes for IETF MPLS and T-MPLS when running
over an Ethernet backbone. Broader review and approval of the proposal by
the two standards bodies is expected in the coming months.

The experts proposed in a joint statement that "The IETF and ITU-T will work
in close collaboration on T-MPLS" and that "a joint working team of experts
from the IETF and ITU-T be established to propose how to progress the
various aspects of the requirements, solutions, and architecture for the
T-MPLS work." The initial goal of the working team will be to examine T-MPLS
work, and foster "an agreement on leadership roles and the modifications
necessary to develop an architecture that it is compatible, coherent and
consistent between both transport and IETF MPLS technologies."

Yoichi Maeda, Chairman of ITU-T's Study Group 15, home of the T-MPLS work
said: "This type of agreement is a characteristic of the spirit of
cooperation that exists between ITU-T and IETF. Both organizations
understand that in order to meet the needs of industry it's imperative to
quickly resolve differences and avoid duplication of work."

"Future work," the proposal states, "will be progressed by first analyzing
the requirements and desired functionality." Since T-MPLS utilizes MPLS
functionality extensively, the experts recommend that, "The IETF Standards
Process will be used for extensions or modifications of IETF MPLS
Technology." It was clearly noted that there are aspects of the problem
space that lie outside the domain of expertise in the IETF or straddle both
organizations, e.g., management of transport equipment, and some aspects of
OAM and survivability. The working team will be tasked to help identify
which of these aspects are best standardized in IETF RFCs and which in ITU-T
Recommendations.

T-MPLS has been under development for three years in ITU-T with four
specifications published, including an architecture document, a
network-to-network interface (NNI), an equipment specification and a
protection switching document. T-MPLS draws extensively on IETF MPLS, a
foundation of more than 50 RFCs published by the IETF MPLS and PWE3 Working
Groups over the last eight years."

Huub, it is this alignment we are seeking to achieve here -- and to assert
that the TMPLS OAM design discussion is closed - certainly is not in the
spirit of the agreement reached between the ITU and the IETF in October
2007.

I do believe that the topic is very much open for discussion here.

Monique

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 10 Jan 2008 07:54:43 -0500

On Jan 10, 2008, at 7:13 AM, VISSERS Maarten wrote:

> see inline..
> Sent: woensdag 9 januari 2008 20:09
> To: VISSERS Maarten
> Cc: David Ward; Alexander Vainshtein; Q5/13; pwe3; [email-masked] 
> ;
> Stewart Bryant
>> detect
>> a misconnection/mismerge condition. BFD only allows the detection  
>> of a
>
> [mv] Can you describe how this layered architecture functions. What  
> type
> of layers are used for this?

	Maarten, speaking as a network operator, I can tell you that there
are certainly cases where you indeed want interaction between your OAM  
tools
and your control plane. Strictly speaking, this is not one of my  
requirements,
although there are cases where you do want this to be the case as well.

	--Tom

> <..>
> [mv] The table is created from the transport network viewpoint. In a
> transport network OAM must be independent of the control plane and OAM
> functions must not depend on control/signalling protocols. As such the
> table should not include any interactions w/ control/signalling
> protocols.
>
> [mv] This table must as such not be used to compare transport network
> and IP/MPLS network OAM mechanisms. A table that compares transport
> entwork with IP/MPLS network OAM mechanisms must as indicated by you
> also include the interactions w/ control/signalling protocols. Let's
> work on such extended version of this table.
>
> Regards,
> Maarten

---

From: "VISSERS Maarten" <[email-masked]>
Date: Wed, 9 Jan 2008 19:36:46 +0100

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

> accessFrom [email-masked] Thu Jan 10 08:12:58 2008
Content-class: urn:content-classes:message
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114
Date: Wed, 9 Jan 2008 19:36:46 +0100
From: "VISSERS Maarten" <[email-masked]>
To: "Alexander Vainshtein" <[email-masked]>
Cc: Q5/13 <[email-masked]>, [email-masked], pwe3 <[email-masked]>,
	David Ward <[email-masked]>, Stewart Bryant <[email-masked]>

Sasha,

as non-OAM type frames through the network to the egress UNI i and T-MPLS in the metro/core hybrid VLAN/T-MPLS Channel 

...snip ...

-DWard

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 13:13:16 +0100

David,

see inline.. 

-----Original Message-----
From: David Ward [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 20:09
To: VISSERS Maarten
Cc: David Ward; Alexander Vainshtein; Q5/13; pwe3; [email-masked];
Stewart Bryant

Maarten -

On Jan 9, 2008, at 12:36 PM, VISSERS Maarten wrote:

> Sasha,
>
> The security issue in BFD is related to the unability of BFD to detect

> a misconnection/mismerge condition. BFD only allows the detection of a

[mv] Can you describe how this layered architecture functions. What type
of layers are used for this?

<..>

Regards,
Maarten

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 10 Jan 2008 09:02:52 -0500

Are you familiar with how ethernet access works (is configured)
in modern networks using pseudowires?  This is precisely what I am
referring to.

	--Tom

> Tom,
>
> May I ask you to describe such cases and the associated layered
> architecture that David is referring to.
>
> Thanks,
> Maarten
>
> Sent: donderdag 10 januari 2008 13:55
> To: VISSERS Maarten
> Cc: David Ward; Q5/13; Alexander Vainshtein; pwe3; t-mpls- 
> [email-masked]
>> Cc: David Ward; Alexander Vainshtein; Q5/13; pwe3;
>> [email-masked] ; Stewart Bryant
>> type of layers are used for this?
>
> 	Maarten, speaking as a network operator, I can tell you that
> there are certainly cases where you indeed want interaction between  
> your
> OAM tools and your control plane. Strictly speaking, this is not one  
> of
> my requirements, although there are cases where you do want this to be
> the case as well.
>
> 	--Tom
>
>
>
>>
>> <..>
>>
>>> networks (like any other transport network, including SDH, ATM, OTN,
>>> Ethernet) deal with it.
>>>

---

From: "Greg Mirsky" <[email-masked]>
Date: Thu, 10 Jan 2008 06:21:00 -0800

Dear Maarten,
couple question to clarify. Hope I'm not too far behind the discussion.
VM>> Any frame received via such
UNI port, that meets the agreed bandwidth profile for the service is
accepted and transported transparently to the far end UNI. When the
customer exceeds the agreed bandwidth, the excess part is discarded.
GIM>> Does that mean that data have only CIR and no EIR?

VM>> Any frame received via such
UNI port, that meets the agreed bandwidth profile for the service is
accepted and transported transparently to the far end UNI. When the
customer exceeds the agreed bandwidth, the excess part is discarded.
GIM>> Does that mean that in T-MPLS network no customer's MIP can exist?

	Kind regards,
		Greg

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]] 
Sent: Wednesday, January 09, 2008 10:37 AM
To: Alexander Vainshtein
Cc: Q5/13; [email-masked]; pwe3; David Ward; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 16:37:20 +0100

Deborah,

Thank you for clarifying this issue. As indicated, I do not have a need
to deploy BFD as CC tool in T-MPLS as it does not provide bakcward
compatibility with G.8112. Also Q.5/13 does not have an identified need.
As such neither from my side, nor from Q.5/13 side there is a new
network application for BFD required. 

Note that this does not imply that Q.5/13 is not willing to add in
future a modified version of BFD that complies with the G.8113
requirements to the T-MPLS OAM toolset. Once Q.5/13 has a more complete
understanding of the interworking issues around MPLS PW and T-MPLS
Channel, it might well be that there is such new application identified.
At such time this new application will contributed to the IETF lists.

If individuals see such new application already today (i.e. before the
interworking issues have been explored fully in our ITU/IETF
cooperation), then it is up those individuals to circulate this new
application and its requirements on the IETF lists. Such would indeed
speed up the process for consideration within IETF. If such is done, I
am offering my support to explore this new application.

Regards,
Maarten

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 18:13
To: VISSERS Maarten; Mark Townsley
Cc: Monique Morrow; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten,

Deborah

-----Original Message-----

Mark,

Regards,
Maarten

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 12:43
To: VISSERS Maarten
Cc: Monique Morrow; Stewart Bryant; Huub van Helvoort; Q5/13;

- Mark

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 21:19:24 +0100

Sasha,
 
See inline...

From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 21:51
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten,

Unfortunately I cannot say it addresses my concerns, because I read it
part of it as a statement that "Hackers shall never gain access to
transport networks because these are transport networks; and if/when
they gain such access, we shall employ some other tools that are not
related to OAM". Personally I do not find this argument convincing; it
would be interesting to hear the opinion of the IETF Security
Directorate on this (or the opinoin of the ITU-T security experts' team
if such a team exists there - I simply do not know).
 
[mv] Opinions on transport network security matters should be expressed
by the transport network operators. Security issues associated with the
transport network's data plane (forwarding,oam,protection) should be
addressed within the lead study group for transport networks in ITU-T;
i.e. SG15. 
 
[mv] So far security issues are not a topic in SG15. That typically
implies that there are no security issues that require changes to the
normal designs that SG15 applied to their transport technologies (PDH,
SDH, ATM, OTN, Ethernet and T-MPLS). Please do not suggest that there
are security issues in transport networks without presenting a specific
description of such issue.
 
And why have you decided that BFD is not capable of detecting mis-merge
and mis-connection?  
 
[mv] I concluded this after reviewing BFD defintion and processing
specs.
 
BFD packets carry both the identification of the intended receiver node
(depends on the BFD profile), a local (within the receiving node) unique
identifier of the BFD session ("Your identifier") and the the
transmitter's identifier of the BFD session ("My identifier"). And BFD
also has a built-in authentication mechanism which allows you to detect
BFD packets that do not belong to the specific session; all you need is
to configure a separate authentication key per connection and to report
arrival of unauthenticated packets. So I would say that the basics for
detection of mis-connection and mis-merge are there.  
 
[mv] I am are talking about deployment of BFD in the transport network
(T-MPLS) in which there is no IP. The BFD version would be the one
currently described for use with VCCV (draft-ietf-pwe3-vccv-bfd-00) in
which the IP/UDP headers are not present (type 0x10/0x20). As such,
there are only the MyDiscriminator/YourDiscriminator identifiers, which
are locally assigned when a BFD session is activated. Via configuration
by the OSS, the two MEPs at the end of a T-MPLS connection can be
configured with the RemoteDiscriminator value, which value should be
inserted in the YourDiscriminator field of the generated BFD control
packet. Or, the MEP with the active mode BFD will generate the first BFD
control packet with a zero YourDiscriminator, and will use after
receiving the reply from the far end MEP the MyDiscriminator field value
as RemoteDiscriminator and insert it in the next BFD control packets
YourDiscriminator field. The far end MEP accepts the BFD control packet
with YourDiscriminator set to zero on the basis that it is received by
the MEP.
According to section 6.8.6 of bfd-base-06 the following will happen at
the receiving MEP: "If the Your Discriminator field is nonzero, it MUST
be used to select the session with which this BFD packet is associated.
If no session is found, the packet MUST be discarded."
 
[mv] The label that identifies the T-MPLS connection in the path or
channel layer, is attached to the BFD control packet of that path or
channel layer connection. This label will deliver the BFD control packet
to the MEP at the end of the connection. The BFD proces in this MEP will
process the received BFD control packets as specified in section
6.8.6/bfd-base-06. If the YourDiscriminator field value in the BFD
packet is not the LocalDiscriminator value, then the packet is
discarded. If the value is the equal to the LocalDiscriminator value,
then the BFD packet is accepted.
 
[mv] When there are two connections merged, then the MEP at the end of
the connection will receive BFD packets, which do not fit (most likely)
the LocalDiscriminator value; consequently these packets are discarded
and ignored. This should not happen in a transport network; this packet
should be stored (to be read by the OSS), a Mismerge defect should be
detected, traffic forwarding should be blocked and AIS should be
inserted. 
 
[mv] When authentication is used, the discarding of the intruding BFD
control packet will be performed on the basis of an authentication
failure as specified also in section 6.8.6/bfd-base-06.
 
[mv] Note that the label will deliver the BFD control packet to the MEP
at the end of the connection. This MEP has a single BFD process. An
interface will typically have multiple parallel connections being
terminated on that interface card. Each of the MEPs at the end of such
connection has a single BFD process. The BFD control packets arriving at
the interface will be delivered to each MEP on the basis of the label in
the BFD control packet. The Discriminator fields are as such
unnecessary; i.e. these fields do not need to be used as demultiplexer
as described in section 4.1/bfd-base-06.

[mv] Unidirectional point to multipoint connections will exist in
T-MPLS. In this case there is one Source MEP and a number of Sink MEPs.
The T-MPLS CV is able to check the continuity and connectivity of such
p2mp connection. BFD is not able to function in this case. There is only
a single direction of transport present; i.e. no return direction.
Furthermore, the LocalDiscriminator values are selected at random per
node. As there is only one source MEP which generates one BFD control
packet that is broadcasted to all sink MEPs, there is only one value for
the YourDiscriminator field. The LocalDiscriminator value must in this
case thus be selected by the OSS and configured in all the sink MEPs.

[mv] Besides this basic processing between two or more MEPs in a
connection, it is possible to have more than one set of MEPs active in a
connection. Each set belongs to a Maintenance Entity Group (MEG) level.
Like in Ethernet and OTN, up to eight MEG levels are supported in T-MPLS
connections. Two or more MEPs may be located in the same interface port
(i.e. one after the other, as in e.g. Ethernet OAM is illustrated),
while their peer MEPs are in different nodes. It must be possible to run
T-MPLS OAM in each of the MEG levels. In G.8114 this is realised by
using the MEG Level (MEL) field. If BFD is used in T-MPLS, then BFD
control packets must support such MEL field and the associated OAM
Filtering (incrementing/decrementing this MEL field value at MEP Source
and MEP Sink functions passed through).
 
Please note also that:

*	
	BFD resolves the mis-configuration problem because the
receiver's identifier are allocated by the receiver and signaled to the
transmitter during the BFD session setup. AFAIK, ETH OAM (and, by
implication, T-MPLS OAM) rely exclusively on manual configuration in
this regard and hence is prone to mis-configuration errors  

[mv] If you let the receiver signal it's identifier to the transmitter
during BFD seesion setup, and if there is no authentication, then if the
connection is set up between the wrong endpoints, the receiver will
accept the BFD session request without complaining. The right action
would have been to alarm this misconnection case. Note that there are
typically multiple connections to be set up in a short period and
multiple MEPs may already be configured to become part of connections.
 
[mv] If you deploy authentication, then the receiver must have been
configured by the OSS with the right key. If the connection is set up
between the wrong endpoints, then the BFD session will not come up and
you get an alarm. to get this alarm, you rely on the (manual)
configuration of this key, which is as prone to mis-configuration errors
as configuration of a MEGID/MEPID. 

*	
	BFD can exist in many profiles, if T-MPLS REALLY requires
something special it could added to the appropriate profile.  

[mv] I have the feeling that it is a bit more than a profile. Ofcourse
if we complicate the BFD process enough, we can always shut down half of
the processing to fit it to its environment. But that is adding
unnecessary complexity to both IP/MPLS and T-MPLS. Let's not do that.
 
REgards,
Maarten

 Regards,
                Sasha

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 16:37:20 +0100

Deborah,

Regards,
Maarten

-----Original Message-----
From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 18:13
To: VISSERS Maarten; Mark Townsley
Cc: Monique Morrow; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten,

Deborah

-----Original Message-----

Mark,

Regards,
Maarten

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 12:43
To: VISSERS Maarten
Cc: Monique Morrow; Stewart Bryant; Huub van Helvoort; Q5/13;

- Mark

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 21:19:24 +0100

Sasha,
 
See inline...

Maarten,

 

 

 

 

Please note also that:

*	

*	

REgards,
Maarten

 Regards,
                Sasha

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 16:43:25 +0100

Mark,

Thank you. As I indicated to Deborah and in previous emails, I can not
formally raise this issue in IETF, but if this is raised by somebody
else I am more than happy to offer my help in the technical analysis and
solution finding. As you wrote, I am effectively doing this already in a
private correspondence.

Regards,
Maarten

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 18:50
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: VISSERS Maarten; Q5/13; Monique Morrow; pwe3; [email-masked];
Stewart Bryant

Yes, thank you Deborah.

- Mark

BRUNGARD, DEBORAH A, ATTLABS wrote:
> Maarten,
>
> I think what Mark was saying is what we have been encouraging in ccamp

> - if individuals/companies determine new applications (or identify 
> applications/requirements (by individuals/companies/SDOs) are 
> encouraged on protocols for which IETF has responsibility for
extensions.
> Of VISSERS Maarten

> several issues. I am only not the one that proposes to use BFD in 
> T-MPLS networks. So again, I have no issues with the use of BFD in 
> IP/MPLS networks.

> That in my understanding leaves the responsibility to raise in IETF 
> the issue that BFD has when it has to operate in a T-MPLS network to 

> else, can bring any issue you like to the IETF via a simple email 
> (just as we are exchanging now). The overhead of this initial step is 
> so small that the only reasons I can think of for anyone not having 
> taken this step is ignorance, lack of will, or perhaps the expectation

> that it was someone else's responsibility. It sounds to me like you 
> believe raising this issue was someone else's responsibility rather 
> than your own. In fact, it is the responsibility of the one who 
> desires to make changes to IETF protocols to bring those change 
> requests to the IETF - I don't think we could expect to function as an
organization otherwise.

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 16:43:25 +0100

Mark,

Regards,
Maarten

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: woensdag 9 januari 2008 18:50
To: BRUNGARD, DEBORAH A, ATTLABS
Cc: VISSERS Maarten; Q5/13; Monique Morrow; pwe3; [email-masked];
Stewart Bryant

Yes, thank you Deborah.

- Mark

extensions.

organization otherwise.

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 16:44:17 +0100

Tom,

I am not familiar how this is done. Please provide a description.
Thanks,
Maarten 

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: donderdag 10 januari 2008 15:03
To: VISSERS Maarten
Cc: David Ward; Q5/13; Alexander Vainshtein; pwe3; [email-masked]
Subject: Re: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

	--Tom

>>> a misconnection/mismerge condition. BFD only allows the detection of

>>> a

> 	Maarten, speaking as a network operator, I can tell you that
there 

> tools and your control plane. Strictly speaking, this is not one of my

> requirements, although there are cases where you do want this to be 
> the case as well.
>
> 	--Tom
>
>
>
>>
>> <..>
>>

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 14:29:09 +0100

Tom,

Thanks,
Maarten 

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: donderdag 10 januari 2008 13:55
To: VISSERS Maarten
Cc: David Ward; Q5/13; Alexander Vainshtein; pwe3; [email-masked]
Subject: Re: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

	Maarten, speaking as a network operator, I can tell you that
there are certainly cases where you indeed want interaction between your
OAM tools and your control plane. Strictly speaking, this is not one of
my requirements, although there are cases where you do want this to be
the case as well.

	--Tom

---

From: "VISSERS Maarten" <[email-masked]>
Date: Thu, 10 Jan 2008 18:24:00 +0100

Greg,

See inline.. 

-----Original Message-----
From: Greg Mirsky [mailto:[email-masked]] 
Sent: donderdag 10 januari 2008 15:21
To: VISSERS Maarten; Alexander Vainshtein
Cc: Q5/13; [email-masked]; pwe3; David Ward; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Dear Maarten,

VM>> Any frame received via such UNI port, that meets the agreed
bandwidth profile for the service is accepted and transported
transparently to the far end UNI. When the customer exceeds the agreed
bandwidth, the excess part is discarded.
GIM>> Does that mean that data have only CIR and no EIR?

[mv] The data can be CIR only, EIR only or CIR/EIR as per SLA.

VM>> Any frame received via such UNI port, that meets the agreed
bandwidth profile for the service is accepted and transported
transparently to the far end UNI. When the customer exceeds the agreed
bandwidth, the excess part is discarded.
GIM>> Does that mean that in T-MPLS network no customer's MIP can exist?

[mv] Customer MIPs can exist. Those are located before the Traffic
Conditioning function that checks the bandwidth. E.g. for an Ethernet
customer service, you find first the ETH_MIP function, then the ETH_TCS
(traffic conditioning) function and then the mapping function that
encapsulates (and optionally bundles) VLAN signal(s) into the network
service layer signal (e.g. SDH VC-n, OTN ODUk, MPLS PW, T-MPLS Channel,
Ethernet VLAN (Q-in-Q)).

[mv] In a service multiplexed interface, you can get two Ethernet MIP
functions; in this case there is a MAC Relay function between the
ETH_MIP connected to the physical interface and the ETH_MIP connected to
the traffic conditioning function.

Regards,
Maarten

	Kind regards,
		Greg

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Wednesday, January 09, 2008 10:37 AM
To: Alexander Vainshtein
Cc: Q5/13; [email-masked]; pwe3; David Ward; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: "VISSERS Maarten" <[email-masked]>
Date: Mon, 14 Jan 2008 08:21:00 +0100

My previous email touched upon the presence of unidirectional T-MPLS
connections and the requirement to monitor the continuity and
connectivity of such unidirectional connections. Unidirectional
connections do not have a return path, and as such a bidirectional
Failure Detection (BFD) will not function in such cases. What is
required is a Unidirectional Failure Detection (UFD), which is capable
to monitor a single direction of transmission.
 
If you analyse the failure detection mechanisms in transport networks,
you will notice that pro-active monitoring is based upon unidirectional
failure detection mechanisms. A number of those UFD mechanisms are e.g.:
- Loss of Signal (LOS), Loss of Continuity (LOC), Unequipped (UNEQ),
Open Connection Indication (OCI)
- Trace Identifier Mismatch (TIM), MisMaTch (MMT), MisMerGe (MMG),
Unexpected MEP (UNM)
- Payload Mismatch (PLM)
- Locked (LCK)
 
TIM,MMT,MMG,UNM failures are associated (on request) with the Accepted
TTI, MEGID or MEPID; i.e. with the identifier value of the remote MEP
that is unexpectedly connected to the local MEP.
 
PLM failutes are associated (on request) with the Accepted Payload
Type/Signal Label (in general the Protocol ID of the payload that is
unexpectedly received at the local MEP and which this MEP is able or not
configured to support).
 
In transport networks, the monitoring of unidirectional and
bidirectional connections is based on the unidirectional failure
detection mechanisms. I.e. one failure detection mechanism (UFD) fits
both connection types.
 
Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of
VISSERS Maarten
Sent: donderdag 10 januari 2008 21:19
To: Alexander Vainshtein
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Sasha,
 
See inline...

Maarten,

 

 

 

 

Please note also that:

*	

*	

REgards,
Maarten

 Regards,
                Sasha

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard

---

From: <[email-masked]>
Date: Mon, 14 Jan 2008 15:46:20 -0000

Connections are single-source, unidirectional and constraining
forwarding constructs (under defect-free conditions), ie connections can
only be p2p and p2mp in nature.  So Maarten is right that the defect
detection/handling OAM in co mode networks needs to be
unidirectional.........and for a whole raft of reasons, not just the
ones pointed out below.
 
Given this, it is somewhat surprising to note that a BDI function has
been piggy-backed in a CV OAM pkt in G.8114.  Whilst this can work OK
for p2p connections which can be made bidirectionally symmetric this
makes no sense at all for p2mp connections which cannot be made
bidirectionally symmetric.  
 
A related point regarding bidirectional symmetry, and one which is not
mentioned below, is that diagnostic OAM that is of a request/response
nature (eg LB) is unlikely to work as expected when we have traffic
leaking from one connection into another one.  Unintended replication
defects do know they have to be 'well-behaved' in always providing
symmetric bidirectional connectivity....indeed it would be folly to
assume this.  In co-ps mode layer network based on label-swapping,
traffic can leak out of one connection into another one, and this will
be undetectable unless one is monitoring ALL the connections
(irrespective of their importance) in the network at the sinks for the
correct SA in CV pkts.  Moreover, any OAM that is of a request/response
nature cannot be trusted to trace-out such defects.......there will not
be a return path.  So any notion that G.8114 LB OAM pkts can somehow be
relied upon to trace out unintended replication/merging defects is just
plain wrong.
 
A more general observation here is we can't treat cl-ps OAM, co-ps OAM
and co-cs OAM as though they can be somehow all be made the same.
G.8114 seems to have an underlying notion that if we make the OAM of
Ethernet (cl-ps) and T-MPLS (co-ps) the same then this means we can can
interwork these technologies.  This is an amazingly naive view.  If one
is seriously going to tackle the topic of technology interworking for
any pair of technologies (and if the technologies don't even belong to
the same mode then stop immediately as there will be large functional
mismatches) then the place to start is with the 'application to 1st
layer network adaptation functions'.....because if one has NOT sorted
this out then one can forget all the rest of the DP/CP components (where
OAM is only one DP aspect here anyway).   
 
I understand (from Hubb) that at our (BT) request all notion of
Eth/T-MPLS i/w has been removed from G.8114.  I do hope this is the
case.
 
regards, Neil
 
-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]] 
Sent: 14 January 2008 07:21
To: Alexander Vainshtein
Cc: Q5/13; [email-masked]; pwe3
Subject: [PWE3] Uni- and Bi-directional Failure Detection (UFD,BFD)
[was: Re: progress of G.8113 and G.8114]

 

 
Regards,
Maarten

  _____  

Sasha,
 
See inline...

  _____  

Maarten,

 

 

 

 

Please note also that:

*	

 

*	

 
REgards,
Maarten

 Regards,
                Sasha

  _____  

Sasha,

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: woensdag 9 januari 2008 16:01
To: VISSERS Maarten
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant; David Ward
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

Maarten and all,

<quote>

My 2c.
                    Sasha Vainshtein

-----Original Message-----
From: VISSERS Maarten [mailto:[email-masked]]
Sent: Tuesday, January 08, 2008 9:34 PM
To: David Ward
Cc: Q5/13; pwe3; [email-masked]; Stewart Bryant
Subject: RE: [T-mpls-dt] RE: [PWE3] Re: progress of G.8113 and G.8114

 David,

Regards,
Maarten

-----Original Message-----
From: David Ward [mailto:[email-masked]]
Sent: dinsdag 8 januari 2008 18:52
To: VISSERS Maarten
Cc: David Ward; Stewart Bryant; Huub van Helvoort; Q5/13;

Maarten -

On Jan 8, 2008, at 11:22 AM, VISSERS Maarten wrote:

....snip...

...snip ...

-DWard