Subject: Re: [PWE3] VCCV usage

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Sat, 13 Nov 2010 04:21:07 +0100

Yes, of course, but you still need the correct TTL to prevent the packet from just being decapsulated and forwarded to the AC.

Cheers
Matthew

Matthew

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Bocci, Matthew (Matthew)
Cc: Yaakov Stein <[email-masked]>; [email-masked] <[email-masked]>
Sent: Sat Nov 13 01:48:43 2010
Subject: Re: [PWE3] VCCV usage

Matthew,

Type-3 can also be used in MS-PW. Type-3 can be used with CW enabled
in situations where there is concern of PW label TTL not being set
correctly at ingress.

On Fri, Nov 12, 2010 at 4:16 PM, Bocci, Matthew (Matthew)
<[email-masked]> wrote:
> Sri,
>
> Still, you are relying on the TTL to be set correctly by the sending
> T/S-PE to prevent a fairly significant issue at the receiving T-PE. TTL
> expiry only ensures that a VCCV packet will be intercepted at a T-PE
> rather then being forwarded on the AC if TTL is set correctly. Type 1
> ensures that this does not happen because the 1st four bits of the control
> word are always checked when the PW label is popped.
>
> Matthew
>
>
>
> On 12/11/2010 21:26, "Sriganesh Kini" <[email-masked]> wrote:
>
>>Yaakov,
>>
>>The tunnel setup protocol should not matter since the TTL expiry VCCV
>>depends on the PW label TTL. When the PW is placed in a tunnel setup
>>by LDP and the number of hops of the LDP tunnel change, the same PW
>>label TTL must be used for VCCV.
>>
>>
>>- Sri
>>
>> 2010 at 4:11 AM, Yaakov Stein <[email-masked]> wrote:
>>> I agree with Sasha that we need to protect against the number of hops
>>>changing,
>>> when the PW is placed in a tunnel set up by LDP.
>>>
>>> However, that is one of the reasons I don't like TTL expiry.
>>> It requires too much configuration, or alternatively a TTL discovery
>>>mechanism.
>>>
>>> Y(J)S
>>>
>>> -----Original Message-----
>>> From: Sri [mailto:[email-masked]]
>>> Sent: Friday, November 12, 2010 12:35
>>> To: Alexander Vainshtein
>>> Cc: Yaakov Stein; [email-masked]
>>> Subject: Re: [PWE3] VCCV usage
>>>
>>> It is important to have TTL Expiry VCCV (Type 3) . IMO, leaking should
>>> not be a concern as the number of hops should not change dynamically.
>>> If it is still a concern it can be used with CW.
>>>
>>> Another important consideration is for VCCV to be inband even for
>>> multipath. This must be independent of whether CW is used.
>>>
>>> --
>>> Sri
>>>
>>>
>>> On Thu, Nov 11, 2010 at 1:28 AM, Alexander Vainshtein
>>> <[email-masked]> wrote:
>>>> Yaakov and all,
>>>>
>>>>
>>>>
>>>> IMO when it comes to VCCV we should look for a disposition that would
>>>>suit
>>>> the needs of both single-segment and multi-segment PWs.
>>>>
>>>>
>>>>
>>>> VCCV Type 3 is the only technique that can support segment-related OAM
>>>>for
>>>> multi-segment PWs. This is explained in detail in the Segmented PWs
>>>>draft
>>>> (now in the RFC Editor queue) with many examples, and it is not
>>>>affected by
>>>> presence or absence of the CW in encapsulation because S-PEs do not
>>>>examine
>>>> the CW. The same document  also precludes usage of VCCV Type 2 for
>>>> multi-segment PWs.
>>>>
>>>>
>>>>
>>>> When it comes to end-to-end (i.e., T-PE to T-PE) VCCV for MS-PWs, the
>>>>only
>>>> problem with VCCV Type 3 is the possibility of leaking a VCCV packet
>>>>out of
>>>> the PW if its TTL has not been set correctly by the transmitter. Hence
>>>>the
>>>> need to use VCCV Type 1 where possible.
>>>>
>>>>
>>>>
>>>> And of course, VCCV Type 1 offers additional level of demuxing on
>>>>Channel
>>>> Type.
>>>>
>>>>
>>>>
>>>> Based on that, I¹d say that we should:
>>>>
>>>> ·         Actively discourage usage of VCCV Type 2 as not compatible
>>>>with
>>>> MS-PWs
>>>>
>>>> ·         Promote a combination of VCCV Type 3 and, where applicable,
>>>>VCCV
>>>> Type 1 as an approach that meets the needs of both single-segment and
>>>> multi-segment PWs.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>>      Sasha
>>>>
>>>>
>>>>
>>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>> Yaakov Stein
>>>> Sent: Thursday, November 11, 2010 10:42 AM
>>>> To: [email-masked]
>>>> Subject: [PWE3] VCCV usage
>>>>
>>>>
>>>>
>>>> Nick and all,
>>>>
>>>>
>>>>
>>>> I would like to follow through on my suggestion at the mike.
>>>>
>>>>
>>>>
>>>> I think the most reasonable VCCV usage should be as follows:
>>>>
>>>> 1)   For encaps that mandate CW use, type 1 (CW) MUST be used.
>>>>
>>>> 2)   For other encaps, if CW is being used, then type 1 SHOULD be used,
>>>>
>>>> and types 2 (router alert label) or 3 (TTL expiry) MAY be used.
>>>>
>>>> 3)   For other encaps when not using the CW, type 3 MUST be supported,
>>>>and 2
>>>> MAY be used.
>>>>
>>>>
>>>>
>>>> This reduces interop issues going forward, while not breaking existing
>>>> implementations without CWs.
>>>>
>>>>
>>>>
>>>> Y(J)S
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> pwe3 mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/pwe3
>>>>
>>>>
>>>
>>
>>
>>
>>--
>>Sriganesh Kini (Sri)
>>_______________________________________________
>>pwe3 mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

