Subject: RE: [PWE3] VCCV-12 last call

From: "O'Connor, Don" <[email-masked]>
Date: Thu, 25 Jan 2007 16:46:51 -0600

Tom
 
Section 7 indicates that only one CC mode can be used - 
 
"In particular, once a valid CC Type is used by a PE (traffic 
   sent using that encapsulation), the PE MUST NOT send any
   traffic down another CC Type encapsulation."
 
There is no statement that only one CV Type can be used. However the current CV precedence rules in Section 7 imply that there is a restriction that only one CV mode can be used concurrently. 
 
I believe that it would be useful to have a CV mode with concurrent LSP Ping and BFD. So my request is to add a code point for the following 
 
LSP Ping + BFD for fault detection only
 
I would also suggest giving this code point the highest precedence in the Section 7 CV precedence table
 
Regards
 
Don

________________________________

From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Thu 1/25/2007 1:15 PM
To: O'Connor, Don
Cc: Stewart Bryant; pwe3
Subject: Re: [PWE3] VCCV-12 last call

On Jan 23, 2007, at 7:22 PM, O'Connor, Don wrote:

> My reading of VCCV - 12 is that
>
> 1) It only supports BFD Base and not MPLS BFD. It can be noted that 
> draft-ietf-bfd-mpls-03.txt. is not listed among the references

        BFD-base is only required because the bootstrapping rules required to
setup BFD/VCCV are single-hop style.

> 2) It is only possible to negotiate (by LDP) one CV protocol - ICMP 
> Ping, LSP Ping, or BFD (Base). So it is not possible to support 
> MPLS BFD which enables concurrent use of LSP Ping and BFD

        You do not negotiate anything per se; you advertise capabilities for
VCCV. You may advertise none, one or all of the different CC/CV 
combinations,
which means you are willing to accept any of those combinations 
(within the
rules stipulated in the draft). The receiving side is then free to send
any of those combinations (within the rules stipulated in the draft), 
but
once one is successfully sent (and acked), no others are allowed, and no
"re-negotiation" is allowed without bringing down the PW.  The latter 
comes
specifically from the rules stipulated in RFC 4447.

        --Tom

>
> Is my understanding accurate ?
>
> Regards
>
> Don
>
> -----Original Message-----
> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, January 22, 2007 7:35 AM
> To: pwe3
> Subject: [PWE3] VCCV-12 last call
>
>
> This is the start of last call for
>
> Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-12.txt
>
> last call will end 6th February.
>
> There are a couple of issues that I have with regard to
> IANA policy that is raised by this draft, but I will
> ask my questions in another thread.
>
> Regards
>
> Stewart
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

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

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jan 2007 15:24:38 +0000

I think that there are many cases where it's reasonable to
use more than one connectivity verifications mode.

For example one mode that synchronises a lot of state and
a second lightwight mode that does fast a fast simple
connectivity check.

Stewart

O'Connor, Don wrote:

> There is no statement that only one CV Type can be used. However the 
> current CV precedence rules in Section 7 imply that there is a 
> restriction that only one CV mode can be used concurrently.
>  
> I believe that it would be useful to have a CV mode with concurrent LSP 
> Ping and BFD. So my request is to add a code point for the following
>  
> ------------------------------------------------------------------------

---

From: Danny Prairie <[email-masked]>
Date: Fri, 26 Jan 2007 10:33:44 -0500

Hi Don,

Good point about the CV. That being said, I would advocate not encoding the
allowed combinations explicitly, but rather advertise the capabilities of
the node, and have the peer decide which type of verification operations it
will perform, potentially also including the use of BFD and LSP Ping
concurrently.

Regards,

Danny

On 1/25/07 5:46 PM, "O'Connor, Don" <[email-masked]> wrote:

> There is no statement that only one CV Type can be used. However the current
> CV precedence rules in Section 7 imply that there is a restriction that only
> one CV mode can be used concurrently.
>  
> I believe that it would be useful to have a CV mode with concurrent LSP Ping
> and BFD. So my request is to add a code point for the following
>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 26 Jan 2007 15:36:13 +0000

I agree

- Stewart

