Subject: [Mpls-interop] Some comments on draft-boutros-mpls-tp-loopback-02.txt

From: "Annamaria Fulignoli" <[email-masked]>
Date: Wed, 18 Mar 2009 16:33:10 +0100

Hi all,
I have some first comments on the
http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02.

Please not that comment 3  involves  the MPLS-TP OAM requirement draft. 

In this mail I refer to the draft 's example: A <---> B <---> C <---> D 

1)  I think lock packet is an independent tool and not a loopback packet
lock/ unlock operation; it should address the general requir. 2.2 7 of
MPLS-TP OAM requirement. This even implies that when the LSP in D enters
in the administrative lock state, all traffic on the path must be
blocked  as lock tool should not be based on the fact that in C there's
a FLB.

2) When D receives the lock packet it should even  send a "server/client
lock "indication  as addressed by
http://tools.ietf.org/html/draft-fulignoli-mpls-tp-ais-lock-tool-00  or
even by http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-01.
 In this mail I use  the" server/client lock " term to differentiate the
lock term used in the loopback draft (and now  referenced  even in
section 2.2.7 MPLS-TP OAM requirement),  by the same term used in
mpls-tp-ais-lock-tool-00  draft and referenced in section 2.2.8 of
MPLS-TP OAM requirement. 

3) Please note that nowadays the term lock is known ad used for the lock
functionality as referenced in 2.2.8 of MPLS-TP OAM requirement; so I
think that  another term should be used for functionality in section
2.2.7 

4) My understanding is that A and D can be even MEPs of a TCM . Is it
correct ?

5)It's not clear to me the administrative state of LSP  in A when it
sends a FLB to C.  I think that even in A the LSP (rx direction ) should
enter in administrative lock state and even A should send to the
client(s) transported by the path ( i.e. In the backward direction) a
"server/client lock" indication  .....

6)  In OLB , why we need to loop all OAM packets ?

7) Why do you think it's  important for MPLS-TP to have a  FLB and not
only a OLB ?  

8) I think that OLB could be simplified with just one Loobpack message
request looped back as a  loopback message replay.... 

9) I ask again: 
    ACH encapsulation method ( not IP based ) and LSP Ping extension (IP
based) are proposed. I wonder why even the IP based method is proposed
in a MPLS-TP OAM tool and I even want to highlight that this approach
could lead to a possible confusion and mis-understanding as in MPLS-TP
requirement draft is reported (req. 41): "It MUST be possible to operate
and configure the MPLS-TP data(transport) plane without any IP
forwarding capability in the MPLS-TP data plane. " 

Kind Regards,
Annamaria

---

From: Sami Boutros <[email-masked]>
Date: Fri, 27 Mar 2009 18:30:09 -0700

><http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02>http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02. 
>
>
>1)  I think lock packet is an independent tool and not a loopback 
>packet lock/ unlock operation; it should address the general requir. 
>2.2 7 of MPLS-TP OAM requirement. This even implies that when the 
>LSP in D enters in the administrative lock state, all traffic on the 
>path must be blocked  as lock tool should not be based on the fact 
>that in C there's a FLB.
>
>2) When D receives the lock packet it should even  send a 
>"server/client lock "indication  as addressed by 
><http://tools.ietf.org/html/draft-fulignoli-mpls-tp-ais-lock-tool-00>http://tools.ietf.org/html/draft-fulignoli-mpls-tp-ais-lock-tool-00 
>or even by 
><http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-01>http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-01.
>
>  In this mail I use  the" server/client lock " term to 
> differentiate the lock term used in the loopback draft (and 
> now  referenced  even in section 2.2.7 MPLS-TP OAM 
> requirement),  by the same term used in 
>3) Please note that nowadays the term lock is known ad used for the 
>lock functionality as referenced in 2.2.8 of MPLS-TP OAM 
>requirement; so I think that  another term should be used for 
>functionality in section 2.2.7
>
>4) My understanding is that A and D can be even MEPs of a TCM . Is 
>it correct ?
>
>sends a FLB to C.  I think that even in A the LSP (rx direction ) 
>should enter in administrative lock state and even A should send to 
>the client(s) transported by the path ( i.e. In the backward 
>direction) a  "server/client lock" indication  .....
>

Please find this text in the draft..

When operating the MPLS-TP LSP in OLB, C loops only AM packets 
generated by A with the specific ACH codepoint back to A.

>7) Why do you think it's  important for MPLS-TP to have a  FLB and 
>not only a OLB ?

For testing  as well for 2 ways performance measurements.

>8) I think that OLB could be simplified with just one Loobpack 
>message request looped back as a  loopback message replay....
>
>9) I ask again:
>     ACH encapsulation method ( not IP based ) and LSP Ping 
> extension (IP based) are proposed. I wonder why even the IP based 
> method is proposed in a MPLS-TP OAM tool and I even want to 
> highlight that this approach could lead to a possible confusion and 
> mis-understanding as in MPLS-TP requirement draft is reported (req. 
> 41): "It MUST be possible to operate and configure the MPLS-TP 
> data(transport) plane without any IP forwarding capability in the 
> MPLS-TP data plane. "

The requirement draft has as well "This document lists the 
requirements for the OAM functionality of MPLS-TP.  These 
requirements apply to pseudowires (PWs), Label Switched Paths (LSPs), 
and Sections." I don't think we can discount the LSP Ping IP based approach.

Thanks,

Sami

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 28 Mar 2009 08:34:22 +0000

Sami,

> and Sections." I don't think we can discount the LSP Ping IP based approach.