-- 
- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Sun, 14 Nov 2010 00:07:00 -0800

Hi Matthew,

So when CW is enabled, VCCV packet will not be forwarded to the AC
(even with incorrect TTL). So CW should be enabled in deployments
where that is a concern. In deployments where the number of PW hops is
well known (as is the case with the large deployed base of SS-PW),
Type-3 can be used without CW by setting TTL to 1.

Thanks

-- 
- Sri

---

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Mon, 15 Nov 2010 07:08:32 +0100

Hi Sri,

Yes, if you use the control word and check the first nibble of every
packet then that is Type 1. If you just rely on TTL expiry, that is type 3.

Matthew

On 14/11/2010 08:07, "Sriganesh Kini" <[email-masked]> wrote:

>> Yes, of course, but you still need the correct TTL to prevent the
>>packet from just being decapsulated and forwarded to the AC.
>>
>> Cheers
>> Matthew
>>
>>
>> Matthew
>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 08:25:15 +0200

Matthew, Sri and all,
I'd like to clarify these statements a bit (or, actually, my understanding of these statements).

1. Only T-PE can ever check the first nibble of the CW (or any other bits of the CW for what it matters).
2. Once TTL expiration results in delivering a packet to the control plane, there are at least two options to process this packet:
   a) Explicitly assume that the packet is IPv4 or IPv6. If this does not hold (wrong version in the first nibble, bad IPv4 header checksum etc.), discard it as an error, otherwise process it as any other IP packet. Please note that this does not require ability to process IP packets in the data plane
  b) In addition to a) above, allow first nibble to be 0b0001, and treat this as an indication that you've received a VCCV Type 1 packet (i.e. demultiplex by the Channel Type etc.). This is IMO a combination of VCCV Type 3 (used to deliver a packet to control plane) and VCCV Type 1 (use the Channel type for demultiplexing). 

I do not think that anything in the MPLS and/or PWE3 architecture prevents using such a combination.

Did I miss something?

Regards,
     Sasha

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Bocci, Matthew (Matthew) [[email-masked]]
Sent: Monday, November 15, 2010 8:08 AM
To: Sriganesh Kini
Cc: Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Hi Sri,

Matthew

---

From: Sriganesh Kini <[email-masked]>
Date: Sun, 14 Nov 2010 23:23:19 -0800

Matthew,

Since the definition of Type 3 in RFC 5085 specifically includes a PW
with CW (from section 5.1.1), I would interpret it as including
checking the first nibble (as required when CW is enabled). Moreover
Type 3 directly lends itself to MS-PW as the first nibble would not be
examined without the first condition of Type 3 i.e., TTL expiry.
Besides, Type 3 enables VCCV even without CW (something not allowed by
Type 1) which is useful.

Thanks

-- 
- Sri

---

From: Sami Boutros <[email-masked]>
Date: Sun, 14 Nov 2010 23:35:22 -0800

