Subject: RE: [PWE3] Discussion: MS-OAM Issues

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 23 Mar 2006 23:51:08 -0500

Hi Yang,
 
I have a few comments. You wrote:
 
"So we prefer to use CW as OAM control channel for MS-PW.  Use 1 bit in CW to distinguish segment and e2e oam traffic"
 
I don't think that that is a good solution. The OAM information carries the same PW label as the payload. Therefore, if you use the CW to indicate whether an S-PE should act on an OAM frame or not, you require the switch to inspect the CW of every frame. In my view that is unacceptable. The S-PE should switch traffic based on the PW label only, without inspection of the rest of the frame. Therefore, I believe that the use of TTL is preferable.
 
For the same reason, I think it is not a good idea to use BFD to distinguish between end-to-end and segment OAM.
 
It would be good to clarify when segment OAM is useful. It is not necessary to be able to do fault detection on a per-segment basis. It is perfectly fine to do fault detection on an end-to-end basis and use a diagnostics tool like Link Trace to do fault isolation when a failure has been detected. 
 
In general, segment OAM is relevant if the MS-PW is carried through multiple administrative domain. In that case, each operator would want to check the sanity of the PW within its own domain. Each operator would create a BFD session between the PEs at the edges of his own domain. In addition, the Service Provider responsible for the end-to-end service would create his own BFD session. Thus, there could be several, nested, independent BFD sessions.
 
Dave already addressed the issue of AIS (or FDI, if you prefer). I agree with him that BFD would be a poor choice. The question is what to do otherwise. One option is to define a VCCV message that is carried in-band but that is independent of the protocol used for end-to-end failure detection. (With independent I mean that it is not defined as part of that protocol.) If I am not mistaken, this is what you propose in section 3.2 of your draft. The alternative is to rely on control messages. E.g. an S-PE that detects a failure on a PW segment could use PW Status to inform the downstream T-PE. Such a procedure would be in line with current SS-PW OAM mechanisms. There are several reasons why an in-band mechanism is preferable over a control-plane mechanism, but much depends on the actual implementation of the T-PEs. If OAM is implemented in hardware, in-band is generally preferable. If it is implemented in software, it probably doesn't make a big difference.
 
Peter

-----Original Message-----
From: Yang Yang [mailto:[email-masked]]
Sent: Thursday, March 23, 2006 11:29 AM
To: [email-masked]
Cc: George Swallow; Stewart Bryant; [email-masked]
Subject: [PWE3] Discussion: MS-OAM Issues

Hello everybody,
    There were lots comments on MS-OAM during the PWE3 session. Thanks a lots.
 
    The key difference between SS-OAM and MS-OAM should be the OAM levels provided.  SS-OAM only provides one level while MS-OAM provides two levels (E2E level and Segment level).  Both the control plane and the data plane should support levels. 
    While PW is setting up, both end of PW should negotiate the level provided. S-PEs support only segment level while T-PEs should support segment level and e2e level. The signaling protocol should be extent to carry level info. 
    In data plane, there are three OAM channel which have been already defined. In SS-PW, Router alert works OK.  The OAM traffic are terminated at the sink side of SS-PW. But in MS-PW, each S-PE will terminate the traffic. And S-PE should inspect the traffic to make sure whether the traffic is segment oam traffic or e2e oam traffic. Usually it costs more time.  TTL may works well in MS-PW. Pls make in mind that TTL info may be denied by the service provider for "security reseaon". 
   So we prefer to use CW as OAM control channel for MS-PW.  Use 1 bit in CW to distinguish segment and e2e oam traffic.
 
   BFD could be extent to carry level info. But BFD PDU are carried in UDP/IP.  The S-PE should inspect the UDP header to make sure it's BFD packets and then inspect BFD PDU to make sure whether it should terminate the packet (segment oam) or transit the packet(e2e oam).  I am not sure whether BFD could work very well in MS-PW. 
 
   Best Regards！
      Yang

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

---

From: Jixiong Dong <[email-masked]>
Date: Fri, 24 Mar 2006 14:30:00 +0800

Hi Peter,

Some comments seen in-line…

Best Regards,

Dong

  _____  

发件人: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
发送时间: 2006年3月24日 12:51
收件人: 'Yang Yang'; [email-masked]
抄送: George Swallow; [email-masked]; Stewart Bryant
主题: RE: [PWE3] Discussion: MS-OAM Issues

Hi Yang,

"So we prefer to use CW as OAM control channel for MS-PW.  Use 1 bit in CW
to distinguish segment and e2e oam traffic"

