logo       
Google Custom Search
    AddThis Social Bookmark Button

RE: (resend) Working group last call: PWE3 PPP assignmen t: msg#00006

Subject: RE: (resend) Working group last call: PWE3 PPP assignmen t
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:vjs@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Sunday, April 18, 2004 4:11 PM
> To: pppext@xxxxxxxx
> Cc: Allan, David [CAR:NS00:EXCH]; margaret@xxxxxxxxxxxxxx; 
> narten@xxxxxxxxxx; ohta.hiroshi@xxxxxxxxxxxxx
> Subject: Re: [Pppext] (resend) Working group last call: PWE3 
> PPP assignment
> 
> 
> > From: James Carlson
> > To: pppext@xxxxxxxx
> > cc: <dallan@xxxxxxxxxxxxxxxxxx>, <ohta.hiroshi@xxxxxxxxxxxxx>,
> >         <narten@xxxxxxxxxx>, <margaret@xxxxxxxxxxxxxx>
> 
> > > 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    vjs@xxxxxxxxxxxx
> 

_______________________________________________
Pppext mailing list
Pppext@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/pppext




Try Searching:
servers, voip, java, networking, microsoft ...
<Prev in Thread] Current Thread [Next in Thread>