At 10:25 PM 11/14/2010, Alexander Vainshtein wrote:
>Matthew, Sri and all,
>I'd like to clarify these statements a bit (or, 
>actually, my understanding of these statements).
>
>1. Only T-PE can ever check the first nibble of 
>the CW (or any other bits of the CW for what it matters).
>2. Once TTL expiration results in delivering a 
>packet to the control plane, there are at least 
>two options to process this packet:
>    a) Explicitly assume that the packet is IPv4 
> or IPv6. If this does not hold (wrong version 
> in the first nibble, bad IPv4 header checksum 
> etc.), discard it as an error, otherwise 
> process it as any other IP packet. Please note 
> that this does not require ability to process IP packets in the data plane
>   b) In addition to a) above, allow first 
> nibble to be 0b0001, and treat this as an 
> indication that you've received a VCCV Type 1 
> packet (i.e. demultiplex by the Channel Type 
> etc.). This is IMO a combination of VCCV Type 3 
> (used to deliver a packet to control plane) and 
> VCCV Type 1 (use the Channel type for demultiplexing).
>
>I do not think that anything in the MPLS and/or 
>PWE3 architecture prevents using such a combination.
>
>Did I miss something?

At S-PE, agreed the only option that would work 
will be type 3 TTL expiry. However the VCCV 
packet can come with or without the CW, so there 
is a check for the 1st nibble there too, if there 
is no CW then we check if this is an ip packet.

Thanks,

Sami

>From: [email-masked] 
>[[email-masked]] On Behalf Of Bocci, 
>Matthew (Matthew) [[email-masked]]

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 09:49:52 +0200

Sami,
Lots of thanks for a prompt response.

Looks exactly like Option (b) in my email to me. Did I miss something?

Regards,
     Sasha
________________________________________
From: Sami Boutros [[email-masked]]
Sent: Monday, November 15, 2010 9:35 AM
To: Alexander Vainshtein; Bocci, Matthew (Matthew); Sriganesh Kini
Cc: Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Thanks,

Sami

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 15 Nov 2010 08:02:40 +0000

Sasha

> 1. Only T-PE can ever check the first nibble of the CW (or any other bits of the CW for what it matters).

Interesting how dogma has taken over here.
The really most important reason for using the CW is to mark the packet as being a PW packet
rather than an IP one, for intermediate devices that peek under the label stack.
So, whether or not you like it (and I personally would have preferred a less layer-violating solution)
we need to assume that everyone along the way is looking at the CW, even Ps.

Now, that doesn't mean that I would like to mandate peeking at the CW at S-PEs instead of TTL expiry.
It is obviously much cleaner to use TTL expiry FOR THAT PARTICULAR case.
For all other cases TTL is actually more work, since after detecting the packet,
the next step is to check the first nibble, which of course can lead to inconsistencies (as you point out).

BTW, while discussing inconsistencies, I find the following text, in the relevant section
of the segmented PW draft, interesting :
 
   Assuming that all nodes along an MS-PW support the Control Word CC
   Type 3, VCCV between S-PEs may be accomplished using the PW label TTL
   as described above.

What is Control Word CC Type 3 ? Shouldn't that be VCCV Type 3 ? 

Putting that aside, the text regarding the mode to be used states as follows :

   VCCV CC type 3 will function correctly whether the CW is enable or not on the PW. 
   However VCCV type 1 for (which can be use for end to end
   verification only), is only supported if the CW is enabled.

The phrase "is only supported" is not clear."
It may mean "MUST be supported if CW is enabled"
or it may mean "MAY be supported if CW is enabled".

I read the former.
So, like the SS case with CW, the MS-PW MUST support Type 1,
although for segmental OAM, even when there is a CW, it uses TTL.

> 2. Once TTL expiration results in delivering a packet to the control plane, 
> there are at least two options to process this packet:
>   a) Explicitly assume that the packet is IPv4 or IPv6. If this does not hold (wrong version in the first nibble, bad > IPv4 header checksum etc.), discard it as an error, otherwise process it as any other IP packet. Please note that this > does not require ability to process IP packets in the data plane
>   b) In addition to a) above, allow first nibble to be 0b0001, and treat this as an indication that you've received a > VCCV Type 1 packet (i.e. demultiplex by the Channel Type etc.). This is IMO a combination of VCCV Type 3 (used to 
> deliver a packet to control plane) and VCCV Type 1 (use the Channel type for demultiplexing). 

Your "b" is actually REQUIRED if the VCCV payload is not IP encapsulated
(i.e., the associated channel type is not 21 or 57).

Y(J)S

---

From: Sami Boutros <[email-masked]>
Date: Mon, 15 Nov 2010 00:34:49 -0800

>Looks exactly like Option (b) in my email to me. Did I miss something?

Correct Saha, You may want to adjust your 1st point statement to say.

1- Without TTL expiration, Only T-PE can ever check the first nibble of the CW.

Thanks,