You are right we cannot discount the LSP Ping IP based approach.

Ben

---

From: Sami Boutros <[email-masked]>
Date: Sat, 28 Mar 2009 18:56:35 -0700

Agreed Ben,

Sami

---

From: "Annamaria Fulignoli" <[email-masked]>
Date: Mon, 30 Mar 2009 11:16:21 +0200

Hi Sami &all,
 
see in line tagged [AF].
 
Regards
Annamaria

________________________________

From: Sami Boutros [mailto:[email-masked]] 
Sent: sabato 28 marzo 2009 2.30
To: Annamaria Fulignoli; [email-masked]
Subject: Re: [Mpls-interop] Some comments on
draft-boutros-mpls-tp-loopback-02.txt

	Hi all, 
	I have some first comments on the
http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02
<http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-02>  . 
	
	Please not that comment 3  involves  the MPLS-TP OAM requirement
draft. 
	
	In this mail I refer to the draft 's example: A <---> B <---> C
<---> D 
	
	1)  I think lock packet is an independent tool and not a
loopback packet lock/ unlock operation; it should address the general
requir. 2.2 7 of MPLS-TP OAM requirement. This even implies that when
the LSP in D enters in the administrative lock state, all traffic on the
path must be blocked  as lock tool should not be based on the fact that
in C there's a FLB.
	
	2) When D receives the lock packet it should even  send a
"server/client lock "indication  as addressed by
http://tools.ietf.org/html/draft-fulignoli-mpls-tp-ais-lock-tool-00
<http://tools.ietf.org/html/draft-fulignoli-mpls-tp-ais-lock-tool-00>
or even by http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-01
<http://tools.ietf.org/html/draft-bhh-mpls-tp-oam-y1731-01>  .
	
	 In this mail I use  the" server/client lock " term to
differentiate the lock term used in the loopback draft (and now
referenced  even in section 2.2.7 MPLS-TP OAM requirement),  by the same
term used in mpls-tp-ais-lock-tool-00  draft and referenced in section
2.2.8 of MPLS-TP OAM requirement. 
	
	3) Please note that nowadays the term lock is known ad used for
the lock functionality as referenced in 2.2.8 of MPLS-TP OAM
requirement; so I think that  another term should be used for
functionality in section 2.2.7 
	
	4) My understanding is that A and D can be even MEPs of a TCM .
Is it correct ? 
	
	5)It's not clear to me the administrative state of LSP  in A
when it sends a FLB to C.  I think that even in A the LSP (rx direction
) should enter in administrative lock state and even A should send to
the client(s) transported by the path ( i.e. In the backward direction)
a  "server/client lock" indication  .....
	
	6)  In OLB , why we need to loop all OAM packets ?  
	 Please find this text in the draft.   When operating the
MPLS-TP LSP in OLB, C loops only AM packets
	generated by A with the specific ACH codepoint back to A.

	7) Why do you think it's  important for MPLS-TP to have a  FLB
and not only a OLB ?  
	 For testing  as well for 2 ways performance measurements. 
	[AF] It could be obtained even in different ways; so my question
was to understand if it was an explicit operator request to loopback all
traffic.

9) I ask again: 
 
 The requirement draft has as well "   This document lists the
requirements for the OAM functionality of MPLS-TP.  These
requirements apply to pseudowires (PWs), Label Switched Paths (LSPs),
and
Sections." 
[AF] This is obtained by the GAL/ACH mechanism too ! 
 
  I don't think we can discount the LSP Ping IP based   approach. 
[AF]  If so, the reasons should be better clarified somewhere. 
 
 [AF]  Are you going to answer even to the other points ?
 
 Thanks,
 Sami

	Kind Regards, 
	Annamaria

---

From: Sami Boutros <[email-masked]>
Date: Mon, 30 Mar 2009 09:04:50 -0700

Hi Annamaria,

>>packet lock/ unlock operation; it should address the general 
>>requir. 2.2 7 of MPLS-TP OAM requirement. This even implies that 
>>when the LSP in D enters in the administrative lock state, all 
>>traffic on the path must be blocked  as lock tool should not be 
>>based on the fact that in C there's a FLB.
>>

I agree the lock is a function independent of loopback and is needed 
by other OAM functions, is this your point?

>>5)It's not clear to me the administrative state of LSP  in A when 
>>it sends a FLB to C.  I think that even in A the LSP (rx direction 
>>) should enter in administrative lock state and even A should send 
>>to the client(s) transported by the path ( i.e. In the backward 

This is correct in FLB mode, the LSP state at A and D will be the lock state.

>>  Please find this text in the draft.   When operating the MPLS-TP 
>> LSP in OLB, C loops only AM packets

  Please find this text in the draft.   When operating the MPLS-TP 
LSP in OLB, C loops only AM packets
generated by A with the specific ACH codepoint back to A.

>>was to understand if it was an explicit operator request to 
>>loopback all traffic.
>
>

Yes it is.

>    ACH encapsulation method ( not IP based ) and LSP Ping extension 
> (IP based) are proposed. I wonder why even the IP based method is 
> proposed in a MPLS-TP OAM tool and I even want to highlight that 
> this approach could lead to a possible confusion and 
>requirements apply to pseudowires (PWs), Label Switched Paths (LSPs), and
>Sections."

I am not sure I get the point. However yes we should support the IP 
less option too and this is what we mentioned in the draft.

>[AF]  If so, the reasons should be better clarified somewhere.

I don't think we need to clarify or justify why we should support IP. 
We support IP and IP less option.

Thanks,

Sami