Subject: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt

From: Loa Andersson <[email-masked]>
Date: Tue, 10 May 2011 17:43:04 +0200

Working Group,

this is to start a two week working group last call on

draft-ietf-mpls-tp-li-lb-01.txt

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

This working group last call ends on May 25th.

/Loa

for the mpls wg co-chairs

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 May 2011 17:32:31 +0100

However, to remove a MEP from Loopback mode, the sending MEP MUST set
    the TTL to the exact number of hops required to reach the MEP (if the
    TTL were set higher, the Loopback removal message would be looped
    back toward the sender). It is RECOMMENDED that the TTL be set to the
    exact number of hops required to reach the MEP.

SB>  Surely that MUST be a MUST not a  RECOMMENDED, since any other
SB>  value would not work.

SB>  I am surprised that we don't have a timer that gets you out of
SB>  jail by removing the LB if you can't get an unloopback command
SB>  to the MEP/MIP

SB>  The data section should emphasis that everything on the LSP
SB>  including OAM gets looped back (you have this as a side remark
SB>  above but it warrants emphasizing.

SB>  Can you remind me what happens when protection switching
SB>  occurs? Does LB at a MEP continue on the protected path? If
SB>  so how does the new TTL get learned?

SB>  What is the state of the TTL learning work that we proposed
SB>  right at the start of the project? i.e. how do we know
SB>  the exact TTL to use?

- Stewart

---

From: Sami Boutros <[email-masked]>
Date: Tue, 10 May 2011 17:40:16 -0700

>SB>  value would not work.

Sami: Will update the text as follow and remove the last sentence.
"However, to remove a MEP from Loopback mode, the sending MEP MUST 
set the TTL to the exact number of hops required to reach the MEP (if 
the TTL were set higher, the Loopback removal message would be 
looped   back toward the sender). "

>SB>  jail by removing the LB if you can't get an unloopback command

Sami: But for how long will that timer run? are you thinking to put 
in the request for how long you stay in loopback to the MEP/MIP?

>SB>  above but it warrants emphasizing.

Sami: Will clarify that OAM packets not intercepted by TTL expiry 
will be looped back

>SB>  the exact TTL to use?

Sami: This proposal is no longer progressing, the exact TTL to use 
will be set by the operator before and after protection switching.

Thanks,

Sami

---

From: [email-masked]
Date: Wed, 11 May 2011 10:11:59 +0800

hi, all
for this draft, I have a question for Loopback function.
in last ietf meeting, IMO, the author sami said this 
Loopback function is to loopback anything. for MEP point of 
a LSP, if it is set to Loopback state, it will loopback all received
packets including any OAM packet. if so, how to detect mis-connectivity or
mis-configuration for the LSP?
in addtion, if it happen mis-connectivity, maybe other LSP packet be 
transported to 
the MEP , and the mep point will still Loopback the wrong packet to peer 
mep point,
can it affect performance statistics or measurement on the peer mep point?

B.R.
liu

Loa Andersson <[email-masked]> 
发件人:  [email-masked]
2011-05-10 23:43

收件人
"[email-masked]" <[email-masked]>
抄送
Ross Callon <[email-masked]>, MPLS-TP ad hoc team 
<[email-masked]>, [email-masked]
主题
[mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt

Working Group,

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 11 May 2011 11:57:06 +0100

On 11/05/2011 01:40, Sami Boutros wrote:
> "However, to remove a MEP from Loopback mode, the sending MEP MUST set 
> back toward the sender). "
>
>
> Sami: But for how long will that timer run? are you thinking to put in 
> the request for how long you stay in loopback to the MEP/MIP?

Yes, I was thinking of a 32bit timer (in say ms), refreshed before 
expiry (i.e. up to 100 days)

The condition that you are guarding against is that the TTL number gets 
screwed up and you can't get an unloop delivered.

Remember that there are situations where the LSP itself may be the only 
way to communicate at the control plane and by going into lookback you 
may have sawn off the branch you are sitting on.

> Sami: Will clarify that OAM packets not intercepted by TTL expiry will 
> be looped back
>
Ah, but remember this all needs to work for MPLS and MPLS-TP, and with 
MPLS you may know TTL a priori.

- Stewart

---

From: Sami Boutros <[email-masked]>
Date: Wed, 11 May 2011 22:03:17 -0700

To check for mis-connectivity/mis-configuration, 
you need a cc-cv function not a loopback function.

The loopback function can be used for loss/delay 
measurements, and this will be addressed in the delay/loss draft.

Thanks,

Sami
At 07:11 PM 5/10/2011, [email-masked] wrote:

>in addtion, if it happen mis-connectivity, maybe 
>other LSP packet be transported to
>the MEP , and the mep point will still Loopback 
>the wrong packet to peer mep point,
>can it affect<app:ds:performance> performance 
><app:ds:statistics>statistics or measurement on the peer mep point?
>
>B.R.
>liu
>
>
>
>
>
>
>·¢¼þÈË:  [email-masked]
>
>2011-05-10 23:43
>ÊÕ¼þÈË
>³ËÍ
>Ross Callon <[email-masked]>, MPLS-TP ad 
>hoc team <[email-masked]>, [email-masked]
>Ö÷Ìâ
>ZTE Information Security Notice: The information 
>contained in this mail is solely property of the 
>sender's organization. This mail communication 
>is confidential. Recipients named above are 
>obligated to maintain secrecy and are not 
>permitted to disclose the contents of this communication to others.
>This email and any files transmitted with it are 
>confidential and intended solely for the use of 
>the individual or entity to whom they are 
>addressed. If you have received this email in 
>error please notify the originator of the 
>message. Any views expressed in this message are 
>those of the individual sender.

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 12 May 2011 07:36:33 +0200

Sami, hi

My understanding is that the question that was asked is how do you use the cc-cv function to check for mis-connectivity if it is being looped-back.

Truth be told that during the period of loopback you apparently cannot check the e2e path for mis-connectivity, and the operator needs to take this into consideration.  But since the path is not transferring data e2e (it is looping everything back) it is by definition not connected e2e.

What is true is what Sami states this functionality should be used to setup a loss/delay measurement on a segment of a path, and it should be used only for limited periods.

Just my 2cents,

yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Sami Boutros
Sent: Thursday, May 12, 2011 8:03 AM
To: [email-masked]; Loa Andersson
Cc: Ross Callon; [email-masked]; MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt

To check for mis-connectivity/mis-configuration, you need a cc-cv function not a loopback function.

The loopback function can be used for loss/delay measurements, and this will be addressed in the delay/loss draft.

Thanks,

Sami

hi, all 
for this draft, I have a question for Loopback function. 
in last ietf meeting, IMO, the author sami said this 
Loopback function is to loopback anything. for MEP point of 
a LSP, if it is set to Loopback state, it will loopback all received 
packets including any OAM packet. if so, how to detect mis-connectivity or 
mis-configuration for the LSP? 
in addtion, if it happen mis-connectivity, maybe other LSP packet be transported to 
the MEP , and the mep point will still Loopback the wrong packet to peer mep point, 
can it affect performance <app:ds:performance>  statistics <app:ds:statistics>  or measurement on the peer mep point? 

B.R. 
liu 

2011-05-10 23:43 

ÊÕ¼þÈË

³ËÍ

Ross Callon <[email-masked]>, MPLS-TP ad hoc team <[email-masked]>, [email-masked] 

Ö÷Ìâ

Working Group,

/Loa

-- 

 
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail communication
is confidential. Recipients named above are obligated to maintain secrecy
and are not permitted to disclose the contents of this communication to
others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
originator of the message. Any views expressed in this message are those
of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 12 May 2011 09:01:31 +0100

What is the test that needs to be made and exactly when?

Let's talk MEPs first.

You could get a cc-cv pkt to the remote end by sending it with the right 
TTL, and you can receive any cc-cv pkt from the remote end by examining 
all received pkts.

To do cc-cv during a LB any diagnostics you run in LB need to take that 
into account and that will complicate the diagnostics.

I do not see how you could ever do it with MIPs.

I would think that most users would be content to verify the LSP using 
traceroute/ping/cc-cv then to set LB and run the tests then clear LB and 
re-verify as above.

The above procedure is an applications issue and not a protocol issue, 
and thus does not belong in this document.

The only case that does not seem to be covered is a problem that occurs 
during the LB, but that is a low probability event, and since there is 
no user data being carried  on the LSP under LB user service will not be 
disrupted. In the case of data in the LSP under LB leaking as a result 
of a problem, that is the responsibility of the other LSP to police.

Note that by examining the data received during a LB text the initiator 
of the LB is able to verify that it is their data that is being looped 
back which is equivalent to running a cc-cv.

Thus I do not think that there is any practical problem that needs to be 
addressed in the protocol.

- Stewart

On 12/05/2011 06:03, Sami Boutros wrote:
> The loopback function can be used for loss/delay measurements, and 
> this will be addressed in the delay/loss draft.
>
> Thanks,
>
> Sami
>> can it affectperformance <app:ds:performance>statistics 
>> <app:ds:statistics> or measurement on the peer mep point?
>>
>> B.R.
>> liu
>>
>>
>>
>>
>>
>>
>> *Loa Andersson <[email-masked]>*

-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Sami Boutros <[email-masked]>
Date: Thu, 12 May 2011 14:05:20 -0700

Agreed Yaacov, during the period of loopback the 
cc-cv function can't be performed, and yes the 
main benefit is of loopback is to measure 
loss/delay on a segment of a path as you stated.

Thanks,

Sami
At 10:36 PM 5/11/2011, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
>Sami, hi
>
>My understanding is that the question that was 
>asked is how do you use the cc-cv function to 
>check for mis-connectivity if it is being looped-back.
>
>Truth be told that during the period of loopback 
>you apparently cannot check the e2e path for 
>mis-connectivity, and the operator needs to take 
>this into consideration.  But since the path is 
>not transferring data e2e (it is looping 
>everything back) it is by definition not connected e2e.
>
>What is true is what Sami states this 
>functionality should be used to setup a 
>loss/delay measurement on a segment of a path, 
>and it should be used only for limited periods.
>
>Just my 2cents,
>yaacov
>
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Sami Boutros
>Cc: Ross Callon; [email-masked]; MPLS-TP ad hoc 
>team; [email-masked]
><https://www.ietf.org/mailman/listinfo/mpls>https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>
>
>

---

From: [email-masked]
Date: Fri, 13 May 2011 09:34:51 +0800

Stewart,hi
mis-connectivity or mis-configuration will generate two results: the first 
result is just as what you said, other LSP data pkt will be 
leaked to the LSP path. it is truly responsibility of the other to police. 

the second result may not be mentioned in your email, the LSP data pkt 
will be leaked to other LSP path. if so, how to process this problem?

in addtion, can the initiator of the LB process and analysis deeply all 
data packet which is being loopbacked? if so , it is most task and 
diffcult for the initiator of the LB to do it?

B.R.
Liu

Stewart Bryant <[email-masked]> 
发件人:  [email-masked]
2011-05-12 16:01
请答复 给
[email-masked]

收件人
[email-masked]
抄送

主题
Re: [mpls] working group last call on   draft-ietf-mpls-tp-li-lb-01.txt

Let's talk MEPs first.

The above procedure is an applications issue and not a protocol issue, and 
thus does not belong in this document.

The only case that does not seem to be covered is a problem that occurs 
during the LB, but that is a low probability event, and since there is no 
user data being carried  on the LSP under LB user service will not be 
disrupted. In the case of data in the LSP under LB leaking as a result of 
a problem, that is the responsibility of the other LSP to police.

Note that by examining the data received during a LB text the initiator of 
the LB is able to verify that it is their data that is being looped back 
which is equivalent to running a cc-cv.

- Stewart

On 12/05/2011 06:03, Sami Boutros wrote: 
To check for mis-connectivity/mis-configuration, you need a cc-cv function 
not a loopback function.

The loopback function can be used for loss/delay measurements, and this 
will be addressed in the delay/loss draft.

Thanks,

Sami

hi, all 

B.R. 
liu 

2011-05-10 23:43 
ÊÕ¼þÈË

Working Group,

/Loa

--

---

From: [email-masked]
Date: Fri, 13 May 2011 09:46:48 +0800

sami, yaccov,hi
firstly i say sorry for not clearly describling my question. 
for the first question, maybe yaacov's understanding be right. if a mep is 

on loopback state, it can't check the e2e path for mis-connectivity 
because
the mep point loopback everything including any OAM packet(cc&cv etc);

for the second question, I know loss/delay measurement should use LM/DM 
fuction to 
implement it. but for loopback function, there are the following two 
application:
  1 To verify bidirectional connectivity of a MEP with a MIP or a peer MEP
;
  2 To perform a bidirectional in-service or out-of-service diagnostics 
test between a pair of peer MEPs. This includes verifying bandwidth 
throughput, detecting bit errors, etc;
 
so for application 1, loopback anything will not affect verify 
bidirectional connectivity; but it may affect diagnostics test.
for example, if mis-connectivity or mis-configuration happened on a LSP 
path, since the mep of the lsp is under loopback state, it can't check 
mis-connectivity,
so the mep of the lsp maybe loopback other data packet of another lsp to 
the peer mep.or the data pkt of the LSP will be leaked to other LSP path, 
so it must affect the result of diagnostics test including bandwidth 
throughput, bit errors.

maybe i miss something important?

thank sami and yaacov for prompt replying it.

B.R.
Liu

Sami Boutros <[email-masked]> 
2011-05-13 05:05

收件人
"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>, 
<[email-masked]>, "Loa Andersson" <[email-masked]>
抄送
"Ross Callon" <[email-masked]>, <[email-masked]>, "MPLS-TP ad hoc 
team" <[email-masked]>, <[email-masked]>
主题
RE: [mpls] working group last call on  draft-ietf-mpls-tp-li-lb-01.txt

Agreed Yaacov, during the period of loopback the cc-cv function can't be 
performed, and yes the main benefit is of loopback is to measure 
loss/delay on a segment of a path as you stated.

Thanks,

Sami
 
My understanding is that the question that was asked is how do you use the 
cc-cv function to check for mis-connectivity if it is being looped-back.
 
Truth be told that during the period of loopback you apparently cannot 
check the e2e path for mis-connectivity, and the operator needs to take 
this into consideration.  But since the path is not transferring data e2e 
(it is looping everything back) it is by definition not connected e2e.
 
What is true is what Sami states this functionality should be used to 
setup a loss/delay measurement on a segment of a path, and it should be 
used only for limited periods.
 
Just my 2cents,
yaacov
 
From: [email-masked] [ mailto:[email-masked]] On Behalf Of 
ext Sami Boutros
Sent: Thursday, May 12, 2011 8:03 AM
To: [email-masked]; Loa Andersson
Cc: Ross Callon; [email-masked]; MPLS-TP ad hoc team; 
[email-masked]
Subject: Re: [mpls] working group last call on 
draft-ietf-mpls-tp-li-lb-01.txt

Thanks,

Sami

hi, all 

B.R. 
liu 

2011-05-10 23:43 
ÊÕ¼þÈË

Working Group,

/Loa

-- 

 

ZTE Information Security Notice: The information contained in this
mail

is solely property of the sender's organization. This mail
communication

is confidential. Recipients named above are obligated to maintain
secrecy

and are not permitted to disclose the contents of this communication
to

others.

This email and any files transmitted with it are confidential
and

intended solely for the use of the individual or entity to whom they
are

addressed. If you have received this email in error please notify
the

originator of the message. Any views expressed in this message are
those

of the individual
sender.

This message has been scanned for viruses and Spam by ZTE
Anti-Spam

system.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 13 May 2011 11:15:13 +0100

It therefore only really makes sense to use OAM of a request/response 
nature, such as loopback, on co-ps mode connections where one assumes 
there is no misconnectivity defect, eg to do RTD measurements say.

Neil

I agree with you on this.

Stewart

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 17 May 2011 06:03:09 +0200

Hi,

Again I am not sure that I understand the confusion – if the segment of the LSP is in loopback mode then it should be easy for the source LER to detect either of the misconnectivity conditions that you describe –

1. For the case of messages that are lost due to a misconnectivity between the source LER and the MIP that is looping back – the messages that are lost will not be looped-back, which can be detected by the source LER

2. For the case of messages that are leaking into the segment from a different LSP – this message will be looped back by the MIP and the source LER could detect an excessive message in the stream.

However, as was pointed out in a separate thread – it is advisable to only enter loopback on an LSP that there are no suspected misconnectivities!

Hope this helps,

yaacov

From: ext [email-masked] [mailto:[email-masked]] 
Sent: Friday, May 13, 2011 4:47 AM
To: Sami Boutros
Cc: [email-masked]; Loa Andersson; [email-masked]; Ross Callon; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: RE: [mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt

sami, yaccov,hi 
firstly i say sorry for not clearly describling my question. 
for the first question, maybe yaacov's understanding be right. if a mep is 
on loopback state, it can't check the e2e path for mis-connectivity because 
the mep point loopback everything including any OAM packet(cc&cv etc); 

for the second question, I know loss/delay measurement should use LM/DM fuction to 
implement it. but for loopback function, there are the following two application: 
  1 To verify bidirectional connectivity of a MEP with a MIP or a peer MEP; 
  2 To perform a bidirectional in-service or out-of-service diagnostics test between a pair of peer MEPs. This includes verifying bandwidth throughput, detecting bit errors, etc; 
  
so for application 1, loopback anything will not affect verify bidirectional connectivity; but it may affect diagnostics test. 
for example, if mis-connectivity or mis-configuration happened on a LSP path, since the mep of the lsp is under loopback state, it can't check mis-connectivity, 
so the mep of the lsp maybe loopback other data packet of another lsp to the peer mep.or the data pkt of the LSP will be leaked to other LSP path, so it must affect the result of diagnostics test including bandwidth throughput, bit errors. 

B.R. 
Liu

2011-05-13 05:05 

收件人

"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>, <[email-masked]>, "Loa Andersson" <[email-masked]> 

抄送

"Ross Callon" <[email-masked]>, <[email-masked]>, "MPLS-TP ad hoc team" <[email-masked]>, <[email-masked]> 

主题

		

Agreed Yaacov, during the period of loopback the cc-cv function can't be performed, and yes the main benefit is of loopback is to measure loss/delay on a segment of a path as you stated.

Thanks,

Sami

Just my 2cents,
yaacov

From: [email-masked] [ mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of ext Sami Boutros

Thanks,

Sami

hi, all 

B.R. 
liu 

2011-05-10 23:43 

ÊÕ¼þÈË

³ËÍ

Ö÷Ìâ

Working Group,

/Loa

-- 

https://www.ietf.org/mailman/listinfo/mpls <https://www.ietf.org/mailman/listinfo/mpls> 

others. 

of the individual
sender. 

system.

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Wed, 18 May 2011 11:36:14 +0200

Best regards,

Matthew

1) ACH and LSP-Ping Based Tools
The proposal in the draft defines both ACH and LSP-Ping based methods.
However, the draft for the use of LSP Ping in both an IP demultiplexed and
ACH demultiplexed mode. Please can you clarify why the additional ACH mode
is required?

2) Identification of MEP/MIP at which to create a loopback.
It is not clear how the target MEP/MIP identifier is carried. I assume
that you just use the MEP/MIP identifier as per
draft-ietf-mpls-tp-on-demand-cv-03, but I think the draft should
explicitly state this.

2) Relationship to control plane and MPLS in general.
The draft seems to present a new way of modifying the forwarding plane on
an LSR or PE. This is because setting an LSP or PW into loopback mode
would presumably require modifying the FIB at the LSR/PE hosting the MIP
or MEP  where the loopback is requested. Normally, one would imagine that
this would be done by LDP, RSVP-TE, or whatever other control plane
protocol has control of the FEC/Label bindings for the LSP/PW. The draft
effectively gives an OAM protocol control of this function. This would add
complexity to cases where a control plane was used to establish the
LSP/PW, and indeed it is not clear how this would work unless there are
extensions to the protocol to carry e.g. The FEC for the reverse direction
of an LSP, or how you keep the control plane state in sync with what OAM
is doing. 