Danny Prairie wrote:
> Hi Don,
> 
> Good point about the CV. That being said, I would advocate not encoding 
> the allowed combinations explicitly, but rather advertise the 
> capabilities of the node, and have the peer decide which type of 
> verification operations it will perform, potentially also including the 
> use of BFD and LSP Ping concurrently.
> 
> Regards,
> 
> Danny
> 
> 
>     I believe that it would be useful to have a CV mode with concurrent
>     LSP Ping and BFD. So my request is to add a code point for the
>     following
>

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 26 Jan 2007 12:12:37 -0600

Danny,
I made the same proposal in my LC comments. The problem is what you are
proposing is not allowed by the text in Section 4. The first and second
paragraphs read:
"  VCCV can support several types of connectivity verification types (CV

   types) or protocols within several possible control channel as 
   defined by the control channel type (CC types), but it does not 
   support the use of more than one combination of both concurrently. 
   The specific type or types of VCCV packets accepted by a router are
   indicated during capability advertisement as described in sections 
   5.5 and 6.2. The various VCCV CV types supported MUST be used
   only when they apply to the context of the PW demultiplexor in use.
   For example, LSP Ping type should only be used when MPLS is utilized
   as the PSN.
 
   Once a set of capabilities if advertised, the specific one chosen 
   based on the preferred order specified below in section 7. Once 
   a specific CC and CV type combination has been chosen, transmitted 
   and replied to, this type combination MUST be the only one used 
   until such time as the Pseudowire is re-signaled." 
 
Then, the first paragraph in Section 7 reads:
"  When a PE receives a VCCV capability advertisement,
   the advertisement may potentially contain more than one CC or
   CV Type. In this case, it MUST use the following rules when 
   choosing which CC or CV type to use. It may only choose one mode
   based on the rules stipulated in sections 4 and 5 above. In
   particular, once a valid CC Type is used by a PE (traffic
   sent using that encapsulation), the PE MUST NOT send any
   traffic down another CC Type encapsulation."
 
This suggests that a PE will pick a single CC type, which we want to
enforce, and a single CV type, which we want to relax for LSP Ping and
BFD type 0x04.
 
Furthermore, I cannot find any text which explicitly states that a PE
compares VCCV capabilities it advertized and those it received from its
peer to perform the match. After the match is made, then the PE picks up
a single CC type from the common set following the precedence orders.
For CV types, the PE can pick up more than one as long as you abide by
the restrictions governing the use of the BFD types, i.e.,:
1.  If both types 0x08 and 0x04 are part of the match, ignore 0x04.
2.  If both types 0x10 and 0x20 are part of the match, ignore 0x10
(there is a typo in the paragraph before last in Section 4 which said
that 0x20 must be ignored).
3. If 0x08 or 0x20 is selected, status is converyed using BFD.
4. Types 0x08 and 0x020 should not be selected if the PE uses LDP status
notifications.  
5. If type 0x04 or 0x10 is selected, status should still be conveyed
using LDP status notifications.
 
Mustapha.

	From: Danny Prairie [mailto:[email-masked]] 
	Sent: Friday, January 26, 2007 10:34 AM
	To: O'Connor, Don; Thomas D. Nadeau
	Cc: pwe3; Stewart Bryant
	Subject: Re: [PWE3] VCCV-12 last call

	Hi Don,
	
	Good point about the CV. That being said, I would advocate not
encoding the allowed combinations explicitly, but rather advertise the
capabilities of the node, and have the peer decide which type of
verification operations it will perform, potentially also including the
use of BFD and LSP Ping concurrently.
	
	Regards,
	
	Danny

	On 1/25/07 5:46 PM, "O'Connor, Don" <[email-masked]>
wrote:

		Tom

		"In particular, once a valid CC Type is used by a PE
(traffic 
		   sent using that encapsulation), the PE MUST NOT send
any
		   traffic down another CC Type encapsulation."
		
		There is no statement that only one CV Type can be used.
However the current CV precedence rules in Section 7 imply that there is
a restriction that only one CV mode can be used concurrently. 
		
		I believe that it would be useful to have a CV mode with