I don't think that that is a good solution. The OAM information carries the
same PW label as the payload. Therefore, if you use the CW to indicate
whether an S-PE should act on an OAM frame or not, you require the switch to
inspect the CW of every frame. In my view that is unacceptable. The S-PE
should switch traffic based on the PW label only, without inspection of the
rest of the frame. Therefore, I believe that the use of TTL is preferable.

[Dong] First you must identify whether the packet is OAM packet or data
packet by CW.first 4 nibble. If you inspect the CW.first 4 nibble, then it’
s not unacceptable for inspecting the CW.segOamBit. I want to indicate that
the proposal in the draft is one choice for implementation. Of course you
could use TTL schema.

For the same reason, I think it is not a good idea to use BFD to distinguish
between end-to-end and segment OAM.

[Dong]  I don’t think that this draft give this proposal.

It would be good to clarify when segment OAM is useful. It is not necessary
to be able to do fault detection on a per-segment basis. It is perfectly
fine to do fault detection on an end-to-end basis and use a diagnostics tool
like Link Trace to do fault isolation when a failure has been detected. 

[Dong] I am sorry that I can’t agree with you. Just like the scenario you
said in the following paragraph, segment OAM is very useful. I want to
indicate the other scenario is segment PW monitor and protection.

In general, segment OAM is relevant if the MS-PW is carried through multiple
administrative domain. In that case, each operator would want to check the
sanity of the PW within its own domain. Each operator would create a BFD
session between the PEs at the edges of his own domain. In addition, the
Service Provider responsible for the end-to-end service would create his own
BFD session. Thus, there could be several, nested, independent BFD sessions.

[Dong] The issue is how to nest BFD sessions and how to distinguish the
nested BFD sessions. As my understand, in-band BFD detection payload is
located after PW label and CW.

Dave already addressed the issue of AIS (or FDI, if you prefer). I agree
with him that BFD would be a poor choice. The question is what to do
otherwise. One option is to define a VCCV message that is carried in-band
but that is independent of the protocol used for end-to-end failure
detection. (With independent I mean that it is not defined as part of that
protocol.) If I am not mistaken, this is what you propose in section 3.2 of
your draft. The alternative is to rely on control messages. E.g. an S-PE
that detects a failure on a PW segment could use PW Status to inform the
downstream T-PE. Such a procedure would be in line with current SS-PW OAM
mechanisms. There are several reasons why an in-band mechanism is preferable
over a control-plane mechanism, but much depends on the actual
implementation of the T-PEs. If OAM is implemented in hardware, in-band is
generally preferable. If it is implemented in software, it probably doesn't
make a big difference.

[Dong] We have discussed with some service providers. They don’t like using
the control plane messages in the OAM of data plane. It will confuse the
conception of layer. And it will make some problems when there is no control
plane or control plane is in fault status. 

Peter

-----Original Message-----
From: Yang Yang [mailto:[email-masked]]
Sent: Thursday, March 23, 2006 11:29 AM
To: [email-masked]
Cc: George Swallow; Stewart Bryant; [email-masked]
Subject: [PWE3] Discussion: MS-OAM Issues

Hello everybody,

    There were lots comments on MS-OAM during the PWE3 session. Thanks a
lots.

    The key difference between SS-OAM and MS-OAM should be the OAM levels
provided.  SS-OAM only provides one level while MS-OAM provides two levels
(E2E level and Segment level).  Both the control plane and the data plane
should support levels. 

    While PW is setting up, both end of PW should negotiate the level
provided. S-PEs support only segment level while T-PEs should support
segment level and e2e level. The signaling protocol should be extent to
carry level info. 

    In data plane, there are three OAM channel which have been already
defined. In SS-PW, Router alert works OK.  The OAM traffic are terminated at
the sink side of SS-PW. But in MS-PW, each S-PE will terminate the traffic.
And S-PE should inspect the traffic to make sure whether the traffic is
segment oam traffic or e2e oam traffic. Usually it costs more time.  TTL may
works well in MS-PW. Pls make in mind that TTL info may be denied by the
service provider for "security reseaon". 

   So we prefer to use CW as OAM control channel for MS-PW.  Use 1 bit in CW
to distinguish segment and e2e oam traffic.

   BFD could be extent to carry level info. But BFD PDU are carried in
UDP/IP.  The S-PE should inspect the UDP header to make sure it's BFD
packets and then inspect BFD PDU to make sure whether it should terminate
the packet (segment oam) or transit the packet(e2e oam).  I am not sure
whether BFD could work very well in MS-PW. 

   Best Regards！

      Yang