However, the draft says that the mechanisms are meant to be extensible to
MPLS in general. I am not sure there is enough detail in the draft to
explain how this can be achieved. I would therefore suggest  removing any
claims that this could work for MPLS in general and stating that it must
not be used with a control plane. As an aside, I think we need an
additional mechanism that makes use of the control plane.

3) Security
The draft adds the ability for an OAM protocol to modify the forwarding
behaviour of a downstream LSR or PE. In my view, this raises a number of
security questions. Although the example of PPP chap is given as a
mechanism, this is only an example and there is again too little detail
about how to use it. Other MPLS-TP OAM protocols have there own
well-specified security / authentication mechanisms (e.g. See RFC5880
Section 4.2-4.4 for BFD). Without a strong security mechanism, I think
that any intermediate LSR or 'man in the middle' could inject LB request
packets and disrupt the forwarding of an LSP or PW at a downstream node.
The security section is at present very brief, but I think it should be
expanded to explain the possible threats scenarios and how they could be
mitigated. I think the draft should explicitly specify which security
mechanisms should be used.

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 May 2011 08:09:05 +0200

Yacoov,

indeed, isn't this one of the reason you'd actuall would like to put
an LSP or PW in loopback?

/Loa

On 2011-05-17 06:03, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:
> Hi,
>
> Again I am not sure that I understand the confusion – if the segment of
> the LSP is in loopback mode then it should be easy for the source LER to
> detect either of the misconnectivity conditions that you describe –
>
> 1. For the case of messages that are lost due to a misconnectivity
> between the source LER and the MIP that is looping back – the messages
> that are lost will not be looped-back, which can be detected by the
> source LER
>
> 2. For the case of messages that are leaking into the segment from a
> different LSP – this message will be looped back by the MIP and the
> source LER could detect an excessive message in the stream.
>
> However, as was pointed out in a separate thread – it is advisable to
> only enter loopback on an LSP that there are no suspected misconnectivities!
>
> Hope this helps,
>
> yaacov
>
> *From:*ext [email-masked] [mailto:[email-masked]]
> *Sent:* Friday, May 13, 2011 4:47 AM
> *To:* Sami Boutros
> *Cc:* [email-masked]; Loa Andersson;
> [email-masked]; Ross Callon; Weingarten, Yaacov (NSN - IL/Hod HaSharon)
> *Subject:* RE: [mpls] working group last call on
> the peer mep.or the data pkt of the LSP will be leaked to other LSP
> path, so it must affect the result of diagnostics test including
> bandwidth throughput, bit errors.
>
> *Sami Boutros <[email-masked]>*
>
> 2011-05-13 05:05
>
> 	
>
> 收件人
>
> 	
>
> "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
> <[email-masked]>, <[email-masked]>, "Loa Andersson"
> <[email-masked]>
>
> 抄送
>
> 	
>
> My understanding is that the question that was asked is how do you use
> the cc-cv function to check for mis-connectivity if it is being looped-back.
>
> *
> From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Sami Boutros*
> Sent:* Thursday, May 12, 2011 8:03 AM*
> To:* [email-masked]; Loa Andersson*
> Cc:* Ross Callon; [email-masked]; MPLS-TP ad hoc team;
> [email-masked]*
> Subject:* Re: [mpls] working group last call on
> can it affectperformance <app:ds:performance> statistics
> [email-masked]
> _https://www.ietf.org/mailman/listinfo/mpls
>
>
>
>
>
>
>
>

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 19 May 2011 11:46:19 +0200