concurrent LSP Ping and BFD. So my request is to add a code point for
the following 

		I would also suggest giving this code point the highest
precedence in the Section 7 CV precedence table
		
		Regards
		
		Don

		
		
		> draft-ietf-bfd-mpls-03.txt. is not listed among the
references
		
		        BFD-base is only required because the
bootstrapping rules required to
		setup BFD/VCCV are single-hop style.
		
		> MPLS BFD which enables concurrent use of LSP Ping and
BFD
		
		        You do not negotiate anything per se; you
advertise capabilities for
		VCCV. You may advertise none, one or all of the
different CC/CV 
		combinations,
		which means you are willing to accept any of those
combinations 
		(within the
		rules stipulated in the draft). The receiving side is
then free to send
		any of those combinations (within the rules stipulated
in the draft), 
		but
		once one is successfully sent (and acked), no others are
allowed, and no
		"re-negotiation" is allowed without bringing down the
PW.  The latter 
		comes
		specifically from the rules stipulated in RFC 4447.
		
		        --Tom

---

From: Danny Prairie <[email-masked]>
Date: Fri, 26 Jan 2007 13:58:40 -0500

Hi Mustapha,

You are correct, we need to change the below text to reflect the behavioural
change I suggested in my previous E-mail.

Regards,

Danny

On 1/26/07 1:12 PM, "AISSAOUI Mustapha"
<[email-masked]> wrote:

> This suggests that a PE will pick a single CC type, which we want to enforce,
> and a single CV type, which we want to relax for LSP Ping and BFD type 0x04.
>  
> Furthermore, I cannot find any text which explicitly states that a PE compares
> VCCV capabilities it advertized and those it received from its peer to perform
> the match. After the match is made, then the PE picks up a single CC type from
> the common set following the precedence orders. For CV types, the PE can pick
> up more than one as long as you abide by the restrictions governing the use of
> the BFD types, i.e.,:
> 2.  If both types 0x10 and 0x20 are part of the match, ignore 0x10 (there is a
> typo in the paragraph before last in Section 4 which said that 0x20 must be
> ignored).
> 5. If type 0x04 or 0x10 is selected, status should still be conveyed using LDP
> status notifications.
>  
> Mustapha.
> 
>>  
>>  
>> 
>>> current CV  precedence rules in Section 7 imply that there is a restriction
>>> that only  one CV mode can be used concurrently.
>>>

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 26 Jan 2007 13:09:47 -0600

Danny and Tom,
if there are no objections, I would like to propose we use the text in
the last paragraph in my email below to Section 4 to clarify this
behaviour.
 
Mustapha.

	From: Danny Prairie [mailto:[email-masked]] 
	Sent: Friday, January 26, 2007 1:59 PM
	To: AISSAOUI Mustapha; O'Connor, Don; Tom Nadeau (tnadeau)
	Cc: pwe3; Stewart Bryant (stbryant)
	Subject: Re: [PWE3] VCCV-12 last call

	Hi Mustapha,
	
	You are correct, we need to change the below text to reflect the
behavioural change I suggested in my previous E-mail.
	
	Regards,
	
	Danny

		Danny,
		I made the same proposal in my LC comments. The problem
is what you are proposing is not allowed by the text in Section 4. The
first and second paragraphs read:
		"  VCCV can support several types of connectivity
verification types (CV 
		   types) or protocols within several possible control
channel as 
		   defined by the control channel type (CC types), but
it does not 
		   support the use of more than one combination of both
concurrently. 
		   The specific type or types of VCCV packets accepted
by a router are
		   indicated during capability advertisement as
described in sections 
		   5.5 and 6.2. The various VCCV CV types supported MUST
be used
		   only when they apply to the context of the PW
demultiplexor in use.
		   For example, LSP Ping type should only be used when
MPLS is utilized
		   as the PSN.
		
		  Once a set of capabilities if advertised, the specific
one chosen 
		   based on the preferred order specified below in
section 7. Once 
		   a specific CC and CV type combination has been
chosen, transmitted 
		   and replied to, this type combination MUST be the
