Subject: RE: [Pppext] (resend) Working group last call: PWE3 PPP assignmen t

From: "David Allan" <[email-masked]>
Date: Mon, 19 Apr 2004 09:27:43 -0400

Sorry for the confusion, I upped the rev number of the draft without
checking that the appropriate text was still there (there are other drafts
that use this). Section 5.4.3 of version 6 of the draft contains the
appropriate text. I'll check where it has gone.

Dave

FYI Lloyd Wood has an archived version...
http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draf
t-ietf-pwe3-arch-06.txt

> -----Original Message-----
> From: Vernon Schryver [mailto:[email-masked]] 
> Sent: Sunday, April 18, 2004 4:11 PM
> To: [email-masked]
> Cc: Allan, David [CAR:NS00:EXCH]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Pppext] (resend) Working group last call: PWE3 
> PPP assignment
> 
> 
> > From: James Carlson
> > To: [email-masked]
> > cc: <[email-masked]>, <[email-masked]>,
> >         <[email-masked]>, <[email-masked]>
> 
> > > I am a document editor attending ITU-T SG13/Q3 and 
> working on MPLS 
> > > OAM. We've been advised by IANA that we need to contact 
> the PPP WG 
> > > directly in order to get a code
> > > point from the PPP DLL space.
> > > 
> > > The PWE3 Architecture document defines a mechanism for the 
> > > multiplexing of protocols with a psuedo-wire (the PWE3 PID) that 
> > > uses the PPP DLL identifier space. (see 
> > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-07.txt).
> > > 
> > > Protocols multiplexed with a pseudo wire using the PWE3 PID will 
> > > properly
> > > fate share  (have common forwarding) with the associated 
> pseudo wire under 
> > > all known circumstances encounted with currently deployed 
> equipment. This is
> > > not
> > > true of other defined mechanisms to distinguish OAM flows for PWs.
> > >  
> > > In order to apply OAM protocols defined in ITU-T Recommendation 
> > > Y.1711 to pesudo wires, we require a PPP DLL code point.
> > >  
> > > Therefore we request a PPP DLL assignment for the Y.1711 protocol.
> 
> 
> Why does Y.1711 need a PPP DLL number?  There are only two 
> references to "PPP" in draft-ietf-pwe3-arch-07.txt.  Both are 
> in this text:
> 
> >    Attachment Circuit   The physical or virtual circuit attaching
> >    (AC)                 a CE to a PE. An attachment Circuit may be
> >                         for example a Frame Relay DLCI, an ATM   
> >                         VPI/VCI, an Ethernet port, a VLAN, a PPP
> >                         connection on a physical interface, a 
> >                         PPP session from an L2TP tunnel, an MPLS
> 
> Unless the packets/PDUs/frames/cells/whatever of Y.1711 will 
> be encapsulated as naked globs of data in PPP frames, why 
> does Y.1711 need a PPP DLL number?
> 
> Where is that "multiplexing of protocols with a psuedo-wire" 
> defined where it involves PPP?
> 
> 
> What is that bit about "currently deployed equipment"?  In 
> what circumstances oare pseudo-wires currently deployed? 
> Whether they are deployed, what PPP DLL number do they use?
> 
> 
> Elsewhere in the document I get the impression that PPP 
> frames might be carried inside psuedo-wire 
> circuits/wires/whatever.  The document explicitly states that 
> psuedo-wires are free to reorder packets/PDUs/whatever.  
> Those two notions clash catastrophically. PPP frames must 
> never be delivered out of order.
> 
> 
> Vernon Schryver    [email-masked]
> 

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

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 19 Apr 2004 18:02:19 -0600 (MDT)

> From: "David Allan" <[email-masked]>
> To: "'Vernon Schryver'" <[email-masked]>, [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]

> http://www.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draf

That version only raises more questions for me.

What is the purpose of the PPP DLL number in that header?
What is demultiplexing using that PPP DLL number?  What are the other
values that might someday be in that field?

Except in the likely case that I'm completely confused about which
protocols are being tunneled in which other protocols, a PPP DLL
number seems like the wrong thing.