Subject: RE: [PWE3] BFD for MPLS PWs

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 9 Aug 2006 19:03:45 +0200

Tom,
Looks clear now.

Regards,
            Sasha

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Wednesday, August 09, 2006 5:57 PM
> To: Sasha Vainshtein
> Cc: Mustapha Aissaoui; Luca Martini; pwe3 WG ((((E-mail))))
> Subject: Re: [PWE3] BFD for MPLS PWs
> 
> 
> 
> > Tom,
> > For the sake of clarity:
> >
> > Did you intended to say
> >
> > 	"except where the PW control plane is used to setup the 
> control  
> > (a.k.a. "associated") channel?
> >
> > In which case I fully agree with you.
> 
> 	If (control plane is used to setup the PW)
> 		use it to set up the control channel;
> 	else // When it is not available...
> 		(manually establish the PW and
> 			manually establish the control channel);
> 
> 	--Tom
> 
> 
> >
> > Regards,
> >                     Sasha
> >
> >> -----Original Message-----
> >> From: Thomas D. Nadeau [mailto:[email-masked]]
> >> Sent: Wednesday, August 09, 2006 4:45 PM
> >> To: Mustapha Aissaoui
> >> Cc: 'Luca Martini'; 'pwe3 WG ((((E-mail))))'; Sasha Vainshtein
> >> Subject: Re: [PWE3] BFD for MPLS PWs
> >>
> >>
> >>
> >> 	The PW's control channel is orthogonal to
> >> the control plane used to setup the PW (if it
> >> exists) except where the control channel is used
> >> to setup the control channel.
> >>
> >> 	--Tom
> >>
> >>> Luca,
> >>> We already have code points 0x04 and 0x08 for the cases below. The
> >>> only
> >>> justification I could find for not wanting to use an IP control
> >>> channel for
> >>> BFD over a PW is because some implementation may not use an
> >> IP control
> >>> plane, and thus no LDP.
> >>>
> >>> Mustapha.
> >>>
> >>>> -----Original Message-----
> >>>> From: Luca Martini [mailto:[email-masked]]
> >>>> Sent: Tuesday, August 08, 2006 7:16 PM
> >>>> To: Mustapha Aissaoui
> >>>> Cc: 'Thomas D. Nadeau'; 'pwe3 WG ((((E-mail))))'; 'Sasha
> >> Vainshtein'
> >>>> Subject: Re: [PWE3] BFD for MPLS PWs
> >>>>
> >>>> Mustapha,
> >>>>
> >>>> I do not agree with your slightly wider statement "an IP
> >>>> control plane may not exist for these implementations". We
> >>>> never said this.
> >>>> What we said is that the Ip header is superfluous for this
> >>>> particular application.
> >>>> The PW status messaging is required by RFC4447 ( the WG
> >>>> insisted on the MUST at the time ), so the VCCV should always
> >>>> use PW status, and may use  BFD status additionally.
> >>>>
> >>>> Option 4 is therefore required.
> >>>>
> >>>> Luca
> >>>>
> >>>>
> >>>> Mustapha Aissaoui wrote:
> >>>>> Tom and Sasha,
> >>>>> I do not see the need to add a CV type for the following:
> >>>>> 4) BFD (without IP headers) + status
> >>>>>
> >>>>> The argument used so far was that an IP control plane may
> >> not exist
> >>>>> for these implementations. Thus, we should restrict the new
> >>>>> encapsulation to work without PW status notifications only.
> >>>>>
> >>>>> Mustapha.
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Thomas D. Nadeau [mailto:[email-masked]]
> >>>>>> Sent: Tuesday, August 01, 2006 1:51 PM
> >>>>>> To: Sasha Vainshtein
> >>>>>> Cc: pwe3 WG ((((E-mail))))
> >>>>>> Subject: Re: [PWE3] BFD for MPLS PWs
> >>>>>>
> >>>>>>
> >>>>>> On Aug 1, 2006, at 1:07 PM, Sasha Vainshtein wrote:
> >>>>>>
> >>>>>>> Tom,
> >>>>>>> I've snipped the long discussion to make your summary and
> >>>>>> my response
> >>>>>>> clearly readable:
> >>>>>>>
> >>>>>>> ... snipped ...
> >>>>>>>>  Lets forget about the LSP ping mode for a second.
> >>>>>>>> For BFD there are currently 2 options:
> >>>>>>>> 1) BFD
> >>>>>>>> or
> >>>>>>>> 2) BFD + status codes.
> >>>>>>>> What is being proposed are 4 options now:
> >>>>>>>>
> >>>>>>>> 1) BFD (with IP headers)
> >>>>>>>> 2) BFD (with IP headers) + status
> >>>>>>>> 3) BFD (without IP headers)
> >>>>>>>> 4) BFD (without IP headers) + status.
> >>>>>>>>
> >>>>>>>> The intent was for options 1/2 to function as-specified
> >>>> today. The
> >>>>>>>> latter two are the optimized modes that are useful for
> >>>> those using
> >>>>>>>> the latest MPLS CW.
> >>>>>>>>
> >>>>>>>> 	--Tom
> >>>>>>> [Sasha] This short text clarifies the proposal, it's a
> >>>> pity we ahve
> >>>>>>> not started from this point.
> >>>>>>>
> >>>>>>> Now my question:
> >>>>>>>
> >>>>>>> Would it be correct to say that, where applicable, the
> >>>> actual OA&M
> >>>>>>> functionality (i.e. ability to detect and trouble-shoot PW
> >>>>>>> connectivity
> >>>>>>> problems)  provided by
> >>>>>>> options (3) and (4) is exactly the same as one provided
> >> by options
> >>>>>>> (1) and (2)
> >>>>>>> respectively, while applicability scope of options (1)
> >> and (2) is
> >>>>>>> strictly wider than that of (3) and (4)?
> >>>>>> 	I don't see why this matters. All 4 have their place.
> >>>>>>
> >>>>>> 	--Tom
> >>>>>>
> >>>>>>
> >>>>>>> Regards,
> >>>>>>>                         Sasha
> >>>>>> _______________________________________________
> >>>>>> 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
> >>>>
> >>
> 

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 14 Aug 2006 16:55:01 -0400

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.

