Subject: [PWE3] RE: Comments on draft-ietf-pwe3-vccv-11.txt

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Fri, 6 Oct 2006 16:10:47 -0400

Hi Tom,

Please see inline.

Regards,

Danny

________________________________

From: Tom Nadeau (tnadeau) 
Sent: Friday, October 06, 2006 4:01 PM
To: Danny Prairie (dprairie)
Cc: PWE3 WG (E-mail); Carlos Pignataro (cpignata)
Subject: Re: Comments on draft-ietf-pwe3-vccv-11.txt

            Thanks for reviewing.  Comments inline.

 

Figure 2:

This may be a minor detail, but the VCCV may only extend between core
facing LCs, i.e. VCCV packets may not go from a given PEs core facing LC
and the AC interface

Section 3:

   they SHOULD be encapsulated with the same PW demultiplexer and
trasported

-----------------

    The defined values for CC Types are for MPLS PWs are:

       0x01 Type 1: PWE3 control word with 0x0001 as first nibble

Section 4:

   both 0x04 and 0x08 types indicated, the PE MUST ignore the 0x08

A little more verbiage as to the differences and selection of 0x04 and
0x08 may be helpful to readers as well.

            How does this sound:

[DP] Sounds good to me.

   It should be noted that two different pairs of CV Types have been

   defined when BFD is used. If both types are supported, both MUST be

   advertised as type 0x04 is not considered a subset of functionality
of

   that in 0x08. If a capability advertisement is received

   with both 0x04 and 0x08 types indicated, the receiving PE MUST ignore
the 

   0x08 bit as if it were set to 0 unless it cannot support the
transmission of type 0x08. 

	-----------------

	   The Version and the Reserved

	   to 0x21 for IPv4 and 0x56 for IPv6 payloads.

	Delete ',the Version 0,'

	Figure 4

	Should the channel type value be different for the BFD without
IP header case?

	The example is not showing an example of BFD sans IP/UDP
headers.

	I think we need to augment the text as follows:

	  For example, the following is an example of how the ethernet 

	   ACH would be received [RFC4448] containing an LSP Ping
payload

	   corresponding to a choice of CC Type of 0x01 and a CV Type of

	   0x02. This results in a Channel Type of 0x21, first nibble of
0001b

	   followed by an LSP ping payload.

	      0                   1                   2
3

	      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	      |0 0 0 1| 0 0 0 0 0 0 0 0 0 0 0 |            0x21
|

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	        Figure 4: PW Associated Channel Header for VCCV

	Should we include an example of BFD sans headers Channel Type

	encapsulation too, or is this sufficient?

	[DP] I believe an example for BFD would be helpful as well.

	

	5.5 VCCV Capability Advertisement for MPLS PSN

	-----------------

	Eventhough a PE may support TTL based CC, the P router
preceeding the PE must support the correct switching mode to ensure the
TTL of the PW label does not get overwritten with a larger TTL value.
This is none obvious to many.

            Will fix the above.

            --Tom

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 6 Oct 2006 16:13:15 -0400

On Oct 6, 2006, at 4:10 PM, Danny Prairie ((dprairie)) wrote:

> This may be a minor detail, but the VCCV may only extend between  
> core facing LCs, i.e. VCCV packets may not go from a given PEs core  
> facing LC and the AC interface
>
> Section 3:
>
>
>
> A little more verbiage as to the differences and selection of 0x04  
> and 0x08 may be helpful to readers as well.
>
>
>
>             How does this sound:
>
> [DP] Sounds good to me.
>
>
>
>    advertised as type 0x04 is not considered a subset of  
> functionality of
>
>    with both 0x04 and 0x08 types indicated, the receiving PE MUST  
> ignore the
>
>> Should the channel type value be different for the BFD without IP  
>> header case?
>>
>> The example is not showing an example of BFD sans IP/UDP headers.
>>
>>    ACH would be received [RFC4448] containing an LSP Ping payload
>>
>>       0                   1                   2                   3
>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>
>>       |0 0 0 1| 0 0 0 0 0 0 0 0 0 0 0 |             
>> 0x21               |
>>

	I will add one in v12.

	Merci!

	--Tom

>> Eventhough a PE may support TTL based CC, the P router preceeding  
>> the PE must support the correct switching mode to ensure the TTL  
>> of the PW label does not get overwritten with a larger TTL value.

---

From: <[email-masked]>
Date: Mon, 9 Oct 2006 11:54:02 +0100

Tom,

I haven't read the VCCV draft yet, so I may be mistaken but the last
sentence of the following doesn't make sense to me.

> I agree, we should prefer 0x08 over 0x04.
>
> How does this sound:
>
> advertised as type 0x04 is not considered a subset of functionality of
> the 0x08 bit as if it were set to 0 unless it cannot support the 

I believe you want to change the second reference to 0x08 to a reference
to 0x04 in the last sentence, so it reads as follows:

"If a capability advertisement is received with both 0x04 and 0x08 types
indicated, the receiving PE MUST ignore the 0x04 bit as if it were set
to 0 unless it cannot support the transmission of type 0x08."

Ben

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 9 Oct 2006 13:13:27 -0400

> to 0 unless it cannot support the transmission of type 0x08."

	Correct.

	--Tom