RE: (resend) Working group last call: PWE3 PPP assignmen t
"David Allan" <[email protected]>
| Newsgroups | gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
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 protected]] > Sent: Sunday, April 18, 2004 4:11 PM > To: [email protected] > Cc: Allan, David [CAR:NS00:EXCH]; [email protected]; > [email protected]; [email protected] > Subject: Re: [Pppext] (resend) Working group last call: PWE3 > PPP assignment > > > > From: James Carlson > > To: [email protected] > > cc: <[email protected]>, <[email protected]>, > > <[email protected]>, <[email protected]> > > > > 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 protected] > _______________________________________________ Pppext mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pppext