only one used 
		   until such time as the Pseudowire is re-signaled." 
		
		Then, the first paragraph in Section 7 reads:
		"  When a PE receives a VCCV capability advertisement,
		   the advertisement may potentially contain more than
one CC or
		   CV Type. In this case, it MUST use the following
rules when 
		   choosing which CC or CV type to use. It may only
choose one mode
		   based on the rules stipulated in sections 4 and 5
above. In
		   particular, once a valid CC Type is used by a PE
(traffic
		   sent using that encapsulation), the PE MUST NOT send
any
		   traffic down another CC Type encapsulation."
		
		This suggests that a PE will pick a single CC type,
which we want to enforce, and a single CV type, which we want to relax
for LSP Ping and BFD type 0x04.
		
		Furthermore, I cannot find any text which explicitly
states that a PE compares VCCV capabilities it advertized and those it
received from its peer to perform the match. After the match is made,
then the PE picks up a single CC type from the common set following the
precedence orders. For CV types, the PE can pick up more than one as
long as you abide by the restrictions governing the use of the BFD
types, i.e.,:
		1. If both types 0x08 and 0x04 are part of the match,
ignore 0x04.
		2.  If both types 0x10 and 0x20 are part of the match,
ignore 0x10 (there is a typo in the paragraph before last in Section 4
which said that 0x20 must be ignored).
		3. If 0x08 or 0x20 is selected, status is converyed
using BFD.
		4. Types 0x08 and 0x020 should not be selected if the PE
uses LDP status notifications.  
		5. If type 0x04 or 0x10 is selected, status should still
be conveyed using LDP status notifications.
		
		Mustapha.

			Hi Don,
			
			Good point about the CV. That being  said, I
would advocate not encoding the allowed combinations explicitly, but
rather advertise the capabilities of the node, and have the peer decide
which  type of verification operations it will perform, potentially also
including  the use of BFD and LSP Ping  concurrently.
			
			Regards,
			
			Danny

			On 1/25/07 5:46 PM,  "O'Connor, Don"
<[email-masked]> wrote:

				Tom
				
				Section 7  indicates that only one CC
mode can be used - 
				
				"In particular,  once a valid CC Type is
used by a PE (traffic 
				   sent  using that encapsulation), the
PE MUST NOT send  any
				   traffic down another CC Type
encapsulation."
				
				There is no  statement that only one CV
Type can be used. However the current CV  precedence rules in Section 7
imply that there is a restriction that only  one CV mode can be used
concurrently. 
				
				I believe that  it would be useful to
have a CV mode with concurrent LSP Ping and BFD. So my  request is to
add a code point for the following 

				I would also  suggest giving this code
point the highest precedence in the Section 7 CV  precedence table
				
				Regards
				
				Don

				From: Thomas D. Nadeau
[mailto:[email-masked]]
				Sent:  Thu 1/25/2007 1:15 PM
				To: O'Connor, Don
				Cc: Stewart  Bryant; pwe3
				Subject: Re: [PWE3] VCCV-12 last call

				On Jan 23, 2007, at 7:22 PM,  O'Connor,
				
				> draft-ietf-bfd-mpls-03.txt. is not
listed among the  references
				
				        BFD-base  is only required
because the bootstrapping rules required to
				setup  BFD/VCCV are single-hop style.
				
				> MPLS BFD which enables  concurrent use
of LSP Ping and  BFD
				
				        You do not  negotiate anything
per se; you advertise capabilities for
				VCCV. You may  advertise none, one or
all of the different CC/CV 
				combinations,
				which  means you are willing to accept
any of those combinations 
				(within  the
				rules stipulated in the draft). The
receiving side is then free to  send
				any of those combinations (within the
rules stipulated in the  draft), 
				but
				once one is successfully sent (and
acked), no others are  allowed, and no
				"re-negotiation" is allowed without
bringing down the PW.   The latter 
				comes
				specifically from the rules stipulated
in RFC  4447.
				
				        --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 26 Jan 2007 15:16:17 -0500

Mustapha,

	The restrictions in question pertains to re-signaling of the PWs
