Subject: FW: last call comments on VCCV-04.. or is it TDM oIP

From: "David Allan" <[email-masked]>
Date: Tue, 8 Mar 2005 10:53:07 -0500

Hi, 

Not quite sure what is in last call, but I'll comment on VCCV-04

---------------------------------------
I still find the text in section 3 confusing....IMO it has not kept up with
the more substantive changes in the document...

   "In the diagnostic mode, the operator triggers LSP-Ping, L2TPV3,
   or ICMP Ping [ICMP] modes depending on the underlying PSN."

And with MPLSoL2TP....? BTW, this is all negotiated (described in section 6)
so IMO it has little to do with the underlying PSN...

   "Since a pseudo wire is bi-directional, it makes sense to require that
the
   reply is send over the PSN tunnel that makes up the other half
   of the PW under test."

PSN tunnel is a server layer, we assume the PSN provides symmetrical
connectivity irregardless of the presence of PWs. SO we are not really
depending on PWs being bi-directional at all....this is simply confusing...

   "For example, if the PSN is an MPLS LSP,
   the reply should be sent on the LSP representing the reverse
   path. 

VCCV-PING specifies the return mode, so a more precise statement is if the
PSN is an MPLS LSP and the return mode is "Reply via an IPv4/IPv6 UDP
packet" then the reply should be sent on the LSP for the FEC of the
originating PE...which also means that VCCV-PING and VCCV-BFD use PSN
addressing, obvious, but not ever mentioned anywhere (except for using ICMP
PING for L2TP in section 7)

   If this fails, the operator can use other reply modes to
   determine what is wrong. 

Within limits, all the reply modes will be about manipulating how the return
packet traverse the PSN...the actual problem determination would be somewhat
more complex...as we are still is it a forward or reverse path problem. 

   The specific type of reply mode is
   indicated during PW circuit set-up (see section 6)."

It is? Section 6 discusses how one negotiates the OAM discriminator in the
forward path. The reverse path as stated above is the PSN (which IMO is
non-negotiable ;-), and the reply mode is embedded in the ping
transaction...

However we are imbedding an explicit layer violation here in that the ping
is injected into the PW using the PW-PID (or whatever we call it these days)
and returns via the PSN. IMO this MAY actually be a useful behavior as I can
then traceroute MH-PWs that are disjointly routed (Assuming that MH-PWs are
never top label)

   The fault detection mode provides a way to emulate fault 
   detection mechanisms in other technologies, such as ATM for 
   example. 

"Emulate"... ? Wouldn't something like, "provides a lightweight method for
rapidly detecting PW faults and interworking with PW clients" make more
sense. 

---------------------------
Section 4.1 is not aligned with draft-ietf-pwe3-cw-02.txt and IMO should
simply reference it....

---------------------------
Section 4.3, if TTL manipulation is inconsistently implemented, doesn't it
become a pretty meaningless test and including it as an option makes no
sense.....
---------------------------
Section 5.1: The FEC TLV carries the sub-tlv type....
---------------------------
Section 5.2: Shouldn't the description of what BFD does and the code points
simply be a reference...for example the list of diagnostic codes is already
out of date...
---------------------------

>From January 2004....

> A few comments in addition to those I've already posted on the list.
> 
<snipped>

>
>Section 3: VCCV as a means of negotiating OAM capabilities and hiding OAM
flows from ECMP seems to be getting blurred with >the protocols in use. e.g.
that use of BFD is explicitly mentioned as "fault detection mode". I have
nothing against using >BFD and LSP-PING, but describing protocol use as
"modes" seems to be an abuse of the english language. How about "The use >of
BFD with VCCV provides a way to emulate..."
>
>Section 6.1: Presume the OAM flag will be corrected to PW PID (actually has
ramifications throughout the document). I'd 
>also like to see 1711 as an option to the CV types field  (on the
assumption the ITU will seek a PPP DLL).

As we have a different registry in draft-ietf-pwe3-cw-02.txt, I'd presume
such an assignment (for 1711) could be directly made now...
>
>As a more general editorial comment, I am not entirely comfortable with the
language describing VCCV and what it does. It >is continually described as a
"thing" when it simply uses the PW PID mechanism for multiplexing other
protocols over a PW >and provides procedures for negotiating their use. So
my preference would be to see statements like "VCCV provides several >means
of creating a control channel between PES that attaches the VC under test"
replaced with somthing I'd find more 
>precise such as "VCCV uses LDP for MPLS PWs to negotiate how OAM PDUs are
multiplexed with the PW". If I am not alone in 
>this sentiment, I'll be glad to propose other text....

cheers
Dave

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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 8 Mar 2005 10:57:06 -0600

VCCV is past WG last call. I am working on a
version that contains all last call comments
that will be out after the ietf meeting.

	--Tom

> my preference would be to see statements like "VCCV provides several 
> >means

---

From: "David Allan" <[email-masked]>
Date: Tue, 8 Mar 2005 12:09:16 -0500

So what was the march 3rd message...?

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]] 
> Sent: Tuesday, March 08, 2005 11:57 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: [email-masked]
> Subject: Re: [PWE3] FW: last call comments on VCCV-04.. or is 
> it TDM oIP
> 
> 
> 
> > I still find the text in section 3 confusing....IMO it has 
> not kept up
> > with
> > VCCV-PING specifies the return mode, so a more precise 
> statement is if
> > the
> > addressing, obvious, but not ever mentioned anywhere 
> (except for using 
> > ICMP
> > Within limits, all the reply modes will be about 
> manipulating how the
> > return
> > It is? Section 6 discusses how one negotiates the OAM 
> discriminator in
> > the
> > However we are imbedding an explicit layer violation here 
> in that the
> > ping
> > is injected into the PW using the PW-PID (or whatever we 
> call it these 
> > days)
> > and returns via the PSN. IMO this MAY actually be a useful 
> behavior as 
> > I can
> > "Emulate"... ? Wouldn't something like, "provides a 
> lightweight method
> > for
> > Section 5.2: Shouldn't the description of what BFD does and 
> the code 
> > points
> >> Section 3: VCCV as a means of negotiating OAM capabilities 
> and hiding
> >> OAM
> > that use of BFD is explicitly mentioned as "fault detection 
> mode". I 
> > have
> > "modes" seems to be an abuse of the english language. How 
> about "The 
> > use >of
> >> precise such as "VCCV uses LDP for MPLS PWs to negotiate 
> how OAM PDUs
> >> are

---

From: "David Allan" <[email-masked]>
Date: Tue, 8 Mar 2005 12:18:06 -0500

To elaborate

VCCV-04 was only posted Feb 3rd, and only mention of last call I can find on
the list is March 3rd....

That one blew right by...;-)

Meanwhile, the good news is you have a few more comments to consider as
you're revving the doc anyway...:-)

rgds
Dave