Subject: Re: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 18 Dec 2006 16:06:01 -0500

Hi,

	Sorry for the late reply to this, but I
finally dug my way out of my pile of work...

> Here are my comments:
>
> 1. Section 3 - third paragraph.
> There seems to be a confusion between inband/out-of-band encapsulation
> modes and the reply mode. The reply mode is dictated by the sender of
> the echo request and not decided by the receiver. The receiver will
> reply according to the requested method. If the requested mode is 4,
> then the receiver SHOULD reply using the VCCV control channel which  
> was
> signaled by the sender of the echo request. This could be an inband  
> (CW
> or TTL=1) or an out-of-band (router alert label).

	Yes, and that is what is meant by the statement.
The sender of the request message is what dictates which
return method is used. In the case of type 4 you are correct
that normal replies are sent inside the CW, but that you
could use TTL=1 or RA label.

> If this is not
> possible because the return path of the PW is Down, then a reply using
> reply mode 2 (IPv4 or IPv6 UDP packet) should be attempted.

	Yes.  And again, this is what the text is saying, right?

    Since a pseudowire service is bi-directional, the reply MAY be sent
    in-band over the PW in the reverse direction. Responses MUST
    be encapsulated so that they follow the return path of
    the pseudowire in this case. In-band responses MUST be attempted
    first. If an in-band test fails, the operator is advised to
    then use a subsequent test using an out-of-band reply mode such
    as Reply Mode 4 from [RFC4379], which will return the result
    to the sender via an application level control channel to
    determine the fault's direction.

> 2. Section 4 - First paragraph.
> a. I believe this paragraph should clarify that it applies to the CC
> Types and to the BFD CV Types only. The other CV Types can be used
> concurrently. For instance, it is perfectly valid to use 'LSP Ping'  
> and
> 'BFD for PW Fault Detection Only' CV Types at the same time over the
> same PW.

	The current document is very precise about allowing
only a single mode at one time, and not allowing re-advertisement
once one is used. Sections 5 and 6 are very explicit about this:

    The capability of which control channel type (CC Type) to
    use is advertised by a PE to indicate which of the various
    control channel types are supported. Once the receiving PE
    has chosen a mode to use, it MUST continue using this mode
    until such time as the PW is re-signaled. Thus, if a new CC
    type is desired, the PW must be torn-down and re-established.

> b. Also, we need to describe the procedures for re-signaling the PW  
> if a
> PE wants to change the CC type or the BFD CV Type while the PW is
> already established. Should this PE withdraw its label and release the
> label received from the peer PE?

	Again, this is something that is explicitly disallowed
in the document. The reasoning is that it violates how the
LDP signaling is defined for the PW in RFC4447.

	There is a sentence in section 4. CC and Types and
CV Type which appears as follows:

    If another is desired to be
    used once a PE has begun to use one, the pseudowire MUST
    be re-signaled.

	It should be clarified as follows:

4. CC Types and CV Types

    VCCV can support several types of connectivity verification
    types (CV types) or protocols within its control channel, but
    does not support more than one concurrently.  The specific
    type or types of VCCV packets accepted by a router are
    indicated during capability advertisement as described in
    section 4.5. The various VCCV CV types supported MUST be used
    only when they apply to the context of the PW demultiplexor in use.
    For example, LSP Ping type should only be used when MPLS is utilized
    as the PSN.

    Once a set of capabilities if advertised, the specific one chosen  
is based
    on the preferred order specified below in section 7. Once a specific
    type has been chosen, transmitted and replied to, this type MUST
    be the only one used until the pseudowire is re-signaled.  
Furthermore,
    based on the the procedures defined in [RFC4447] the pseudowire
    MUST be re-signaled if a different set of capabilities types is
    desired.

> 3. Section 4 - Last paragraph.
> The CV type 0x00 is described here but is not defined as a valid value
> earlier in the section.

	Done.

> 4. Section 4.1 - 3rd and 4th paragraphs.
> I believe the description of BFD timing out is not correct. When PE2
> does not receive BFD messages from PE1, it can only conclude that  
> the PW
> in the direction PE1-PE2 is down. It cannot conclude anything for the
> direction PE2-PE1.
> I believe the description in draft-ietf-pwe3-oam-msg-map-04.txt is
> correct.
>
>      "When the downstream PE (PE1) does not receive control messages
>      from the upstream PE (PE2) during a certain number of  
> transmission
>      intervals (a number provisioned by the operator), it declares  
> that
>      the PW in its receive direction is down. In other word, PE1  
> enters
>      the ''forward defect'' state for this PW. PE1 sends a message to
> PE2
>      with H=0 (i.e. "I do not hear you") and with diagnostic code  
> 1. In
>      turn, PE2 declares the PW is down in its transmit direction  
> and it
>      uses diagnostic code 3 in its control messages to PE1. PE2 enters
>      the ''reverse defect'' state for this PW."

	The text in question currently looks like this:

    When one of the PEs (PE2 from Figure 1) doesn't receive control
    messages from PE1 (from Figure 1) during the specified amount of
    time it declares that the PW in the direction from PE2 to PE1
    is down.

	Figure 1 has a topology like this:

	PE1 ---- PE2

	The text should read:

    When one of the PEs (PE2 from Figure 1) does not receive control
    messages from its peer PE (PE1 from Figure 1) during a certain
    number of transmission intervals (a number provisioned by the
    operator) PE2 declares that the PW in its receive direction is down.
    In other words, PE1 enters the "forward defect" state for this PW.
    PE1 then sends a message to PE2 with H=0 (i.e. "I do not hear you")
    and with Diagnostic code 1. In turn, PE2 declares the PW is down in
    its transmit direction and it uses Diagnostic code 3 in its control
    messages to PE1. PE2 enters the ''reverse defect'' state for this  
PW.

> 5. Section 4.1 - paragraph before last.
> The transition to Down state when both BFD and a control plane status
> are used should be:
> if (control plane == "Down" || BFD Status == "Down")
>             PW status = DOWN;

	Fixed.

> 6. Section 5.5 - Last paragraph
> Why should we have the exception when one side advertized no VCCV
> capability while the other advertized one? This is a complication for
> the implementation I would like to avoid. If a node signals no VCCV
> capability, it is unlikely that it will be able to generate a message
> using any of the encapsulations indicated by the peer.

	So the text in question is as follows:

    The exception to the rules given in the last two paragraphs above
    is when one side of the PW indicates no support for VCCV while the
    other indicates support for at least one control channel type. In
    this case, it is possible for one side of the PW to send VCCV
    messages (either requests or replies to requests).

	The reason we called out this case was for completeness.
It is possible that such a scenario is configured, and so the
specification needs to handle it.  Re-reading the text, I think
it should be changed a little to clarify things as follows:

    The exception to the rules given in the last two paragraphs above
    is when one side of the PW indicates no support for VCCV while the
    other indicates support for at least one control channel type. This
    case can be realized because the peer advertising 0x00 (None) to
    indicate that it has no desire to accept VCCV request messages
    for policy reasons, or because the functionality is incomplete on
    that device. In the case where it is configured due to policy
    reasons to not accept VCCV requests, it is still free to generate
    them to its peer if it received a capability advertisement
    from its peer advertising such capability. In this case, based on
    the rules already stated, it is allowed to generate VCCV request
    messages to which the peer will reply (as it has advertised the
    capability to accept VCCV messages of that type). However, the
    peer will not generate requests to it, as it has advertised no
    capabilities as stated earlier.

> 7. Section 7
> Precedence rules for CV Types make sense for the BFD values only. For
> instance, it is perfectly valid to use LSP Ping and 'BFD for PW Fault
> Detection Only' at the same time over the same PW.

	Again, the document as passed LC #1, explicitly stated
that 1 and only one mode was allowed once one is used.

> However, the BFD CV
> types have a precedence which MUST be enforced in the following order
> and only one Type MUST be used. The PW needs to be resignaled to  
> change
> the BFD CV type. Here is the precedence order:
>
> 	 0x04  BFD for PW Fault Detection Only.
>        0x08  BFD for PW Fault Detection and AC/PW Fault
>              Status Signaling.
>        0x10  BFD for PW Fault Detection Only. Carrying BFD payload
>              without IP headers.
>        0x20  BFD for PW Fault Detection and AC/PW Fault
>              Status Signaling. Carrying BFD payload without IP  
> headers.
> 8. Section 8.1.1 - 2nd sentence.
> I assume this sentence should read:
>   "CC Type values 0x01, 0x02, and 0x04
>    are specified in this document, CC Type values 0x08, 0x16
>    and 0x24 are to be assigned by IANA using the "Expert Review"
>    policy defined in [RFC2434]."
>
> What are CV Type values 0x16 and 0x24 intended for?
>
> 9. Section 8.1.2
> What are CV Type values 0x16 and 0x24 intended for?

	Yes, there were a few typos:

8.1.2. Connectivity Verification Types (CV Types)

    IANA is requested to set up a registry of "VCCV Control Verification
    Types".  These are 8 bitfield values. CV Type values 0x01, 0x02,  
0x04
    0x08, 0x10 and 0x20 are specified in Section 4 of this document. The

	--Tom

>
> Mustapha.
>
>> -----Original Message-----
>> From: Stewart Bryant [mailto:[email-masked]]
>> Sent: Wednesday, October 04, 2006 6:06 PM
>> To: pwe3
>> Subject: [Fwd: [PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt]
>>
>> This is the start of last call on draft-ietf-pwe3-vccv-11.txt
>>
>> Last call will finish on 28th Oct 2006, ie the Friday
>> following draft cutoff.
>>
>> Please read this draft and comment to the list as we need to
>> get this work completed.
>>
>> Thanks
>>
>> Stewart
>>
>>
>> -------- Original Message --------
>> Subject: 	[PWE3] I-D ACTION:draft-ietf-pwe3-vccv-11.txt
>> Date: 	Wed, 04 Oct 2006 15:50:01 -0400
>> From: 	[email-masked]
>> To: 	[email-masked]
>> CC: 	[email-masked]
>>
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>> This draft is a work item of the Pseudowire Emulation Edge to
>> Edge Working Group of the IETF.
>>
>> 	Title		: Pseudo Wire Virtual Circuit
>> Connectivity Verification (VCCV)
>> 	Author(s)	: T. Nadeau, et al.
>> 	Filename	: draft-ietf-pwe3-vccv-11.txt
>> 	Pages		: 27
>> 	Date		: 2006-10-4
>> 	
>> This document describes Virtual Circuit Connection Verification
>>    (VCCV) which provides a control channel that is associated
>>    with a pseudo wire (PW), as well as the corresponding
>>    operations and management functions such as connectivity
>>    verification to be used over that control channel. VCCV
>>    applies to all supported access circuit and transport types
>>    currently defined for PWs.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-11.txt
>>
>> To remove yourself from the I-D Announcement list, send a
>> message to [email-masked] with the word
>> unsubscribe in the body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>> Internet-Drafts are also available by anonymous FTP. Login
>> with the username "anonymous" and a password of your e-mail
>> address. After logging in, type "cd internet-drafts" and then
>> "get draft-ietf-pwe3-vccv-11.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> 	[email-masked].
>> In the body type:
>> 	"FILE /internet-drafts/draft-ietf-pwe3-vccv-11.txt".
>> 	
>> NOTE:	The mail server at ietf.org can return the document in
>> 	MIME-encoded form by using the "mpack" utility.  To use this
>> 	feature, insert the command "ENCODING mime" before the "FILE"
>> 	command.  To decode the response(s), you will need "munpack" or
>> 	a MIME-compliant mail reader.  Different MIME-compliant
>> mail readers
>> 	exhibit different behavior, especially when dealing with
>> 	"multipart" MIME messages (i.e. documents which have been split
>> 	up into multiple messages), so check your local documentation on
>> 	how to manipulate these messages.
>>
>> Below is the data which will enable a MIME compliant mail
>> reader implementation to automatically retrieve the ASCII
>> version of the Internet-Draft.
>>
>>
>>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

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