Re: [PWE3] BFD for MPLS PWs

[Carlos Pignataro <[e-mail]>]

Tom,

Please find a couple of comments inline.

On 8/14/2006 4:55 PM, Thomas D. Nadeau allegedly said the following:
> 	Based on the discussion thread we had on the
> list as well as the ones I had with various folks
> at the IETF meeting, the chairs asked me to update the
> text and post it here for discussion.  The text I have
> posted here is based on the latest version of the
> VCCV draft (version 10), so please use that as your
> reference point.  Please comment by COB on Friday,
> after which I will post the updated draft.
> 
> 	--Tom
> 

Please note I pasted the following small snip of VCCV draft version 10,
Section 4.1, to comment.

> 
> 4.1. Inband VCCV (Type 1)
>    The first nibble is set to 0x0001 to indicate a channel associated
>    with a pseudowire [RFC4385][RFC4446]. The Format ID and the reserved

                                               ^^^^^^^^^         ^^^^^^^
                                               Version          Reserved

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

     ^^^^ Why is the Channel Type set to zero for Inband VCCV (Type 1) -
     using an IP header, if rfc4385 defines 0x0021 and 0x0057? If zero,
     how is the dataplane differentiated from CC Type 4 (no IP Hdr) PW
     Associated Channel traffic if both are signaled and packets arrive
     over the Associated Channel with Channel Type 0?

> 
>    For example, the following is an example of how the ethernet control
>    word would be received [RFC4448]:

     ^^^^ Nit: Since it begins with 0001b, it's no longer an Eth CW but
     an ACH.

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

                                        ^
                                        misaligned.

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> 
> 
> 4.4. Inband VCCV Containing Payload Sans IP Headers (Type 4)
> 
>     The PW set-up protocol [RFC4447] determines whether a PW uses a
>     control word. When a control word is used, it SHOULD have the
>     following form for the purpose of indicating VCCV control
>     channel messages when they contain a CC type payload that is
>     not prepended with the standard IP/UDP header. For example, for
>     BFD as specified in [BFD]. More specificaly, the BFD
>     encapsulation begins immediately following the Channel Type
>     identifier as specified below.
> 
>     The PW Associated Channel for VCCV control channel traffic is
>     defined as follows in [RFC4385]:
> 
>        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|Version|   Reserved    |         Channel Type          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                    Figure 3: PW Associated Channel Header
> 
>     The first nibble is set to 0x0001 to indicate a channel associated
>     with a pseudowire [RFC4385][RFC4446]. The Format ID and the reserved

                                               ^^^^^^^^^         ^^^^^^^
                                               Version          Reserved

>     fields are set to 0, the Version is 0, and the Channel Type is set
>     to 0.
> 
>     For example, the following is an example of how VCCV would be
>     received containing BFD payload without IP/UDP headers [BFD]:
> 
> 
>           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                   |            0x08                |

                                                     ^^^^
                                         Wasn't the Channel Type 0x00?

>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |                    BFD Payload [BFD]                          |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>         Figure 5: PW Associated Channel Header for VCCV with BFD Payload
> 
> 
>     It should be noted that although some PW types are not required
>     to carry the control word, this type of VCCV MUST only be used
>     for those PW types that do employ the control word.
> 
>     This is the preferred mode of VCCV operation when the control word
>     is present and Type 1 is not available.
> 
> 
> 4.6.1 VCCV Capability Advertisement Sub-TLV
> 
>     [RFC4447] defines an Interface Parameter field in the LDP PW ID
>     FEC (FEC 128) and an Interface Parameters TLV in the LDP Generalized
>     PW ID FEC (FEC 129) to signal different capabilities for specific
>     PWs. An optional sub-TLV parameter is defined to indicate the
>     capability of supporting none, one or more control channel types
>     for VCCV. This is the VCCV parameter field. If FEC 128 is used the
>     VCCV parameter field is carried in the Interface Parameters field.
>     If FEC 129 is used it is carried as an Interface Parameter sub-TLV
>     in the Interface Parameters TLV.
> 
>     The VCCV parameter ID is defined as follows in [RFC4446]:
> 
>          Parameter ID   Length     Description
>            0x0c           4           VCCV
> 
>     The format of the VCCV parameter field is as follows:
> 
>      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |      0x0c     |       0x04    |   CC Types    |   CV Types    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>     The Control Channel (CC Types) type field defines a bitmask used to
>     indicate the type of control channel(s) (i.e.: none, one or more)
>     that a router is capable of receiving control channel traffic on.
>     If more than one control channel is specified, the router agrees
>     to accept control traffic over either control channel; however,
>     see the rules specified in section 6 for more details.

    Should these rules in Section 6 be updated to include the new CC
    Type? Specifically what if Types 1 and 4 are both signaled?

Thanks,

--Carlos.

>     If none of the types are supported, a CC Type Indicator of 0x00
>     SHOULD be transmitted to indicate this to the peer. However,
>     if no capability is signaled, then the PE MUST assume that its
>     peer is incapable of receiving any of the VCCV CC Types and
>     MUST NOT send any OAM control channel traffic to it. The
>     defined values for CC Types are:
> 
>         0x00 None
>         0x01 Type 1: PWE3 control word with 0x0001 as first nibble
>                      as defined in [RFC4385].
>         0x02 Type 2: MPLS Router Alert Label.
>         0x04 Type 3: MPLS PW Demultiplexor Label TTL = 1 (Type 3).
>         0x08 Type 4: PWE3 control word with 0x0001 as first nibble
>                      as defined in [RFC4385]. Carrying payload
>                      sans IP headers.
> 
>     The CV Type Indicators field is a bitmask used to indicate the
>     specific type or types (i.e.: none, one or more) of control channel
>     packets that may be sent on the specified control channel.  The
>     defined values for CV Types are:
> 
>         0x00  None.
>         0x01  ICMP Ping.
>         0x02  LSP Ping.
>         0x04  BFD for PW Fault Detection only.
>         0x08  BFD for PW Fault Detection and AC/PW Fault
>               Status Signaling.
>     It should be noted that two different CV Types have been defined
>     when BFD is used. In the case of type 0x08, the AC and PW status
>     SHOULD be conveyed via BFD status codes as specified in [OAM-MAP].
>     However, this type SHOULD NOT be used when a control protocl such
>     as LDP is available that can signal the AC/PW status to the remote
>     endpoint of the PW due to complications that can arise from
>     synchronization issues between the control protocol's status
>     signaling messags and the BFD messages containing fault status
>     information.
> 
>     If none of the types above are supported, a CV Type Indicator of  
> 0x00
>     SHOULD be transmitted to indicate this to the peer. However, if no
>     capability is signaled, then the peer MUST assume that the peer has
>     no VCCV capability. This bit MUST NOT be set if any of the others
>     are set. A PE receiving such a conflict MUST ignore the 0x00 bit
>     and consider the remaining bits that are set as if the 0x00 bit
>     were not set. If the CC Type is specified as 0x00 above, then the
>     CV Type field MUST be ignored, and assumed to be 0x00 (None) as
>     well.
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

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

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