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

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Fri, 6 Oct 2006 15:51:29 -0400

Hi,

Here are a few comments I have on the PWE3-VCCV draft version 11.

Regards,

Danny

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:

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

   To make sure that VCCV packets follow the same path as the PW data
flow, 

   they SHOULD be encapsulated with the same PW demultiplexer and
trasported 

   over the same PSN tunnel.

MUST would be preferred IMO for PW demultiplexer. Even in the case of
the tunnel, why is it should??

Section 4:

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

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

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

                    as defined in [RFC4385].

Should 0b0001 be used instead of 0x? Not sure if there a 'standard' for
such usage in IETF docs.

Section 4:

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

   If a capability advertisement is received with 

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

   bit as if it were set to 0

If 0x08 and 0x04 are both advertised, should 0x8 not take precedence as
it provides richer functionality (assuming both sides support it). A
little more verbiage as to the differences and selection of 0x04 and
0x08 may be helpful to readers as well.

Section 5.1

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

   The Version and the Reserved

   fields are set to 0, the Version is 0, and the Channel Type is set 

   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?

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.

 

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

---

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

Thanks for reviewing.  Comments inline.
> 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:
>
> -----------------
>
>
>
>    To make sure that VCCV packets follow the same path as the PW  
> data flow,
>
> MUST would be preferred IMO for PW demultiplexer. Even in the case  
> of the tunnel, why is it should??
>
>
>
> Section 4:
>
> -----------------
>
>
>
> Should 0b0001 be used instead of 0x? Not sure if there a 'standard'  
> for such usage in IETF docs.

	Will fix the above.

> If 0x08 and 0x04 are both advertised, should 0x8 not take  
> precedence as it provides richer functionality (assuming both sides  
> support it).
	I agree, we should prefer 0x08 over 0x04.
> 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:

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