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

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 8 Mar 2005 11:17:20 -0600

The draft was refreshed so it wouldn't
be expired, which might be what is confusing
things.

	--Tom
	
> 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
> >
> >
> >
> >       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
> >
> > > 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
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> >
> >

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 08 Mar 2005 19:10:45 +0000

> be expired, which might be what is confusing

Yes! I was doing draft status just before IETF, and
saw that 03 was marked in my records as expecting 04
and LC 04 when it arrives.

So - when I saw 04, I issues the LC without realizing
that it was not the 04 I was expecting.

Next time I will check with the authors first.

Sorry to waste the WG's time issuing the LC notice.

- Stewart

>> > >    "Since a pseudo wire is bi-directional, it makes sense to require
>> > > that
>> > > the
>> > > of creating a control channel between PES that attaches the VC under
>> > > test"