and their associated capabilities AFTER they have been signaled
with LDP. This is the references to RFC 4447.  We further constrained
the use of a CC/CV combination based on that, although it seems
this was a bit heavy-handed.  So while I still agree that we must not
allow re-signaling of capabilities after the PW comes up, we should
allow the use of different CC/CV types (as per the advertisement
and recommended precedence rules).

	--Tom

> Danny,
> I made the same proposal in my LC comments. The problem is what you  
> are proposing is not allowed by the text in Section 4. The first  
> and second paragraphs read:
> This suggests that a PE will pick a single CC type, which we want  
> to enforce, and a single CV type, which we want to relax for LSP  
> Ping and BFD type 0x04.
>
> Furthermore, I cannot find any text which explicitly states that a  
> PE compares VCCV capabilities it advertized and those it received  
> from its peer to perform the match. After the match is made, then  
> the PE picks up a single CC type from the common set following the  
> precedence orders. For CV types, the PE can pick up more than one  
> as long as you abide by the restrictions governing the use of the  
> BFD types, i.e.,:
> (there is a typo in the paragraph before last in Section 4 which  
> said that 0x20 must be ignored).
> 4. Types 0x08 and 0x020 should not be selected if the PE uses LDP  
> status notifications.
> 5. If type 0x04 or 0x10 is selected, status should still be  
> conveyed using LDP status notifications.
>
> Mustapha.
>
> encoding the allowed combinations explicitly, but rather advertise  
> the capabilities of the node, and have the peer decide which type  
> of verification operations it will perform, potentially also  
> There is no statement that only one CV Type can be used. However  
> the current CV precedence rules in Section 7 imply that there is a

---

From: Danny Prairie <[email-masked]>
Date: Fri, 26 Jan 2007 15:51:46 -0500

In regards to the CC, I would still like to see there be an ordering to
ensure there is no discrepancy with the expectation of a control word being
present on the packet.

Regards,

Danny

On 1/26/07 3:16 PM, "Tom Nadeau (tnadeau)" <[email-masked]> wrote:

>> compares VCCV capabilities it advertized and those it received from its peer
>> to perform the match. After the match is made, then the PE picks up a single
>> CC type from the common set following the precedence orders. For CV
>> types, the PE can pick up more than one as long as you abide by the
>> restrictions governing the use of the BFD types, i.e.,:
>>  
>> 2.  If both types 0x10 and 0x20 are part of the match, ignore 0x10 (there is
>> a typo in the paragraph before last in Section 4 which said that 0x20 must be
>> ignored).
>>  
>> 5. If type 0x04 or 0x10 is selected, status should still be conveyed using
>> LDP status notifications.
>>  
>>  
>>  
>> Mustapha.
>> 
>>  
>>>   
>>>   
>>> 
>>> the allowed combinations explicitly, but   rather advertise the capabilities
>>> of the node, and have the peer decide which   type of verification
>>> operations it will perform, potentially also including   the use of BFD and
>>> LSP Ping   concurrently.
>>> 
>>> Regards,
>>> 
>>> Danny
>>> 
>>>

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 26 Jan 2007 15:26:30 -0600

Absolutely. Only a single CC mode should be selected from the matching
set and if more than one match, use the precedence indicated in the
draft. For the CV type, it is allowed to select more than one as long as
one abides by the restrictions below.
 
Mustapha.

From: Danny Prairie [mailto:[email-masked]] 
Sent: Friday, January 26, 2007 3:52 PM
To: Tom Nadeau (tnadeau); AISSAOUI Mustapha
Cc: O'Connor, Don; pwe3; Stewart Bryant (stbryant)
Subject: Re: [PWE3] VCCV-12 last call

	In regards to the CC, I would still like to see there be an
ordering to ensure there is no discrepancy with the expectation of a
control word being present on the packet.
	
	Regards,
	
	Danny

	On 1/26/07 3:16 PM, "Tom Nadeau (tnadeau)" <[email-masked]>
wrote:

		Mustapha, 
		
		The restrictions in question pertains to re-signaling of
the PWs
		and their associated capabilities AFTER they have been
signaled
		with LDP. This is the references to RFC 4447.  We
further constrained
		the use of a CC/CV combination based on that, although