Authors,

I've one thought that been nagging me about
draft-ietf-mpls-tp-li-lb-01.txt, it is on how the lock instruct tool
interwork with other OAM tools, in particular CC adn CV.

Consider this case

            A====B====C====D====E
  c----b----a------------------------d----e

  f----g----a------------------------d----h

  i----j----a------------------------d----k
            A====B====C====D====E

What I tried draw is a three LSPs [c to e, f to h, i to k]
that are put into a tunnel at node A, A to E represents the tunnel.

Consider the case where we are running CC and/or CV on bout the
tunnel

If the operator wants to put C in loop back, the first step is
that A sends a lock instruct message to E for this LSP.

This will immediately result in an alarm from A, and might trigger
protection (the draft does not describe, how node A is prepared
for locking E).

This might be a minor problem since A originates the lock
instruct, and we can put A in a "prepared state" but it might
at least be mentioned in the draft.

More problematic might be that c,f,h,e and k might also alarm, since
these node might be widely dispersed it might cause quite some amount
of alarms and protection switching.

Since we are dealing with OAM tools, I think it is necessary to give
some operational heads up in this kind of draft.

/Loa

--

---

From: Loa Andersson <[email-masked]>
Date: Sun, 29 May 2011 13:16:15 +0800

Working Group,

this last call has ended. There has been comments, could the authors
please resolve the comments and publish a new version of the document.

/Loa
for the MPLS wg chairs

--