Re: [PWE3] Discussion: MS-OAM Issues

On 3/24/06, Busschbach, Peter B (Peter) <busschbach at lucent.com> wrote:

Hi Dong,

You may have misunderstood some of my comments. Let me explain below.

Peter

-----Original Message-----
From: Jixiong Dong [mailto: dongjixiong at huawei.com]
Sent: Friday, March 24, 2006 1:30 AM
To: 'Busschbach, Peter B (Peter)'; 'Yang Yang'; pwe3 at ietf.org
Cc: 'George Swallow'; danny at tcb.net; 'Stewart Bryant'
Subject: ??: [PWE3] Discussion: MS-OAM Issues

Hi Peter,

Some comments seen in-line…

Best Regards,

Dong

发件人: Busschbach, Peter B (Peter) [mailto: busschbach at lucent.com]
发送时间: 2006年3月24 日 12:51
收件人: 'Yang Yang'; pwe3 at ietf.org
抄送: George Swallow; danny at tcb.net; Stewart Bryant
主题: RE: [PWE3] Discussion: MS-OAM Issues

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.

[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.

[PB] My point was that an S-PE should not look at the control word at all. It essentially functions as a label switch that only inspects the PW label. Therefore, you first need to find a way to alert the S-PE that there is a packet that it should pay attention to. Using the TTL is the best way to do that. Once, the S-PE sees a packet with an expired TTL, it will inspect the packet further, and in that case you do indeed need an identification in the CW to distinguish OAM packets from Payload packets.

I don't have a problem with the idea to use a bit in the control word to distinguish between segment OAM and end-to-end OAM. However, from Yang's email I got the impression that he saw it as sufficient and as an alternative to TTL expiry.

One last thing: I personally believe it makes sense to adopt the concept of ME levels, as defined in Ethernet OAM ( Y.1731, 802.1ag). Therefore, instead of a single bit to distinguish between segment and e2e oam, you would need three bits to encode the eight possible ME levels.

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.

[PB] The draft does not, but I thought that the last email in Yang's email suggested that as a possibility. My comment applied to Yang's email

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.

[PB]  The word segment is confusing. Since we are talking about Multi-segment OAM, you woulld think that a segment is the part of the PW that exists between two adjacent S-PEs. This is also the way it is used in your draft. On the other hand, in the L2VPN OAM Framework document, segments are associated with administrative domains.

Normally, if you want to do failure detection on the link between two adjacent switches, you use OAM mechanisms available on that link. Therefore, in the case of PWs, you would like to run BFD in the PSN Tunnel that connects two S-PEs. The probem is that due to the use of ECMP you can't guarantee fate sharing between the BFD session in the PSN Tunnel and a particular PW. This could compel an operator to run BFD within the PW. In that case, you will indeed end up with segment OAM in the way you describe it .

Personally, I think operators should use RSVP-TE to establish PSN Tunnels and thus avoid ECMP altogether. That way, the operator can run BFD in the PSN Tunnels. The operator would then run BFD in the PW for e2e OAM. In case there are multiple operators and service providers involved, they could create a nested structure analogous to the the L2VPN OAM Framework. In that case, there would be segment OAM, but the segments would coincide with the administrative domains , not with PW segments.

I think that any document on PW OAM should address the fact that there are two interpretations of the word segment .

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.

[PB]  I think it is a good idea to define in-band AIS/FDI. However, I want to reiterate that the current SS-PW solutions do use the control plane to convey fault status. Apart from BT, I haven't seen a strong opposition form service providers against the WG drafts that describe this solution. And since it is used for SS-PW, it would make sense, for the sake of consistency, to also allow it for the MS-PW ase.

Peter

-----Original Message-----
From: Yang Yang [mailto: HealthingHearts at ieee.org]
Sent: Thursday, March 23, 2006 11:29 AM
To: pwe3 at ietf.org
Cc: George Swallow; Stewart Bryant; danny at tcb.net
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