it seems
		this was a bit heavy-handed.  So while I still agree
that we must not
		allow re-signaling of capabilities after the PW comes
up, we should
		allow the use of different CC/CV types (as per the
advertisement
		and recommended precedence rules).
		
		--Tom

			Danny,
			
			I made the same proposal in my LC comments. The
problem is what you are proposing is not allowed by the text in Section
4. The first and second paragraphs read:
			
			"  VCCV can support several types of
connectivity verification types (CV 
			   types) or protocols within several possible
control channel as 
			   defined by the control channel type (CC
types), but it does not 
			   support the use of more than one combination
of both concurrently. 
			   The specific type or types of VCCV packets
accepted by a router are
			   indicated during capability advertisement as
described in sections 
			   5.5 and 6.2. The various VCCV CV types
supported MUST be used
			   only when they apply to the context of the PW
demultiplexor in use.
			   For example, LSP Ping type should only be
used when MPLS is utilized
			   as the PSN.

			   Once a set of capabilities if advertised, the
specific one chosen 
			   based on the preferred order specified below
in section 7. Once 
			   a specific CC and CV type combination has
been chosen, transmitted 
			   and replied to, this type combination MUST be
the only one used 
			   until such time as the Pseudowire is
re-signaled." 

			
			"  When a PE receives a VCCV capability
advertisement,
			   the advertisement may potentially contain
more than one CC or
			   CV Type. In this case, it MUST use the
following rules when 
			   choosing which CC or CV type to use. It may
only choose one mode
			   based on the rules stipulated in sections 4
and 5 above. In
			   particular, once a valid CC Type is used by a
PE (traffic
			   sent using that encapsulation), the PE MUST
NOT send any
			   traffic down another CC Type encapsulation."

			This suggests that a PE will pick a single CC
type, which we want to enforce, and a single CV type, which we want to
relax for LSP Ping and BFD type 0x04.

			Furthermore, I cannot find any text which
explicitly states that a PE compares VCCV capabilities it advertized and
those it received from its peer to perform the match. After the match is
made, then the PE picks up a single CC type from the common set
following the precedence orders. For CV types, the PE can pick up more
than one as long as you abide by the restrictions governing the use of
the BFD types, i.e.,:
			
			1.  If both types 0x08 and 0x04 are part of the
match, ignore 0x04.
			
			2.  If both types 0x10 and 0x20 are part of the
match, ignore 0x10 (there is a typo in the paragraph before last in
Section 4 which said that 0x20 must be ignored).
			
			3. If 0x08 or 0x20 is selected, status is
converyed using BFD.
			
			4. Types 0x08 and 0x020 should not be selected
if the PE uses LDP status notifications.  
			
			5. If type 0x04 or 0x10 is selected, status
should still be conveyed using LDP status notifications.

			Mustapha.

				  

				 From: Danny Prairie
[mailto:[email-masked]] 
				Sent: Friday, January 26, 2007 10:34
AM
				To: O'Connor, Don; Thomas D. Nadeau
				Cc: pwe3; Stewart   Bryant
				Subject: Re: [PWE3] VCCV-12 last call

				Hi Don,
				
				Good point about the CV. That being
said, I would advocate not encoding the allowed combinations explicitly,
but   rather advertise the capabilities of the node, and have the peer
decide which   type of verification operations it will perform,
potentially also including   the use of BFD and LSP Ping   concurrently.
				
				Regards,
				
				Danny

				

				Tom

				"In particular,     once a valid CC Type
is used by a PE (traffic 
				   sent     using that encapsulation),
the PE MUST NOT send     any
				   traffic down another CC Type
encapsulation."
				
				There is no     statement that only one
CV Type can be used. However the current CV     precedence rules in
Section 7 imply that there is a restriction that only     one CV mode
can be used concurrently. 

				LSP Ping + BFD     for fault detection
only
				
				I would also     suggest giving this
code point the highest precedence in the Section 7 CV     precedence
table
				
				Regards
				
				Don

				   From: Thomas D. Nadeau

				On Jan 23, 2007, at 7:22 PM,

				
				> 2) It is only possible to