Sami

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 15 Nov 2010 00:50:32 -0800

Sasha, pls see inline

> 1. Only T-PE can ever check the first nibble of the CW (or any other bits of the CW for what it matters).

No. S-PE should examine it too when Type 3 is used and PW label TTL expires.

>   a) Explicitly assume that the packet is IPv4 or IPv6. If this does not hold (wrong version in the first nibble, bad IPv4 header checksum etc.), discard it as an error, otherwise process it as any…

This is applicable only when CW is not used. Also " ... process it as any othe

-- 
- Sri

---

From: Sriganesh Kini <[email-masked]>
Date: Mon, 15 Nov 2010 00:52:38 -0800

(ignore prev response. hit send too early).

Sasha, pls see inline

>   a) Explicitly assume that the packet is IPv4 or IPv6. If this does not hold (wrong version in the first nibble, bad IPv4 header checksum etc.), discard it as an error, otherwise process it as any…

Yes, modulo the neogtiated CV types. This is applicable when CW is not used.

>  b) In addition to a) above, allow first nibble to be 0b0001, and treat this as an indication that you've received a VCCV Type 1 packet (i.e. demultiplex by the Channel Type etc.). This is IMO a co…

Yes. But I am not sure of referring to it as a "VCCV Type 1 packet".
In fact none of the VCCV Types define a "VCCV packet format" per se.
It only provides mechanisms to do exception processing and specifies
where the start of a VCCV packet should be. E.g. even Type 3 defines
an operation with CW.

-- 
- Sri

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 13:32:04 +0200

Yaakov,
Lots of thanks for a prompt response.
Please see some answers inline below.

Regards,
     Sasha

-----Original Message-----
From: Yaakov Stein [mailto:[email-masked]] 
Sent: Monday, November 15, 2010 10:03 AM
To: Alexander Vainshtein; Bocci, Matthew (Matthew); Sriganesh Kini
Cc: [email-masked]
Subject: RE: [PWE3] VCCV usage

Sasha

Interesting how dogma has taken over here.
The really most important reason for using the CW is to mark the packet as being a PW packet
rather than an IP one, for intermediate devices that peek under the label stack.
So, whether or not you like it (and I personally would have preferred a less layer-violating solution)
we need to assume that everyone along the way is looking at the CW, even Ps.
[[[Sasha]]] I do not think that you compare apples to apples here. 
E.g.: 
- in the non-ECMP environments P routers do not have to look beyond the label stack;
 - LSRs that use label stack hashing for ECMP do not have to look at the CW either etc. 
In short, the original "first nibble" was just a precaution against some specific non-standardized
(even if de-facto popular) behavior. 
VCCV Type 1, as defined in RFC 5085, is IMO quite different.

Now, that doesn't mean that I would like to mandate peeking at the CW at S-PEs instead of TTL expiry.
It is obviously much cleaner to use TTL expiry FOR THAT PARTICULAR case.
[[[Sasha]]] So far, good!
For all other cases TTL is actually more work, since after detecting the packet,
the next step is to check the first nibble, which of course can lead to inconsistencies (as you point out).
[[[Sasha]]] IMHO inconsistencies can occur in all the cases. If you use CW and VCCV Type 1 you should still be ready to treat a packet with 0x3, or 0x13 in the first nibble (by discarding it). The only difference is that with TTL expiration there are 3 valid first nibble values for the CP (0x1, 0x4 and 0x6), while with "pure" VCCV Type 1 there are just two (0x0 and 0x1). 

[[[Sasha]]] I must admit that I cannot parse that. Maybe we should ask the Editors?

I read the former.

[[[Sasha]]] We seem to be in full agreement here.

[[[Sasha]]] Absolutely. On the other hand, I do not see any issue with encapsulating 
VCCV packets in UDP/IP (or in ICMP/IP as in the case of ICMP Ping). 
BW is not a real issue here, and, as I mentioned, handling IP packets in the data plane 
is not required either. 
(And obtaining a new UDP port from IANA for a new protocol is not all that different 
from requesting a new VCCV Channel type:-).

Y(J)S

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Nov 2010 04:18:09 -0800

Dear Sri,
you've wrote:
"Besides, Type 3 enables VCCV even without CW (something not allowed by Type
1) which is useful ..."
I think that VCCV means IP encapsulated packets, not PW ACH. And IP
encapsulated LSP or ICMP Ping can travel over Type 1 VCCV CC.

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 15 Nov 2010 04:26:13 -0800

Dear Sri,
"In fact none of the VCCV Types define a "VCCV packet format" per se."
Yes, you're right. I'd note that Type 1 VCCV impies use of PW ACH and thus
specific format.
Types 2 and 3 allow non-PW ACH, i.e. IP-encapsulated VCCV packets.

