Subject: Question on VCCV

From: "David Allan" <[email-masked]>
Date: Tue, 16 Dec 2003 13:14:17 -0500

Looking at the current draft, a few questions come to mind.

1) VCCV appears to only allow exclusive selection of one OAM protocol to be
used on the OAM channel. If more than one optional VCCV parameter can be
carried, this is not clear. This does not seem consistent with the text in
section 6 in which the egress advertises capability DU and lets the ingress
choose. Therefore the CC type and CV type fields should be bitmaps not
enums, and the values range 1,2,4,8 etc. So one could specify being able to
accept some number of protocols via some number of mechanisms, and the
ingress picks one. 

2) The draft references the PW PID but does not provide a means of
designating it as an OAM channel. (needs an additional code point in the CC
field). IMHO the next should also simply state "type of control channel" vs.
"type of IP control channel" as PW PID uses a PPP DLL and self identifies
the content.

3) Does the appearance of a private draft in a WG document mean PWE3 has
formally adopted BFD? If so, should the katz draft be renamed?

4) Why are the references to FRF8, Y.17fw, I.555, I.620, Q.933, GTTP, PWREQ,
PWE3FW, and L2SIG included as they have no relevance to the document. IMHO
the Martinisig reference should be updated and actually referenced in the
document if the procedures for VCCV piggyback on it.

cheers
Dave

Quick aside, current posted draft has a few formatting problems ....;-)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 16 Dec 2003 15:33:31 -0500

>1) VCCV appears to only allow exclusive selection of one OAM 
>protocol to be used on the OAM channel. If more than one optional VCCV 
>parameter can be
>carried, this is not clear. This does not seem consistent with 
>the text in section 6 in which the egress advertises capability DU and 
>lets the ingress
>enums, and the values range 1,2,4,8 etc. 
>
>So one could specify being able to

	Yes, you are correct, the CC and CV types are a bitmask. I
thought I had made that clear before, but it looks like I left
it out. :(

>designating it as an OAM channel. (needs an additional code 
>point in the CC field). IMHO the next should also simply state "type of

>control channel" vs.
>"type of IP control channel" as PW PID uses a PPP DLL and self 
>identifies the content.

	We will make this clearer.

>3) Does the appearance of a private draft in a WG document 
>mean PWE3 has formally adopted BFD? 

> If so, should the katz draft be renamed?

	As far as I know, there is no formal rule
stating that WG drafts cannot reference non-WG
drafts, but I will leave it up to the chairs to
clarify.

>PWE3FW, and L2SIG included as they have no relevance to the 
>document. 

	I disagree. The PWE3FW is relevant, as it defines the 
architecture onto which this mechanism fits into. 
Y.17fw is a relevant informative reference, as is PWEREQ. 
We need to reorg the references into Informative and 
Normative sections; however.

	I do agree that FRF8, I.555, I.620, and
Q.933 should be removed as they are not referenced. These are
relics from the initial version of the draft that included
the OAM Msg mapping stuff that we pulled out into a
separate draft.

>IMHO
>the Martinisig reference should be updated and actually 
>referenced in the document if the procedures for VCCV piggyback on it.

	Agreed..

	--Tom

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

---

From: "David Allan" <[email-masked]>
Date: Wed, 17 Dec 2003 10:13:03 -0500

Hi Tom:

> 	Yes, you are correct, the CC and CV types are a 
> bitmask. I thought I had made that clear before, but it looks 
> like I left it out. :(

Current value for BFD is a 3 (does that mean BFD is a hybrid of LSP-PING and
ICMP? ;-) or are these bit offsets....(if so why start at 1?)

> >designating it as an OAM channel. (needs an additional code point in 
> >the CC field). IMHO the next should also simply state "type of
> 
> >control channel" vs.
OK

> drafts, but I will leave it up to the chairs to

As you've introduced a reference to non-WG technology that is not in any
other WG, t'would seem to me that it's now a PW thing. Process wise I
beleive this would have to be resolved before publication as an RFC.

> architecture onto which this mechanism fits into. 

OK, but it's not explicitly referenced so should be informative....

> Y.17fw is a relevant informative reference, as is PWEREQ. 

OK, then they also should be moved from the normative references to the
informative section.

> Normative sections; however.

Well the section titles are there ;-)

> the OAM Msg mapping stuff that we pulled out into a separate draft.

OK

> >referenced in the document if the procedures for VCCV 

Great

Dave

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 17 Dec 2003 10:28:01 -0500

>-----Original Message-----
>From: David Allan [mailto:[email-masked]] 
>Sent: Wednesday, December 17, 2003 10:13 AM
>To: [email-masked]'; [email-masked]
>Subject: RE: [PWE3] Question on VCCV
>
>
>Hi Tom:
>
>Current value for BFD is a 3 (does that mean BFD is a hybrid 
>of LSP-PING and ICMP? ;-) or are these bit offsets....(if so why start
at 1?)

	They are bit positions.

>point in 

	Yes, of course all normative references need
resolution prior to being assigned an RFC number.

>OK, then they also should be moved from the normative references to the
	
	Yup.

>Well the section titles are there ;-)

	*)

	--Tom