---

From: Danny McPherson <[email-masked]>
Date: Mon, 14 Aug 2006 15:05:16 -0600

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:

>       |0 0 0 1|  0                   |             
> 0x08                |
>       |                    BFD Payload  
> [BFD]                          |

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 14 Aug 2006 22:25:18 -0400

Tom,

Please find a couple of comments inline.

> after which I will post the updated draft.

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

> 
> 4.1. Inband VCCV (Type 1)

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

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

     ^^^^ 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 0 0 1|  0                   |            0                   |

                                        ^
                                        misaligned.

>     defined as follows in [RFC4385]:

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

>     received containing BFD payload without IP/UDP headers [BFD]:

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

    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.

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

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Tue, 15 Aug 2006 08:18:04 +0200

Tom and all,
I am sorry to say that I am completely confused by the proposed text.

1.	
	Figure 3 in the new text (taken from RFC 4385) shows the following fieds in the Associated/Control Channel CW:

	*	
		The first nibble (set to '0001')
	*	
		The next nibble (Version) that, according to 4385 MUST be 0
	*	
		The next 8 bits that are Reserved
	*	
		The next 16 bits that define the Channel Type. According to 4385, IANA sets up a dedicated registry for the PW Associated Channel Types. The current state of this registry defines 2 types matching (to the best of my recollection, by design) the PPP Protocol numbers for the corresponding payload:

			*	
				0x21    Associated Channel carries an IPv4 packet   
			*	
				0x57    Associated Channel carries an IPv6 packet