Regards,
Greg

On Mon, Nov 15, 2010 at 12:52 AM, Sriganesh Kini <
[email-masked]> wrote:

> > 2. Once TTL expiration results in delivering a packet to the control
> plane, there are at least two options to process this packet:
> >   a) Explicitly assume that the packet is IPv4 or IPv6. If this does not
> hold (wrong version in the first nibble, bad IPv4 header checksum etc.),
> discard it as an error, otherwise process it as any other IP packet. Please
> note that this does not require ability to process IP packets in the data
> plane
>
> >  b) In addition to a) above, allow first nibble to be 0b0001, and treat
> this as an indication that you've received a VCCV Type 1 packet (i.e.
> demultiplex by the Channel Type etc.). This is IMO a combination of VCCV
> Type 3 (used to deliver a packet to control plane) and VCCV Type 1 (use the
> Channel type for demultiplexing).
>
> > From: [email-masked] [[email-masked]] On Behalf Of Bocci,

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 15 Nov 2010 14:39:58 +0200

Hi all,
I present for your consideration the following use case.

1.       An MS-PW uses CW in encapsulation.

2.       End-to-end LSP Ping  in VCCV is used to check its continuity. Since encapsulation uses CW, VCCV Type 1 is used (as required by 5086).

3.       Loss of end-to-end continuity has been detected by end-to-end LSP-Ping, and the operator wants to localize the fault. In order to do that the operator employs LSP-Ping in the trace route mode.
How, in your opinion, would look LSP-PIng packets in this case? IMO

·         They would still use CW with 0b0001 in the first nibble and 21 as the Channel Type (because this is what the remote T-PE expects).

·         They would use TTL expiration in order to be terminated by S-PEs because there is no other way to do that.
Did I miss something?
Do you think that this use case is not relevant for MS-PW deployments (assuming there are – or will be – such)?

Regards,
     Sasha

From: Greg Mirsky [mailto:[email-masked]]
Sent: Monday, November 15, 2010 2:26 PM
To: Sriganesh Kini
Cc: Alexander Vainshtein; Yaakov Stein; [email-masked]
Subject: Re: [PWE3] VCCV usage

Dear Sri,
"In fact none of the VCCV Types define a "VCCV packet format" per se."
Yes, you're right. I'd note that Type 1 VCCV impies use of PW ACH and thus specific format.
Types 2 and 3 allow non-PW ACH, i.e. IP-encapsulated VCCV packets.

Regards,
Greg
On Mon, Nov 15, 2010 at 12:52 AM, Sriganesh Kini <[email-masked]<mailto:[email-masked]>> wrote:
(ignore prev response. hit send too early).

Sasha, pls see inline

> From: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>] On Behalf Of Bocci, Matthew (Matthew) [[email-masked]<mailto:[email-masked]>]
> Cc: Yaakov Stein; [email-masked]<mailto:[email-masked]>
> On 14/11/2010 08:07, "Sriganesh Kini" <[email-masked]<mailto:[email-masked]>> wrote:
>
>>Hi Matthew,
>>
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> From: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>>> Cc: Yaakov Stein <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>> Sri,
>>>>
>>>> On 12/11/2010 21:26, "Sriganesh Kini" <[email-masked]<mailto:[email-masked]>>
>>>>wrote:
>>>>
>>>>>Yaakov,
>>>>>
>>>>> 2010 at 4:11 AM, Yaakov Stein <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>> From: Sri [mailto:[email-masked]<mailto:[email-masked]>]
>>>>>> Cc: Yaakov Stein; [email-masked]<mailto:[email-masked]>
>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>> Yaakov and all,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
>>>>>>>Behalf Of
>>>>>>> Yaakov Stein
>>>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>>>> [email-masked]<mailto:[email-masked]>
>>>>>[email-masked]<mailto:[email-masked]>
>>>> [email-masked]<mailto:[email-masked]>
>>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

--
- Sri
_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Luca Martini <[email-masked]>
Date: Mon, 15 Nov 2010 12:11:57 -0700

comments below.
Luca

> What is Control Word CC Type 3 ? Shouldn't that be VCCV Type 3 ? 
cc type 3 == VCCV type 3. that is a left over from Tom's edits.
I can fix that in the AUTH48 stage.

> The phrase "is only supported" is not clear."
why ???

> or it may mean "MAY be supported if CW is enabled".
no , it means "it is only supported  if the CW is enabled" seems very
clear to me .

you can add a MAY to it , but that is superfluous.