Subject: [PWE3] Discussion: MS-OAM Issues

From: "Yang Yang" <[email-masked]>
Date: Thu, 23 Mar 2006 10:29:28 -0600

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: "David Allan" <[email-masked]>
Date: Thu, 23 Mar 2006 11:52:11 -0500

HI Yang:

IMO if there is an issue with BFD and MS-PWs, it is that session discriminator information for U-PE-U-PE flows is not normally distributed to S-PEs, BFD itself IMO nominally not being tightly coupled with, nor explicitly inferring state from the arrival path. You can have segment operations, and e2e operations, but notifications from a segment boundary to a PW end point cannot be easily supported today.

So on failure of a segment, use of BFD to carry notifications (FDI/AIS equivalents with concatenated path down diagnostic code or similar) to an end point would require S-PEs to have knowledge of the session discriminators for the path , and to obtain this would have to snoop the VCCV channel to do so or require extensions to signalling to distribute that information once BFD initial negotiation was complete. Further, I would have to belevie there are state machine issues with BFD if there is a potential of more than one source of PDUs associated with a session discrimintor....(U-PE AND S-PE)

So the only other apparent possiblity is to perform per segment BFD, and bucket brigade the diagnostic codes..... Extra overhead and incomplete coverage of the BFD flows...(yuck)

cheers
Dave

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

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 24 Mar 2006 11:55:05 -0500

Hi Yang,
 
"TTL expiry could be used as OAM control channel if the T-PE know eactly how many segment/hops to the far end T-PE."
I agree that the use of TTL is not without problems, but I don't there is much else you can do. Y.1711 uses a special label value to identify OAm traffic, however in the case of ECMP that does not guarantee fate sharing between OAM and payload. 
 
Finding the far-end T-PE is actually not very hard. In contrast with the S-PE, the T-PE does inspect the CW of every packet. Therefore, you can set the TTL to a sufficiently large value and everything will work. The more difficult problem is the find an S-PE at the edge of an administrative domain  that is a few hops away. It seems to me that upon PW establishment the MEP at one end of a maintenance entity must execute a form of Link Trace to determine the distance in S-PE hops to its peer MEP.
 
"... if there are no CW in PW, how to deploy MS-OAM"
I am not saying that there is no CW. I am saying that you cannot expect an S-PE to inspect the CW of every packet that passes through it.
 
"The MIP node should inspect the ETH-OAM PDU to make sure whether the PDU should be terminated or transmitted"
I believe that there will be some differences between PW OAM and Ethernet OAM because of the frame identification issue. In the case of Ethernet a MIP recognizes OAM frames through the Etherntype. It could potentially act on every OAM packet that passes through it. On the other hand, in the case of PWs, the TTL determines which node will act on an OAM packet. In some sense, you could say that certain functionality shifts from the MIP to the MEP.
 
"In MS-PW, the S-PE could also inspect the traffic and get level info from CW field. There are no problem."
As I mentioned before, you first need TTL expiry to trigger the S-PE to inspect a packet. Subsequently, the CW can be used to identify the identity that the packet contains and OAM frame and the level to which it applies.
 
Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Yang Yang
Sent: Friday, March 24, 2006 11:29 AM
To: Busschbach, Peter B (Peter)
Cc: Jixiong Dong; [email-masked]; George Swallow; [email-masked]; Stewart Bryant
Subject: Re: [PWE3] Discussion: MS-OAM Issues

Hello Peter,
   TTL expiry could be used as OAM control channel if the T-PE know eactly how many segment/hops to the far end T-PE. If it couldn't get the TTL info, the approach doen't work. You may also question that if there are no CW in PW, how to deploy MS-OAM?  The approach defined in the draft has such limitation. It's only an alternative approach. We may try to find even better approaches. 
   I'm not sure whether MS-PW need too many OAM levels. Besides the levels supportted, the OAM traffic must carry the level info. In Ethernet, the level info is carried in OAM PDU. A reserved multicast address is used to identificate the OAM traffic and the ME-Level filed is used to distinguish the OAM level. The MIP node should inspect the ETH-OAM PDU to make sure whether the PDU should be terminated or transmitted.  In MS-PW, the S-PE could also inspect the traffic and get level info from CW field. There are no problem. 

  Best Regards!
    Yang

On 3/24/06, Busschbach, Peter B (Peter) < [email-masked] <mailto:[email-masked]> > wrote: 

Hi Dong,
 
You may have misunderstood some of my comments. Let me explain below.
 
Peter

-----Original Message-----
From: Jixiong Dong [mailto:  <mailto:[email-masked]> [email-masked]]
Sent: Friday, March 24, 2006 1:30 AM
To: 'Busschbach, Peter B (Peter)'; 'Yang Yang'; [email-masked] <mailto:[email-masked]> 
Cc: 'George Swallow'; [email-masked] <mailto:[email-masked]> ; 'Stewart Bryant'
Subject: ??: [PWE3] Discussion: MS-OAM Issues 

Hi Peter,

Some comments seen in-line…

Best Regards,

Dong

  _____  

发件人: Busschbach, Peter B (Peter) [mailto: [email-masked] <mailto:[email-masked]> ] 
发送时间: 2006年3月24 日 12:51
收件人: 'Yang Yang'; [email-masked] <mailto:[email-masked]> 
抄送: George Swallow; [email-masked] <mailto:[email-masked]> ; 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: [email-masked] <mailto:[email-masked]> ]
Sent: Thursday, March 23, 2006 11:29 AM 
To: [email-masked] <mailto:[email-masked]> 
Cc: George Swallow; Stewart Bryant; [email-masked] <mailto:[email-masked]> 
Subject: [PWE3] Discussion: MS-OAM Issues 

Hello everybody,

   Best Regards！

      Yang