2.	
	At the same time, the text that immediately follows this diagram:

	*	
		 Refers, in addition to these, to a Format ID (???) field which is neither defined in RFC 4385 nor shown in the the diagram. 
	*	
		 States that ALL the fields mentioned (excluding the first nibble) are set to 0

3.	
	On top of that, the next diagram (for whatever reasons labeled as Figure 5?!) shows an example of the VCCV CW where the Channel Type field is set to 8 (?), with the BFD Payload immediately following. Note that the mythical number 8 is not explained in the text but can be found later twicce in the part of the text that describes advertisement of the VCCV capabilities in the control plane:

	*	
		As the bit mask indicating ability to carry non-IP payloads
	*	
		As the bit mask indicating ability to use BFD with status indication

4.	
	The text also states that BFD without IP headers is the preferred form of BFD to use with the PWs that employ the CW. But this statement is neither explained nor expressed as a typical IETF requirement (MUST? SHOULD?) so that it can be probably ignored.
5.	
	There seems to be no request to IANA to alllocate a new Associated Channel Type (or types) in the the above-mentioned registry

This said, I think that the following TECHNICAL issues MUST be resolved before proceeding with the draft:

1.	
	Clear-cut differentiation between the VCCV types used in the control plane (capability advertisements) and Associated Channel types required to carry non-IP payloads. In particular:

	*	
		We should decide whether we want to keep the earlier design of using the PPP DLL numbers as the Associated Channel types
	*	
		If we decide to keep it (and I support that), an appropriate allocation by IANA (in the PPP DLL numbers registry) MUST be requested in parallel with the request to allocate (the same number as) the Associated Channel type for non-IP BFD payloads

			*	
				The PPP DLL numbers regitsry operates in the "expert review"  mode
			*	
				The value 8 belongs to a reserved (0x7 to 0x1f) area in this registry with the comment that "transparency is not sufficient" for this range (whatever this means)

2.	
	Clear-cut specification of the requirement levels where alternative encapsulations (BFD with IP vs. BFD without IP) exist, including specification of the mandatory encapsulation required for mutual interoperability.

And, of course, the text should be carefully cleaned from "unresolved references" like Format ID mentioned above.

Hopefully this clarifies my position.

Regards,

                      Sasha

________________________________

From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Mon 14/08/2006 23:55
To: pwe3 WG ((((((((E-mail))))))))
Cc: Swallow George; Pignataro Carlos; Morrow Monique; Danny McPherson; Agarwal Rahul; Stewart (stbryant) Bryant
Subject: Re: [PWE3] BFD for MPLS PWs

        --Tom

       0                   1                   2                   3

          0                   1                   2                   3

     0                   1                   2                   3

        0x00 None

        0x00  None.
        0x01  ICMP Ping.
        0x02  LSP Ping.

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 15 Aug 2006 16:23:56 +0200

Tom, 

Although others have already commented,
here are my comments on a few snippets of the proposed text:

What is the "Format ID" ?

The channel type must be set to 0x21, 0x57, or whatever is assigned
for the raw BFD protocol.

          0                   1                   2                   3

Why is the channel type = 0x08 ? Is this what you want assigned
for the raw BFD case ? Up to now we have been reusing assignments
from the PPP datalink protocol field - in which case 0x08 is part of
the "reserved (transparency inefficient)" block.

Can CC of 0x01 and 0x08 be used simultaneously ?

        0x00  None.
        0x01  ICMP Ping.
        0x02  LSP Ping.

I suggest adding a note stating:
Bitmasks imply that more than one of the CV types may be used
simultaneously.
Types 0x01 through 0x04 can be differentiated based on the fact that
they
have channel type 0x21/57 and appropirate UDP port numbers.
Type 0x08 can be unquely identified by channel type (whatever IANA
assigns, e.g. 0x08)

nit -  protocol

    are set. 

bit? This is a byte. If it is zero then none of the CV types are
specified.

    A PE receiving such a conflict MUST ignore the 0x00 bit

bit?

Y(J)S