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

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 <stbryant@cisco.com> 
发件人:  mpls-bounces@ietf.org
2011-05-12 16:01
请答复 给
stbryant@cisco.com

收件人
mpls@ietf.org
抄送

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

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: 
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, liu.guoman@zte.com.cn wrote:

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 <loa@pi.nu> 
·¢¼þÈË:  mpls-bounces@ietf.org 

2011-05-10 23:43 
ÊÕ¼þÈË
"mpls@ietf.org" <mpls@ietf.org> 
³ËÍ
Ross Callon <rcallon@juniper.net>, MPLS-TP ad hoc team 
<ahmpls-tp@lists.itu.int>, draft-ietf-mpls-tp-li-lb@tools.ietf.org 
Ö÷Ìâ
[mpls] working group last call on draft-ietf-mpls-tp-li-lb-01.txt 

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 mpls@ietf.org mailing list.

This working group last call ends on May 25th.

/Loa

for the mpls wg co-chairs

-- 

Loa Andersson                         email: loa.andersson@ericsson.com
Sr Strategy and Standards Manager            loa@pi.nu
Ericsson Inc                          phone: +46 10 717 52 13
                                             +46 767 72 92 13
_______________________________________________
mpls mailing list
mpls@ietf.org
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.

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

-- 
For corporate legal information go to:

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

_______________________________________________
mpls mailing list
mpls@ietf.org
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.