Subject: Re: [PWE3] BFD for MPLS PWs

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 29 Aug 2006 14:01:23 -0400

Hi Danny,

	Thanks for reviewing. Comments below.

> Just received this E-mail. I have a few comments on version 10 of the
> draft:
>
> 1. The following is stated in the draft:
>
>    4.3. TTL Expiry VCCV (Type 3)
>
>    The TTL of the PW label can be set to 1 to force the packet to be
>    processed within the destination router's control plane. This is
>    an inband control channel identification mechanism that is an
>    alternate to section 4.1.
>
>    To use this type, the control word MUST be used.
>
> I was wondering the reason for the last statement? I would have  
> expected
> to see MUST NOT.

	I think this is a typo; should be "MOST NOT".

> 2. The following is found in section  :
>
>    Implementations MUST NOT include both CV types of 0x02 and
>    0x04 simultaneously in a capability advertisement due to the
>    complexity of supporting both simultaneously to avoid ambiguity
>    and confusion about how to process and transmit Pseudowire status.
>    If a capability advertisement is received with both 0x02 and 0x04
>    types indicated, the PE MUST ignore the 0x04 bit.
>
> Am I correct in stating that the above should be 0x04 and 0x08  
> instead?

	Yes, this is a typo I missed.

> 3. Why is it stated in the draft that use of router alert label is
> preferred over TTL expiry? I would have assumed the opposite. In fact,
> the current code for XR picks TTL expiry over RA label.

	That is a mistake I fixed in version 11 (to be published).
The RA mode should be the least preferred mode.

> 4. The draft indicates that PWs should be torn down when the CV or CC
> types change. IMO, we should only tear down when strictly  
> necessary. If
> a node has the LSP Ping feature disabled, but is then turned on, there
> is no reason why the PWs need to be torn down.

	We originally added this to simplify implementation, but
I now see why it is important to allow a change of this on the fly
without disrupting the data flow for the PW. Let me suggest that we
allow changes only after a subsequent transmission of the interface
parameters TLV with new capabilities advertisements. In this case,
the sending PE MAY choose to send a different payload type. But
as originally stated, once it starts sending it, it MUST continue
with that type.  We want to avoid having to entertain different
payload types on the fly, which I think does complicate the
implementations. Although we might want to relax the MUST to a
SHOULD.

	--Tom

> Regards,
>
> Danny
>
>> From: Danny McPherson <[email-masked]>
>> Date: August 14, 2006 5:05:16 PM EDT
>> To: "Thomas D. Nadeau" <[email-masked]>
>> Cc: "pwe3 WG ((((((((E-mail))))))))" <[email-masked]>, Swallow
>> George <[email-masked]>, Pignataro Carlos <[email-masked]>,
>> Morrow Monique <[email-masked]>, Agarwal Rahul
>> <[email-masked]>, "Stewart (stbryant) Bryant"  
>> <[email-masked]>
>> Subject: Re: [PWE3] BFD for MPLS PWs
>>
>>
>> Yes folks, please consider this a LC on this section of the
>> text as we need to move forward.  If you've got comments
>> either way on this please post here ASAP.
>>
>> Thanks!
>>
>> -danny & stb
>>
>> On Aug 14, 2006, at 2:55 PM, Thomas D. Nadeau wrote:
>>
>>>
>>> 	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
>>>
>>>
>>>
>>>
>>> 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
>>>    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                |
>>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>>> +-+-+
>>>       |                    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.
>>>    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
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/pwe3
>

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

---

From: Luca Martini <[email-masked]>
Date: Wed, 30 Aug 2006 12:37:51 -0600

Thomas D. Nadeau wrote:
>> types change. IMO, we should only tear down when strictly necessary. If
Actually quoting RFC4447:
"
  -  Interface Parameter Sub-TLV

      This variable-length TLV is used to provide interface-specific
      parameters, such as attachment circuit MTU.

      Note that as the "interface parameter sub-TLV" is part of the FEC,
      the rules of LDP make it impossible to change the interface
      parameters once the pseudowire has been set up.  Thus, the
      interface parameters field must not be used to pass information,
      such as status information, that may change during the life of the
      pseudowire.  Optional parameter TLVs should be used for that
      purpose.
"

So the interface parameter sub-TLV cannot be "updated" wFrom [email-masked] Wed Aug 30 14:47:08 2006
Date: Wed, 30 Aug 2006 12:37:51 -0600
From: Luca Martini <[email-masked]>
To: "Thomas D. Nadeau" <[email-masked]>
Subject: Re: [PWE3] BFD for MPLS PWs
Cc: "George Swallow \(swallow\)" <[email-masked]>,
	"Carlos Pignataro \(cpignata\)" <[email-masked]>,
	"Monique Morrow \(mmorrow\)" <[email-masked]>, [email-masked],
	[email-masked], "Rahul Agarwal \(rahagarw\)" <[email-masked]>,
	"Stewart Bryant \(stbryant\)" <[email-masked]>

Thomas D. Nadeau wrote:
>> types change. IMO, we should only tear down when strictly necessary. If
Actually quoting RFC4447:
"
  -  Interface Parameter Sub-TLV

      This variable-length TLV is used to provide interface-specific
      parameters, such as attachment circuit MTU.

      Note that as the "interface parameter sub-TLV" is part of the FEC,
      the rules of LDP make it impossible to change the interface
      parameters once the pseudowire has been set up.  Thus, the
      interface parameters field must not be used to pass information,
      such as status information, that may change during the life of the
      pseudowire.  Optional parameter TLVs should be used for that
      purpose.
"

So the interface parameter sub-TLV cannot be "updated" without issuing  
a label withdraw message and re-advertising the FEC.

Luca

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 30 Aug 2006 15:27:04 -0400

On Aug 30, 2006, at 2:37 PM, Luca Martini wrote:

> So the interface parameter sub-TLV cannot be "updated" without  
> issuing  a label withdraw message and re-advertising the FEC.

	Good point. We should leave the text as we originally
had it, which agreed with your reference.

	--Tom

---

From: "Danny Prairie \(dprairie\)" <[email-masked]>
Date: Tue, 29 Aug 2006 11:55:48 -0400

I was wondering the reason for the last statement? I would have expected
to see MUST NOT.

Am I correct in stating that the above should be 0x04 and 0x08 instead?

Regards,

Danny

> <[email-masked]>, "Stewart (stbryant) Bryant" <[email-masked]>
>>    The first nibble is set to 0x0001 to indicate a channel associated
>>    fields are set to 0, the Version is 0, and the Channel Type is set
>>    to 0.
>>
>>    This is the preferred mode of VCCV operation when the control word
>>    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
>>    SHOULD be conveyed via BFD status codes as specified in [OAM-MAP].
>>    as LDP is available that can signal the AC/PW status to the remote
>>    SHOULD be transmitted to indicate this to the peer. However, if no