negotiate (by LDP) one CV protocol - ICMP 
				> MPLS BFD which enables     concurrent
use of LSP Ping and     BFD
				
				        You do not     negotiate
anything per se; you advertise capabilities for
				VCCV. You may     advertise none, one or
all of the different CC/CV 
				combinations,
				which     means you are willing to
accept any of those combinations 
				(within     the
				rules stipulated in the draft). The
receiving side is then free to     send
				any of those combinations (within the
rules stipulated in the     draft), 
				but
				once one is successfully sent (and
acked), no others are     allowed, and no
				"re-negotiation" is allowed without
bringing down the PW.      The latter 
				comes
				specifically from the rules stipulated
in RFC     4447.
				
				        --Tom

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 26 Jan 2007 22:23:55 -0500

It seems there should be one further restriction. Only CC Type 1 (PW
ACH) has a PID (i.e, the Channel Type); for CC Types 2 and 3 (RA and
TTL), if wanting to have BFD and LSP Ping, BFD without IP/UDP headers
should not be used as a CV Type -- BFD with IP/UDP can be discriminated
from LSP Ping and ICMP using the IP Protocol/UDP Port numbers in that case.

Thanks,

--Carlos.

On 1/26/2007 4:26 PM, AISSAOUI Mustapha allegedly said the following:
> *From:* Danny Prairie [mailto:[email-masked]]
> *Sent:* Friday, January 26, 2007 3:52 PM
> *To:* Tom Nadeau (tnadeau); AISSAOUI Mustapha
> *Cc:* O'Connor, Don; pwe3; Stewart Bryant (stbryant)
> *Subject:* Re: [PWE3] VCCV-12 last call
> 
> 
>     In regards to the CC, I would still like to see there be an ordering
>     to ensure there is no discrepancy with the expectation of a control
>     word being present on the packet.
> 
>     Regards,
> 
>     Danny
> 
> 
>             I made the same proposal in my LC comments. The problem is
>             what you are proposing is not allowed by the text in Section
>             This suggests that a PE will pick a single CC type, which we
>             want to enforce, and a single CV type, which we want to
>             Furthermore, I cannot find any text which explicitly states
>             that a PE compares VCCV capabilities it advertized and those
>             it received from its peer to perform the match. After the
>             match is made, then the PE picks up a single CC type from
>             the common set following the precedence orders. For CV
>             types, the PE can pick up more than one as long as you abide
>             by the restrictions governing the use of the BFD types, i.e.,:
> 
>             ignore 0x10 (there is a typo in the paragraph before last in
>                  *From:* Danny Prairie   [mailto:[email-masked]]
>                 *Sent:* Friday, January 26, 2007 10:34   AM
>                 *To:* O'Connor, Don; Thomas D. Nadeau
>                 *Cc:* pwe3; Stewart   Bryant
>                 *Subject:* Re: [PWE3] VCCV-12 last call
> 
>                   
>                 Hi Don,
> 
>                 Good point about the CV. That being   said, I would
>                 advocate not encoding the allowed combinations
>                 explicitly, but   rather advertise the capabilities of
>                 the node, and have the peer decide which   type of
>                 verification operations it will perform, potentially
>                 also including   the use of BFD and LSP Ping   concurrently.
> 
>                 Regards,
> 
>                 Danny
> 
> 
>                     There is no     statement that only one CV Type can
>                     be used. However the current CV     precedence rules
>                     in Section 7 imply that there is a restriction that
>                     only     one CV mode can be used concurrently.
> 
>                     I believe that     it would be useful to have a CV
>                     mode with concurrent LSP Ping and BFD. So my
>                         request is to add a code point for the following
> 
>                     I would also     suggest giving this code point the
>                     highest precedence in the Section 7 CV
>                         precedence table
> 
>                     Regards
> 
>                     Don
> 
>                         
>                        *From:* Thomas D. Nadeau [mailto:[email-masked]]
>                     *Sent:*     Thu 1/25/2007 1:15 PM
>                     *To:* O'Connor, Don
>                     *Cc:* Stewart     Bryant; pwe3
>                     *Subject:* Re: [PWE3] VCCV-12 last call
> 
> 
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems