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

From: Stewart Bryant <[email-masked]>
Date: Wed, 04 Oct 2006 23:05:46 +0100

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

---

From: <[email-masked]>
Date: Tue, 10 Oct 2006 15:53:16 +0100

Colleagues,

A couple of comments on draft-ietf-pwe3-vccv-11.

The first three diagrams and their numbering/labelling seems a bit
messed up.  The first diagram is not labelled.  Figure 1 shows that the
PW starts at the ingress of the PE, the unlabelled diagram (the actual
Figure 1 I assume?) shows that the PW starts in the middle of the PE.

It states "Figure 2 illustrates the network reference model for point to
point PWs" Is this reference to 'Figure 2' meant to actually reference
the unlabelled diagram?

Figure 1 uses the abbreviation 'AC' but this abbreviation is never
expanded either in the diagram or in the text.

Section 4.1 - s/contorl/control/

Section 7 - s/precidence/precedence/

Also in section 7 to remove any possibility of ambiguity it might be
worth making it explicit that the order of precedence in the lists is
top to bottom (I assume that is the order intended?).

Ben

-- 
Ben Niven-Jenkins
Network Architect, BT Exact
  
E-mail: [email-masked] 
Office: +44 (0)1473 648225
Mobile: +44 (0)7918 077205
   Fax: +44 (0)1332 578827

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 10 Oct 2006 11:06:55 -0400

> point PWs" Is this reference to 'Figure 2' meant to actually reference

	Will make consistent.

> expanded either in the diagram or in the text.

	Yes, others have made this same comment.

> Section 7 - s/precidence/precedence/

	OK.

> top to bottom (I assume that is the order intended?).

	Yes. Good point.  I originally had numbers next to
each item to be explicit about the ordering, but I thought
they would confuse people because the numbers for the order
didn't match the CC/CV types. In any event, its worth putting
in some text stating explicitly that the order is top-down.

	--Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 19 Oct 2006 12:18:52 -0400

One note to those reviewing the document.
I did run the document through idnits before I posted,
but it was just pointed out to me that I was running
a version of idnits that is about 10 revisions old.
When I ran it through the latest idnits script
and there are issues. I will fix them along with the
other comments posted during the LC.

	--Tom

>   (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.
>
> 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.
>
> logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3- 
> vccv-11.txt".
>
> http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow- 
> sites.txt
>
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
>

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Fri, 27 Oct 2006 23:52:27 -0500

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

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.

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?

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

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

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;

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.

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

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]
> 
> Last call will finish on 28th Oct 2006, ie the Friday 
> following draft cutoff.
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 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. 
> 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 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 
> 
>