From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-frame-relay-02.txt Date: Tue, 03 Feb 2004 15:51:26 -0500 Lines: 86 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 03 21:52:05 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Frame Relay over Pseudo-Wires Author(s) : C. Kawa Filename : draft-ietf-pwe3-frame-relay-02.txt Pages : 28 Date : 2004-2-3 This document defines frame relay pseudo-wire emulation edge-to-edge. A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over IP and MPLS packet switched network (PSN). Two mapping modes are defined: One-to-one mapping mode characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs is defined for MPLS PSN. The other mode is known as port mode or many-to-one mapping mode and is defined for MPLS PSN and IP PSN with L2TPv3. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-frame-relay-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-frame-relay-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-frame-relay-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: RE: Comments on VCCV-01 Date: Tue, 03 Feb 2004 11:18:44 -0500 Lines: 33 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CDA5@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <4B6D09F3B826D411A67300D0B706EFDE0115CDA5@nt-exch-yow.pmc_n t.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" X-From: pwe3-admin@ietf.org Wed Feb 04 10:06:14 2004 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Shahram Davari , "'David Allan'" In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CDA5@nt-exch-yow.pmc_n t.nt.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDE0115CDA5@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Shahram and Dave, I'm catching up on the list and I saw your emails regarding Y.1711 as a VCCV option. Given Y.1711's use of a reserved label, I would like a better understanding of exactly how one would implement Y.1711 in a pseudowire - especially what the PDUs would look like and the general theory of operation. Is the Y.1711 label expected to work if it's not the top label in the stack? I don't think it's well specified enough to just add another codepoint to the VCCV document. Also, would you want Y.1711 in VCCV to be optional or required in implementations? Thanks, Andy ----------- At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > >> 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). > > > > If the working group desires such a mode to be > >added, then we can, but lets hear from the WG before we > >do this. > > > I am in favor of adding 1711 mode. > >-Shahram > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: Re: l2vpn signaling (LDP/CR-LDP/RSVP-TE) Date: Tue, 03 Feb 2004 11:27:54 -0500 Lines: 27 Sender: pwe3-admin@ietf.org References: <20040115103027.V31112@kummer.juniper.net> <401A8CBA.3030706@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Kireeti Kompella , Moshe.Aharon@ecitele.com, l2vpn@ietf.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 04 10:06:15 2004 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Chris Chase In-Reply-To: <401A8CBA.3030706@att.com> References: <20040115103027.V31112@kummer.juniper.net> <401A8CBA.3030706@att.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Chris, it's always pleasant to be quoted! At the time the Martini work started, "targeted RSVP" wasn't on anybody's radar screen. As Kireeti points out, in hindsight it probably would have worked just fine. In practice using LDP over TCP, I can't speak for anyone else, but we've found in our own implementation (both in testing and in the field) that scaling hasn't been a problem for tens of thousands of sessions/circuits, and we're continually raising the limits on our testing. Cheers, Andy ----------- At 1/30/2004 11:56 AM -0500, Chris Chase wrote: >How well are edge nodes going to scale for a full mesh of targeted LDP >sessions? I keep hearing from vendors about connection limits on their >TCP stacks. Whether it is BGP for CE-PE connections in 2547 services or >targeted LDP for PWE, it seems there are constant pressures on the number >of connections vendors can support. > >With RSVP for the vc label signaling I don't see the connection constrains >from a full mesh. A couple years ago Andy Malis told me that not looking >at RSVP was simply because implementations were already starting down the >LDP road. > >Chris Chase From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: Comments draft-ietf-pwe3-frame-relay-02.txt Date: Wed, 4 Feb 2004 11:05:25 +0200 Lines: 208 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "'PWE3 WG (E-mail)'" , "Andrew G. Malis (E-mail)" , "Rao Cherukuri (E-mail)" , "David Sinicrope (E-mail)" , Alik Shimelmits , Sharon Galtzur , Israel Sasson , Itsik Goldraich X-From: pwe3-admin@ietf.org Wed Feb 04 10:10:06 2004 Return-path: To: "'claude.kawa@sympatico.ca'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Claude and all, After having read the -02 draft I sorry to say that almost all my comments to the -01 version have remained unresolved. Please find below the (indented) text of the original comments with the added status of their resolution (marked [02-status]). In some cases I've added some fresh considerations and suggestions. Hopefully these comments will be useful. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Sasha Vainshtein > Sent: Sunday, July 06, 2003 12:48 PM > To: 'claude.kawa@polymtl.ca' > Cc: PWE3 WG (E-mail) > Subject: Comments draft-ietf-pwe3-frame-relay-01.txt > > > Claude and all, > Please see below several comments on the latest revision > of the FRoPW draft. Some of these are purely editorial nits, > while some other look to me like substantial omissions. > > 1. The Intro section defines the difference between one-to-one > and many-to-one modes like following: > > > Two mapping modes are defined between FR VCs and FR PWs: The first > one is called "one-to-one" mapping. because there is a one-to-one > correspondence between a FR VC and a pair of > unidirectional PWs. The > second mapping is called "many-to-one" mapping or "port > mode" because > multiple FR VCs assigned to a port are mapped to one pair of PWs. > > > I think that "unidirectional PWs" are not defined anywhere in the > PWE3 architecture. And somehow "unidirectional" is missing in the > definition of the "many-to-one" mode while the "pair" remains. > Pairs of PWs are also mentioned in the Reference Model section... > but Section 7.2 changes the language and discusses a pair of > (unidirectional) VC LSPs per a FR VC. And section 9 explicitly > refers to "a PW, i.e. a pair of VC LSPs"... > [02-status] - no change found. Of coures, this is mainly editorial stuff... > > 2. The PWE3 framework and PWE3 Protocol Layers drafts referenced > in the document has been merged into a common PWE3 architecure > document. > [02-status] - Done > > 3. Requirement to "detect detectable" transmission errors looks > somewhat vague. (I believe that nobody expects the FRoPW to detect > undetectable transmission errors:-) > [02-status] - almost no change (brackets have been placed around the word "detectable"). > > 4. The draft mentions padding at the end of the FRoPW packet "when > a pseudo-wire traverses a link that requires a minimum layer 2 > frame length". Since the PWE3 functionality resides exclusively > in the edge devices which are, at most, aware, of the > types of links they terminate, the text is misguiding. > a) Section 7.4.1.1 seems to define padding as part of the > ingress PE > functionality. It states that "If the link layer > protocol does not > have a minimum length requirement then Length_field is > set to zero > and no padding is required." Would this logic really be > implemented, > the egress PE would be unable to recover the actual > length of a short > FR frame if the PW crosses an Ethernet link somewhere > in the PSN core > while the ingress PE uses, say, POS for its connection > to the PSN. > b) The definition of padding characters in Section 7.3. > states that > "any 8-bit character with a decimal value from 0 to 255 > may be used as a padding character" as if 8-bit characters with > other decimal values exist... > IMO, padding is the function of the appropriate link > anywhere in the > network, and not of the PW IWF. The ingress PE must set > the length field > to sizeof (payload + FRoPW header) if this size is less > then 64 bytes, > otherwise the length field must be set to 0. The egress > PE then always > can recover the length of the payload. > And, of course, padding is irrelevant with and IP PSN. > [02-status] - No changes found. This is NOT an editorial comment, since the PWE3 Charter explicitly limits the PW functionality to the PEs! Please compare this text to the (IMHO, correct!) padding-related wording taken from draft-ietf-pwe3-atm-encap-04.txt: If the Pseudo Wire traverses a network link that requires a minimum frame size such as Ethernet as a practical example, with a minimum frame size of 64 octets, then such links will apply padding to the Pseudo Wire PDU to reach its minimum frame size. In this case the control word must include a length field set to the PDU length. A mechanism is required for the egress PE to detect and remove such padding. I suggest to copy and paste this text (assuming, of course, that the ATM draft authors do not object) as a replacement of all the padding-related considerations in the FR draft. Among other things, it would also make the draft shorter... > > 5. There are two "B" bits in the FRoPW control word (one carrying > the BECN bit of the encapsulated FR frame, and one belonging > to the fragmentation mechanism). > [02-status] - No changes found!!! > > 6. The draft says that D and F bits of the FRoPW header are "copied" > to DE and FECN bits of the recovered FR frame and then > explains that > a cleared bit can become set as the result of this "copying". > [02-status] - No changes found. This is mainly editorial stuff... > > 7. The following text seems superfluous: > > Re-ordering FRoPW packets is an implementation option but > requires that the sender numbers FRoPW packets. > > (Does anybody expect the egress PE to reorder unnumbered > packets?:-) > [02-status] - No changes found. In addition, I'd like to note that the draft seems controversial wrt numbering of FRoPW packets: on one hand, it states (in Section 4, item 3) that FR frames order must be preserved; on the other hand, it does not absolutely disallow using "unnumbered" packets (i.e. with the sequence number set to 0). The draft does not even preculde mixing numbered and unnumbered packets on the same FR PW. I suggest to state explicitly that such a mixture MUST NOT be used! And, BTW, Section 4 (Requirements) does not use the IETF all-capitals "MUST"s and "SHOULD"s even if Section 2 (Terminology) provides an appropriate reference to RFC 2119. Does this mean that these words are interpreted differently? E.g. "must" clauses do not specify absolute requirements? This would account for handling of the numbering issue in the draft... > > 8. Section 7.5 says that a FRoPW packet received with errors must be > silently discarded. It is not clear to which errors this section > refers: > a) Frames with L2 errors are (usually) discarded > regardless of being or > not being FRoPW packets (indeed, I am not sure one can identifiy > such frames as belonging to any specific PW) > b) No FRoPW specific errors are defined in the draft > c) In particular, it is not clear how to treat a packet > with L2 size > exceeding by far 64 bytes (after skipping the label stack) > and non-zero Length field. > [02-status] - No changes found. The draft actually says that in such a case the receiver must believe to what the Length field says (Section 7.4.2.2). This is acceptable and leaves just one possible FRoPW error to check: (Lenght-field != 0) && (Length_FRoPW_packet < Length-field). BTW, this case is not considered in the draft!!! > > 9. The draft does not specify whether the DE indications in > the FR frames > may be somehow reflected in the Diffserv markings of the > PSN headers. > (The WG Charter explicitly provides for such an activity.) > [02-status] - No changes found. I'd like to note that the draft mentions the need to map FR transfer and discard priorities to "appropriately engineered PWs and PSN tunnels" (Section 4, item 8). Since, AFAIK, PWs are not engineered and, in any case their parameters cannot be perceived by the PSN, the words "PWs and" seem superfluous. In other words, the QoS requirement is neither spelled out properly nor met! > > 10.With full respect to Steve Vogelsang, his name appears twice > in the list of the draft co-authors (but only once in the authors' > addresses list:-). > [02-status] - no changes found!!! > > Hopefully these comments will be useful. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 04:11:51 -0500 Lines: 199 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EAFE.EC6D5CAE" Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" X-From: pwe3-admin@ietf.org Wed Feb 04 10:15:07 2004 Return-path: To: "'Andrew G. Malis'" , Shahram Davari X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3EAFE.EC6D5CAE Content-Type: text/plain; charset="iso-8859-1" HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3EAFE.EC6D5CAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Comments on VCCV-01

HI Andy:

Y.1711 used with VCCV would use the PW PID as an = alternative to the reserved label (and a PPP DLL value to be assigned). = A draft requesting such a value will be posted shortly, and the = requisite changes to 1711 are parked on the living list awaiting the = IANA assignment. A further change would be required to PW setup = procedures to synchronize TTSI values.

IMO as VCCV procedures negotiate capability, 1711 = support would not be a MUST any more than the other options.

cheers
Dave

> -----Original Message-----
> From: Andrew G. Malis [mailto:andymalis@comcast.net] =
> Sent: Tuesday, February 03, 2004 11:19 = AM
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]
> Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul = Aggarwal';
> 'Monique Morrow (mmorrow)'; 'George Swallow = (swallow)'
> Subject: RE: [PWE3] Comments on VCCV-01
>
>
> Shahram and Dave,
>
> I'm catching up on the list and I saw your = emails regarding
> Y.1711 as a
> VCCV option.  Given Y.1711's use of a = reserved label, I would
> like a better
> understanding of exactly how one would = implement Y.1711 in a
> pseudowire -
> especially what the PDUs would look like and = the general theory of
> operation.  Is the Y.1711 label expected = to work if it's not
> the top label
> in the stack?  I don't think it's well = specified enough to
> just add another
> codepoint to the VCCV document.  Also, = would you want Y.1711
> in VCCV to be
> optional or required in implementations?
>
> Thanks,
> Andy
>
> -----------
>
> At 1/29/2004 07:12 AM -0800, Shahram Davari = wrote:
> > >> 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).
> > >
> > >       = If the working group desires such a mode to be
> > >added, then we can, but lets hear from = the WG before we
> > >do this.
> > >
> >  I am in favor of adding 1711 = mode.
> >
> >-Shahram
> >
> = >_______________________________________________
> >pwe3 mailing list
> >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3=
>
>
> = _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3=
>

------_=_NextPart_001_01C3EAFE.EC6D5CAE-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 11:24:39 +0200 Lines: 292 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-22fe4d07-ae78-47cc-bb77-ef2d233ff90d" Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" , "'Andrew G. Malis'" , Shahram Davari X-From: pwe3-admin@ietf.org Wed Feb 04 10:30:08 2004 Return-path: To: "'David Allan'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-22fe4d07-ae78-47cc-bb77-ef2d233ff90d Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB00.B6D6BE80" ------_=_NextPart_001_01C3EB00.B6D6BE80 Content-Type: text/plain; charset="iso-8859-1" David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [ mailto:andymalis@comcast.net ] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3EB00.B6D6BE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Comments on VCCV-01
David=20 and all,
Please=20 see a brief comment inline.
 
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, = February 04,=20 2004 11:12 AM
To: 'Andrew G. Malis'; Shahram = Davari
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow = (mmorrow)'; 'George Swallow (swallow)'
Subject: RE: [PWE3] = Comments=20 on VCCV-01

HI Andy:

Y.1711 used with VCCV would use the PW PID as an = alternative=20 to the reserved label (and a PPP DLL value to be = assigned).  

[Sasha] Please note that most PW = encapsulations=20 defined today do not use PW PID because hey have chosen to use the = ECMP-safe=20 control word. Can you please explain how this can be resolved without = changing=20 all the PW encapsulation formats?

A draft requesting such a value will be posted = shortly, and=20 the requisite changes to 1711 are parked on the living list awaiting = the IANA=20 assignment. A further change would be required to PW setup procedures = to=20 synchronize TTSI values.

IMO as VCCV procedures negotiate capability, 1711 = support=20 would not be a MUST any more than the other options.

cheers
Dave

> -----Original Message-----
>=20 From: Andrew G. Malis [mailto:andymalis@comcast.net] =
> Sent: Tuesday, February 03, 2004 11:19 = AM=20
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]=20
> Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; = 'Rahul=20 Aggarwal';
> 'Monique Morrow (mmorrow)'; = 'George=20 Swallow (swallow)'
> Subject: RE: [PWE3] = Comments=20 on VCCV-01
>
>=20
> Shahram and Dave,
>=20
> I'm catching up on the list and I saw = your emails=20 regarding
> Y.1711 as a
> VCCV option.  Given Y.1711's use of a reserved = label, I would=20
> like a better
>=20 understanding of exactly how one would implement Y.1711 in a =
> pseudowire -
> especially = what the PDUs=20 would look like and the general theory of
>=20 operation.  Is the Y.1711 label expected to work if it's not=20
> the top label
> in the=20 stack?  I don't think it's well specified enough to =
> just add another
> = codepoint to the=20 VCCV document.  Also, would you want Y.1711
>=20 in VCCV to be
> optional or required in=20 implementations?
>
>=20 Thanks,
> Andy
>=20
> -----------
>=20
> At 1/29/2004 07:12 AM -0800, Shahram = Davari=20 wrote:
> > >> I'd also like to = see=20
> > >> 1711 as an option to the CV = types=20 field  (on the
> assumption the ITU =
> > >> will seek a PPP = DLL).=20
> > >
> > = >       If the working group desires = such a=20 mode to be
> > >added, then we = can, but lets=20 hear from the WG before we
> > >do = this.
> > >
>=20 >  I am in favor of adding 1711 mode.
>=20 >
> >-Shahram
>=20 >
>=20 >_______________________________________________
> >pwe3 mailing list
>=20 >pwe3@ietf.org
> >https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
>
> =
> _______________________________________________ =
> pwe3 mailing list
>=20 pwe3@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
>

------_=_NextPart_001_01C3EB00.B6D6BE80-- ------=_NextPartTM-000-22fe4d07-ae78-47cc-bb77-ef2d233ff90d-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 09:36:34 -0000 Lines: 235 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB02.6128F4B7" Cc: , , , , X-From: pwe3-admin@ietf.org Wed Feb 04 10:40:11 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Comments on VCCV-01 Thread-Index: AcPq/2+k5+9XPsWfT3Wu561Ny+O5CQAAr/MQ To: , , X-OriginalArrivalTime: 04 Feb 2004 09:36:35.0333 (UTC) FILETIME=[616A6350:01C3EB02] Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EB02.6128F4B7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My take too Dave, ie alternative to reserved label not 'in addition' to = it. =20 regards, Neil -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of David = Allan Sent: 04 February 2004 09:12 To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique = Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy:=20 Y.1711 used with VCCV would use the PW PID as an alternative to the = reserved label (and a PPP DLL value to be assigned). A draft requesting = such a value will be posted shortly, and the requisite changes to 1711 = are parked on the living list awaiting the IANA assignment. A further = change would be required to PW setup procedures to synchronize TTSI = values. IMO as VCCV procedures negotiate capability, 1711 support would not be a = MUST any more than the other options.=20 cheers=20 Dave=20 > -----Original Message-----=20 > From: Andrew G. Malis [ mailto:andymalis@comcast.net]=20 > Sent: Tuesday, February 03, 2004 11:19 AM=20 > To: Shahram Davari; Allan, David [CAR:NS00:EXCH]=20 > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal';=20 > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'=20 > Subject: RE: [PWE3] Comments on VCCV-01=20 >=20 >=20 > Shahram and Dave,=20 >=20 > I'm catching up on the list and I saw your emails regarding=20 > Y.1711 as a=20 > VCCV option. Given Y.1711's use of a reserved label, I would=20 > like a better=20 > understanding of exactly how one would implement Y.1711 in a=20 > pseudowire -=20 > especially what the PDUs would look like and the general theory of=20 > operation. Is the Y.1711 label expected to work if it's not=20 > the top label=20 > in the stack? I don't think it's well specified enough to=20 > just add another=20 > codepoint to the VCCV document. Also, would you want Y.1711=20 > in VCCV to be=20 > optional or required in implementations?=20 >=20 > Thanks,=20 > Andy=20 >=20 > -----------=20 >=20 > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote:=20 > > >> I'd also like to see=20 > > >> 1711 as an option to the CV types field (on the=20 > assumption the ITU=20 > > >> will seek a PPP DLL).=20 > > >=20 > > > If the working group desires such a mode to be=20 > > >added, then we can, but lets hear from the WG before we=20 > > >do this.=20 > > >=20 > > I am in favor of adding 1711 mode.=20 > >=20 > >-Shahram=20 > >=20 > >_______________________________________________=20 > >pwe3 mailing list=20 > >pwe3@ietf.org=20 > > https://www1.ietf.org/mailman/listinfo/pwe3=20 >=20 >=20 > _______________________________________________=20 > pwe3 mailing list=20 > pwe3@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/pwe3=20 >=20 ------_=_NextPart_001_01C3EB02.6128F4B7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Comments on VCCV-01
My take too Dave, ie alternative to reserved = label not=20 'in addition' to it.
 
regards, Neil
-----Original Message-----
From: = pwe3-admin@ietf.org=20 [mailto:pwe3-admin@ietf.org]On Behalf Of David = Allan
Sent: 04=20 February 2004 09:12
To: 'Andrew G. Malis'; Shahram=20 Davari
Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul = Aggarwal';=20 'Monique Morrow (mmorrow)'; 'George Swallow = (swallow)'
Subject: RE:=20 [PWE3] Comments on VCCV-01

HI Andy:

Y.1711 used with VCCV would use the PW PID as an = alternative=20 to the reserved label (and a PPP DLL value to be assigned). A draft = requesting=20 such a value will be posted shortly, and the requisite changes to 1711 = are=20 parked on the living list awaiting the IANA assignment. A further = change would=20 be required to PW setup procedures to synchronize TTSI = values.

IMO as VCCV procedures negotiate capability, 1711 = support=20 would not be a MUST any more than the other options.

cheers
Dave

> -----Original Message-----
>=20 From: Andrew G. Malis [mailto:andymalis@comcast.net]=20
> Sent: Tuesday, February 03, 2004 11:19 = AM=20
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]=20
> Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul = Aggarwal';
> 'Monique Morrow (mmorrow)'; = 'George=20 Swallow (swallow)'
> Subject: RE: [PWE3] = Comments=20 on VCCV-01
>
>=20
> Shahram and Dave,
>=20
> I'm catching up on the list and I saw = your emails=20 regarding
> Y.1711 as a
> VCCV option.  Given Y.1711's use of a reserved = label, I would=20
> like a better
>=20 understanding of exactly how one would implement Y.1711 in a =
> pseudowire -
> especially = what the PDUs=20 would look like and the general theory of
>=20 operation.  Is the Y.1711 label expected to work if it's not=20
> the top label
> in the=20 stack?  I don't think it's well specified enough to =
> just add another
> = codepoint to the=20 VCCV document.  Also, would you want Y.1711
>=20 in VCCV to be
> optional or required in=20 implementations?
>
>=20 Thanks,
> Andy
>=20
> -----------
>=20
> At 1/29/2004 07:12 AM -0800, Shahram = Davari=20 wrote:
> > >> I'd also like to = see=20
> > >> 1711 as an option to the CV = types=20 field  (on the
> assumption the ITU=20
> > >> will seek a PPP = DLL).=20
> > >
> >=20 >       If the working group desires = such a=20 mode to be
> > >added, then we can, = but lets=20 hear from the WG before we
> > >do=20 this.
> > >
>=20 >  I am in favor of adding 1711 mode.
>=20 >
> >-Shahram
>=20 >
>=20 >_______________________________________________
> >pwe3 mailing list
>=20 >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3 =
>
>
>=20 _______________________________________________
>=20 pwe3 mailing list
> pwe3@ietf.org =
> https://www1.ietf.org/mailman/listinfo/pwe3 =
>

------_=_NextPart_001_01C3EB02.6128F4B7-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 04:58:12 -0500 Lines: 110 Sender: pwe3-admin@ietf.org Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" , "'Andrew G. Malis'" , Shahram Davari X-From: pwe3-admin@ietf.org Wed Feb 04 11:01:10 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha: My understanding of the next revision of VCCV is that the PW PID (first nybble 0x01) is the exclusive mechanism for distinguishing OAM flows as there are no bits universally available in the CW (first nybble 0x00). Not clear what the issue is? Dave -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wednesday, February 04, 2004 4:25 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 12:13:42 +0200 Lines: 445 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-5ca0bebb-7e36-4c3c-a6ca-d31517285855" Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" , "'Andrew G. Malis'" , Shahram Davari X-From: pwe3-admin@ietf.org Wed Feb 04 11:19:12 2004 Return-path: To: "'David Allan'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-5ca0bebb-7e36-4c3c-a6ca-d31517285855 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB07.90E6A940" ------_=_NextPart_001_01C3EB07.90E6A940 Content-Type: text/plain; charset="iso-8859-1" Dave, The current PWE3 Architecture draft defines the PW PID as following: PWE3 Payload Type Identifier (PWE3-PID) - An identifier used to distinguish between an MPLS IP payload and a CW that is not ECMP safe. It further explains in Section 5.4.4 that: If technical considerations result in a PW control word that may alias an IP packet, the control word SHOULD be preceded by an PWE3 payload type dentifier (PWE3 PID). This does not, IMO, cover usage of the first nibble of the ECMP-safe CW. Nor is the PPP DLL relevant for ECMP-safe PWs. If your intention was to use the first nibble of an ECMP-safe CW in Y.1711-based PW OAM to distinguish OAM packets (first nibble = '0001') from the data packets (first nibble = '0000'), this is OK with me. But please don't refer to it as "PW PID"! With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:58 AM To: Sasha Vainshtein Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 Sasha: My understanding of the next revision of VCCV is that the PW PID (first nybble 0x01) is the exclusive mechanism for distinguishing OAM flows as there are no bits universally available in the CW (first nybble 0x00). Not clear what the issue is? Dave -----Original Message----- From: Sasha Vainshtein [ mailto:Sasha@AXERRA.com ] Sent: Wednesday, February 04, 2004 4:25 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [ mailto:dallan@nortelnetworks.com ] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [ mailto:andymalis@comcast.net ] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------_=_NextPart_001_01C3EB07.90E6A940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] Comments on VCCV-01
Dave,
The=20 current PWE3 Architecture draft defines the PW PID  as=20 following:
<quote>
PWE3 Payload=20 Type Identifier (PWE3-PID) -  An identifier used to = distinguish=20 between an MPLS IP payload and a CW that is not ECMP=20 safe.
<end quote>
It=20 further explains in Section 5.4.4 that:
<quote>
If technical considerations = result in a PW=20 control word that may alias an IP packet, the control word SHOULD be = preceded=20 by an PWE3 payload type dentifier (PWE3 = PID).
<end quote>
This=20 does not, IMO, cover usage of the first nibble of the ECMP-safe CW. Nor = is the=20 PPP DLL relevant for ECMP-safe PWs.
If=20 your intention was to use the first nibble of an ECMP-safe CW in=20 Y.1711-based PW OAM to distinguish OAM packets (first=20 nibble =3D '0001') from the data packets (first nibble = =3D '0000'),=20 this is OK with me. But please don't refer to it as "PW=20 PID"!
With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha = Vainshtein
email:     sasha@axerra.com
tel:       +972-3-7659993=20 (office)
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
 
-----Original Message-----
From: David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, = February 04,=20 2004 11:58 AM
To: Sasha Vainshtein
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow = (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram=20 Davari
Subject: RE: [PWE3] Comments on = VCCV-01

Sasha:

My understanding of the next revision of VCCV is = that the PW=20 PID (first nybble 0x01) is the exclusive mechanism for distinguishing = OAM=20 flows as there are no bits universally available in the CW (first = nybble=20 0x00). Not clear what the issue is?

Dave



-----Original Message-----
From: Sasha=20 Vainshtein [mailto:Sasha@AXERRA.com]=20
Sent: Wednesday, February 04, 2004 4:25 = AM=20
To: Allan, David [CAR:NS00:EXCH]
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow = (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram=20 Davari

Subject: RE: [PWE3] Comments on VCCV-01 =


David and all,
Please see = a brief=20 comment inline.

With best regards,
          &nb= sp;           &nb= sp;           =20 Sasha Vainshtein
email:    =20 sasha@axerra.com
tel:       +972-3-7659993 = (office)=20
          =20 +972-8-9254948 (res.)
           = +972-58-674833 (cell.)

-----Original Message-----
From: David=20 Allan [mailto:dallan@nortelnetworks.c= om]=20
Sent: Wednesday, February 04, 2004 11:12 AM =
To: 'Andrew G. Malis'; Shahram Davari
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow = (mmorrow)'; 'George Swallow (swallow)'
Subject: RE:=20 [PWE3] Comments on VCCV-01


HI Andy:
Y.1711 used with = VCCV would=20 use the PW PID as an alternative to the reserved label (and a PPP DLL = value to=20 be assigned). 

[Sasha] Please note that most PW encapsulations = defined today=20 do not use PW PID because hey have chosen to use the ECMP-safe = control word.=20 Can you please explain how this can be resolved without changing all = the PW=20 encapsulation formats?

A draft requesting such a value will be posted = shortly, and=20 the requisite changes to 1711 are parked on the living list awaiting = the IANA=20 assignment. A further change would be required to PW setup procedures = to=20 synchronize TTSI values.

IMO as VCCV procedures negotiate capability, 1711 = support=20 would not be a MUST any more than the other options.
cheers
Dave
>=20 -----Original Message-----
> From: = Andrew G. Malis=20 [mailto:andymalis@comcast.net] =
> Sent: Tuesday, February 03, 2004 11:19 = AM=20
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]=20
> Cc: 'tnadeau@cisco.com'; = pwe3@ietf.org; 'Rahul=20 Aggarwal';
> 'Monique Morrow (mmorrow)'; = 'George=20 Swallow (swallow)'
> Subject: RE: [PWE3] = Comments=20 on VCCV-01
>
>=20
> Shahram and Dave,
>=20
> I'm catching up on the list and I saw = your emails=20 regarding
> Y.1711 as a
> VCCV option.  Given Y.1711's use of a reserved = label, I would=20
> like a better
>=20 understanding of exactly how one would implement Y.1711 in a =
> pseudowire -
> especially = what the PDUs=20 would look like and the general theory of
>=20 operation.  Is the Y.1711 label expected to work if it's not=20
> the top label
> in the=20 stack?  I don't think it's well specified enough to =
> just add another
> = codepoint to the=20 VCCV document.  Also, would you want Y.1711
>=20 in VCCV to be
> optional or required in=20 implementations?
>
>=20 Thanks,
> Andy
>=20
> -----------
>=20
> At 1/29/2004 07:12 AM -0800, Shahram = Davari=20 wrote:
> > >> I'd also like to = see=20
> > >> 1711 as an option to the = CV types=20 field  (on the
> assumption the ITU =
> > >> will seek a PPP DLL).=20
> > >
> >=20 >       If the working group desires = such a=20 mode to be
> > >added, then we = can, but lets=20 hear from the WG before we
> > >do = this.=20
> > >
> > =20 I am in favor of adding 1711 mode.
> = >=20
> >-Shahram
> >=20
>=20 >_______________________________________________
> >pwe3 mailing list
>=20 >pwe3@ietf.org
> >https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
>
> =
> _______________________________________________ =
> pwe3 mailing list
> = pwe3@ietf.org=20
> https://www1.ietf.o= rg/mailman/listinfo/pwe3=20
>

------_=_NextPart_001_01C3EB07.90E6A940-- ------=_NextPartTM-000-5ca0bebb-7e36-4c3c-a6ca-d31517285855-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 05:26:30 -0500 Lines: 160 Sender: pwe3-admin@ietf.org Cc: "'tnadeau@cisco.com'" , pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" , "'Andrew G. Malis'" , Shahram Davari X-From: pwe3-admin@ietf.org Wed Feb 04 11:30:08 2004 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Sasha: Where I think there may be confusion is that the text in the arch document does not appear to cover the VCCV usage case, unless an OAM PDU falls under the category of non ECMP safe CW. IMHO that would be a stretch given the definition of CW offered. I think the arch draft may require clarfication on this point after the next revision of VCCV is posted. rgds Dave -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wednesday, February 04, 2004 5:14 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 Dave, The current PWE3 Architecture draft defines the PW PID as following: PWE3 Payload Type Identifier (PWE3-PID) - An identifier used to distinguish between an MPLS IP payload and a CW that is not ECMP safe. It further explains in Section 5.4.4 that: If technical considerations result in a PW control word that may alias an IP packet, the control word SHOULD be preceded by an PWE3 payload type dentifier (PWE3 PID). This does not, IMO, cover usage of the first nibble of the ECMP-safe CW. Nor is the PPP DLL relevant for ECMP-safe PWs. If your intention was to use the first nibble of an ECMP-safe CW in Y.1711-based PW OAM to distinguish OAM packets (first nibble = '0001') from the data packets (first nibble = '0000'), this is OK with me. But please don't refer to it as "PW PID"! With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:58 AM To: Sasha Vainshtein Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 Sasha: My understanding of the next revision of VCCV is that the PW PID (first nybble 0x01) is the exclusive mechanism for distinguishing OAM flows as there are no bits universally available in the CW (first nybble 0x00). Not clear what the issue is? Dave -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wednesday, February 04, 2004 4:25 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: claude.kawa@sympatico.ca Subject: Re: Comments draft-ietf-pwe3-frame-relay-02.txt Date: Wed, 4 Feb 2004 6:39:58 -0500 Lines: 226 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: "'PWE3 WG (E-mail)'" , "Andrew G. Malis (E-mail)" , "Rao Cherukuri (E-mail)" , "David Sinicrope (E-mail)" , Alik Shimelmits , Sharon Galtzur , Israel Sasson , Itsik Goldraich X-From: pwe3-admin@ietf.org Wed Feb 04 12:42:19 2004 Return-path: X-Mailer: Openwave WebEngine, version 2.8.6.6 (webedge20-101-174-112-20020617)" To: Sasha Vainshtein Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha, and others, OK will work now to try to correct the text beforeloosing Sasha comments. claude > > From: Sasha Vainshtein > Date: 2004/02/04 Wed AM 04:05:25 EST > To: "'claude.kawa@sympatico.ca'" > CC: "'PWE3 WG (E-mail)'" , "Andrew G. Malis (E-mail)" > , "Rao Cherukuri (E-mail)" , > "David Sinicrope (E-mail)" , > Alik Shimelmits , Sharon Galtzur , > Israel Sasson , Itsik Goldraich > Subject: Comments draft-ietf-pwe3-frame-relay-02.txt > > Claude and all, > After having read the -02 draft I sorry to say that almost all my > comments to the -01 version have remained unresolved. > > Please find below the (indented) text of the original comments > with the added status of their resolution (marked [02-status]). > In some cases I've added some fresh considerations and suggestions. > > Hopefully these comments will be useful. > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > > -----Original Message----- > > From: Sasha Vainshtein > > Sent: Sunday, July 06, 2003 12:48 PM > > To: 'claude.kawa@polymtl.ca' > > Cc: PWE3 WG (E-mail) > > Subject: Comments draft-ietf-pwe3-frame-relay-01.txt > > > > > > Claude and all, > > Please see below several comments on the latest revision > > of the FRoPW draft. Some of these are purely editorial nits, > > while some other look to me like substantial omissions. > > > > 1. The Intro section defines the difference between one-to-one > > and many-to-one modes like following: > > > > > > Two mapping modes are defined between FR VCs and FR PWs: The first > > one is called "one-to-one" mapping. because there is a one-to-one > > correspondence between a FR VC and a pair of > > unidirectional PWs. The > > second mapping is called "many-to-one" mapping or "port > > mode" because > > multiple FR VCs assigned to a port are mapped to one pair of PWs. > > > > > > I think that "unidirectional PWs" are not defined anywhere in the > > PWE3 architecture. And somehow "unidirectional" is missing in the > > definition of the "many-to-one" mode while the "pair" remains. > > Pairs of PWs are also mentioned in the Reference Model section... > > but Section 7.2 changes the language and discusses a pair of > > (unidirectional) VC LSPs per a FR VC. And section 9 explicitly > > refers to "a PW, i.e. a pair of VC LSPs"... > > > [02-status] - no change found. Of coures, this is mainly editorial stuff... > > > > 2. The PWE3 framework and PWE3 Protocol Layers drafts referenced > > in the document has been merged into a common PWE3 architecure > > document. > > > [02-status] - Done > > > > 3. Requirement to "detect detectable" transmission errors looks > > somewhat vague. (I believe that nobody expects the FRoPW to detect > > undetectable transmission errors:-) > > > [02-status] - almost no change (brackets have been placed around the word > "detectable"). > > > > 4. The draft mentions padding at the end of the FRoPW packet "when > > a pseudo-wire traverses a link that requires a minimum layer 2 > > frame length". Since the PWE3 functionality resides exclusively > > in the edge devices which are, at most, aware, of the > > types of links they terminate, the text is misguiding. > > a) Section 7.4.1.1 seems to define padding as part of the > > ingress PE > > functionality. It states that "If the link layer > > protocol does not > > have a minimum length requirement then Length_field is > > set to zero > > and no padding is required." Would this logic really be > > implemented, > > the egress PE would be unable to recover the actual > > length of a short > > FR frame if the PW crosses an Ethernet link somewhere > > in the PSN core > > while the ingress PE uses, say, POS for its connection > > to the PSN. > > b) The definition of padding characters in Section 7.3. > > states that > > "any 8-bit character with a decimal value from 0 to 255 > > may be used as a padding character" as if 8-bit characters with > > other decimal values exist... > > IMO, padding is the function of the appropriate link > > anywhere in the > > network, and not of the PW IWF. The ingress PE must set > > the length field > > to sizeof (payload + FRoPW header) if this size is less > > then 64 bytes, > > otherwise the length field must be set to 0. The egress > > PE then always > > can recover the length of the payload. > > And, of course, padding is irrelevant with and IP PSN. > > > [02-status] - No changes found. This is NOT an editorial comment, > since the PWE3 Charter explicitly limits the PW functionality > to the PEs! > Please compare this text to the (IMHO, correct!) padding-related > wording taken from draft-ietf-pwe3-atm-encap-04.txt: > > If the Pseudo Wire traverses a network link that requires a minimum > frame size such as Ethernet as a practical example, with a minimum > frame size of 64 octets, then such links will apply padding to the > Pseudo Wire PDU to reach its minimum frame size. In this case the > control word must include a length field set to the PDU length. A > mechanism is required for the egress PE to detect and remove such > padding. > > I suggest to copy and paste this text (assuming, of course, that the ATM > draft authors do not object) as a replacement of all the padding-related > considerations in the FR draft. Among other things, it would also make > the draft shorter... > > > > 5. There are two "B" bits in the FRoPW control word (one carrying > > the BECN bit of the encapsulated FR frame, and one belonging > > to the fragmentation mechanism). > > > [02-status] - No changes found!!! > > > > 6. The draft says that D and F bits of the FRoPW header are "copied" > > to DE and FECN bits of the recovered FR frame and then > > explains that > > a cleared bit can become set as the result of this "copying". > > > [02-status] - No changes found. This is mainly editorial stuff... > > > > 7. The following text seems superfluous: > > > > Re-ordering FRoPW packets is an implementation option but > > requires that the sender numbers FRoPW packets. > > > > (Does anybody expect the egress PE to reorder unnumbered > > packets?:-) > > > [02-status] - No changes found. In addition, I'd like to note that the draft > seems controversial wrt numbering of FRoPW packets: on one hand, it states > (in Section 4, item 3) that FR frames order must be preserved; on the other > hand, > it does not absolutely disallow using "unnumbered" packets (i.e. with the > sequence > number set to 0). The draft does not even preculde mixing numbered and > unnumbered > packets on the same FR PW. I suggest to state explicitly that such a mixture > MUST NOT be used! > > And, BTW, Section 4 (Requirements) does not use the IETF all-capitals > "MUST"s and "SHOULD"s even if Section 2 (Terminology) provides an > appropriate > reference to RFC 2119. Does this mean that these words are interpreted > differently? E.g. "must" clauses do not specify absolute requirements? > This would account for handling of the numbering issue in the draft... > > > > 8. Section 7.5 says that a FRoPW packet received with errors must be > > silently discarded. It is not clear to which errors this section > > refers: > > a) Frames with L2 errors are (usually) discarded > > regardless of being or > > not being FRoPW packets (indeed, I am not sure one can identifiy > > such frames as belonging to any specific PW) > > b) No FRoPW specific errors are defined in the draft > > c) In particular, it is not clear how to treat a packet > > with L2 size > > exceeding by far 64 bytes (after skipping the label stack) > > and non-zero Length field. > > > [02-status] - No changes found. The draft actually says that in such a case > the receiver must believe to what the Length field says (Section 7.4.2.2). > This is acceptable and leaves just one possible FRoPW error to check: > (Lenght-field != 0) && (Length_FRoPW_packet < Length-field). > BTW, this case is not considered in the draft!!! > > > > 9. The draft does not specify whether the DE indications in > > the FR frames > > may be somehow reflected in the Diffserv markings of the > > PSN headers. > > (The WG Charter explicitly provides for such an activity.) > > > [02-status] - No changes found. I'd like to note that the draft mentions > the need to map FR transfer and discard priorities to "appropriately > engineered PWs and PSN tunnels" (Section 4, item 8). Since, > AFAIK, PWs are not engineered and, in any case their parameters cannot > be perceived by the PSN, the words "PWs and" seem superfluous. In other > words, the QoS requirement is neither spelled out properly nor met! > > > > 10.With full respect to Steve Vogelsang, his name appears twice > > in the list of the draft co-authors (but only once in the authors' > > addresses list:-). > > > [02-status] - no changes found!!! > > > > Hopefully these comments will be useful. > > > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > tel: +972-3-7659993 (office) > > +972-8-9254948 (res.) > > +972-58-674833 (cell.) > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 09:03:34 -0500 Organization: Cisco Systems, inc. Lines: 372 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01C3EAFD.C9576800" Cc: , "'Rahul Aggarwal'" , "'Monique Morrow \(mmorrow\)'" , "'George Swallow \(swallow\)'" , "'Andrew G. Malis'" , "'Shahram Davari'" X-From: pwe3-admin@ietf.org Wed Feb 04 15:07:10 2004 Return-path: To: "'David Allan'" , "'Sasha Vainshtein'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: Importance: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_00A1_01C3EAFD.C9576800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I think Andy is asking how you envision y1711 being used as a "mode" in VCCV. For example, since there is no real packet format defined for y1711, how to you envision VCCV will encapsulate it, etc...? In essence, the existing payloads of VCCV are recycled from other (well specified) places. --Tom -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 4:58 AM To: 'Sasha Vainshtein' Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 Sasha: My understanding of the next revision of VCCV is that the PW PID (first nybble 0x01) is the exclusive mechanism for distinguishing OAM flows as there are no bits universally available in the CW (first nybble 0x00). Not clear what the issue is? Dave -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wednesday, February 04, 2004 4:25 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------=_NextPart_000_00A1_01C3EAFD.C9576800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
    I think Andy is asking how you envision y1711=20 being
used=20 as a "mode" in VCCV. For example, since there
is no=20 real packet format defined for y1711, how to
you=20 envision VCCV will encapsulate it, etc...? 
In=20 essence, the existing payloads of VCCV are
recycled from other (well specified) = places.
 
    --Tom
 
 
-----Original Message-----
From: = David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, = February 04,=20 2004 4:58 AM
To: 'Sasha Vainshtein'
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow=20 (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram=20 Davari
Subject: RE: [PWE3] Comments on = VCCV-01

Sasha:

My understanding of the next revision of VCCV is = that the PW=20 PID (first nybble 0x01) is the exclusive mechanism for distinguishing = OAM=20 flows as there are no bits universally available in the CW (first = nybble=20 0x00). Not clear what the issue is?

Dave



-----Original Message-----
From: Sasha=20 Vainshtein [mailto:Sasha@AXERRA.com]=20
Sent: Wednesday, February 04, 2004 4:25 = AM=20
To: Allan, David [CAR:NS00:EXCH]
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow=20 (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram=20 Davari

Subject: RE: [PWE3] Comments on VCCV-01 =


David and all,
Please see = a brief=20 comment inline.

With best regards,
          &nbs= p;            = ;           =20 Sasha Vainshtein
email:    =20 sasha@axerra.com
tel:       +972-3-7659993 = (office)=20
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)

-----Original Message-----
From: David=20 Allan [mailto:dallan@nortelnetworks.co= m]=20
Sent: Wednesday, February 04, 2004 11:12 AM =
To: 'Andrew G. Malis'; Shahram Davari
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow=20 (mmorrow)'; 'George Swallow (swallow)'
Subject: RE:=20 [PWE3] Comments on VCCV-01


HI Andy:
Y.1711 used with = VCCV would=20 use the PW PID as an alternative to the reserved label (and a PPP DLL = value to=20 be assigned). 

[Sasha] Please note that most PW encapsulations = defined today=20 do not use PW PID because hey have chosen to use the ECMP-safe control = word.=20 Can you please explain how this can be resolved without changing all = the PW=20 encapsulation formats?

A draft requesting such a value will be posted = shortly, and=20 the requisite changes to 1711 are parked on the living list awaiting = the IANA=20 assignment. A further change would be required to PW setup procedures = to=20 synchronize TTSI values.

IMO as VCCV procedures negotiate capability, 1711 = support=20 would not be a MUST any more than the other options.
cheers
Dave
>=20 -----Original Message-----
> From: Andrew = G. Malis=20 [mailto:andymalis@comcast.net]=20
> Sent: Tuesday, February 03, 2004 11:19 = AM=20
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]=20
> Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; = 'Rahul=20 Aggarwal';
> 'Monique Morrow (mmorrow)'; = 'George=20 Swallow (swallow)'
> Subject: RE: [PWE3] = Comments=20 on VCCV-01
>
>=20
> Shahram and Dave,
>=20
> I'm catching up on the list and I saw = your emails=20 regarding
> Y.1711 as a
> VCCV option.  Given Y.1711's use of a reserved = label, I would=20
> like a better
>=20 understanding of exactly how one would implement Y.1711 in a =
> pseudowire -
> especially = what the PDUs=20 would look like and the general theory of
>=20 operation.  Is the Y.1711 label expected to work if it's not=20
> the top label
> in the=20 stack?  I don't think it's well specified enough to =
> just add another
> = codepoint to the=20 VCCV document.  Also, would you want Y.1711
>=20 in VCCV to be
> optional or required in=20 implementations?
>
>=20 Thanks,
> Andy
>=20
> -----------
>=20
> At 1/29/2004 07:12 AM -0800, Shahram = Davari=20 wrote:
> > >> I'd also like to = see=20
> > >> 1711 as an option to the = CV types=20 field  (on the
> assumption the ITU=20
> > >> will seek a PPP DLL).=20
> > >
> >=20 >       If the working group desires = such a=20 mode to be
> > >added, then we can, = but lets=20 hear from the WG before we
> > >do = this.=20
> > >
> > =20 I am in favor of adding 1711 mode.
> > =
> >-Shahram
> >=20
>=20 >_______________________________________________
> >pwe3 mailing list
>=20 >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3 =
>
>
>=20 _______________________________________________
>=20 pwe3 mailing list
> pwe3@ietf.org =
> https://www1.ietf.org/mailman/listinfo/pwe3 =
>

------=_NextPart_000_00A1_01C3EAFD.C9576800-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 09:09:13 -0500 Lines: 149 Sender: pwe3-admin@ietf.org Cc: pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" , "'Andrew G. Malis'" , "'Shahram Davari'" X-From: pwe3-admin@ietf.org Wed Feb 04 15:12:03 2004 Return-path: To: "'tnadeau@cisco.com'" , "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Tom: I have to admit I am not quite grokking your comment. Cannot parse "no real packet format defined for..." I envision the stack being PSN label PW label PW PID (avec PPP DLL) 1711 PDU cheers Dave -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 04, 2004 9:04 AM To: Allan, David [CAR:NS00:EXCH]; 'Sasha Vainshtein' Cc: pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; 'Shahram Davari' Subject: RE: [PWE3] Comments on VCCV-01 I think Andy is asking how you envision y1711 being used as a "mode" in VCCV. For example, since there is no real packet format defined for y1711, how to you envision VCCV will encapsulate it, etc...? In essence, the existing payloads of VCCV are recycled from other (well specified) places. --Tom -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 4:58 AM To: 'Sasha Vainshtein' Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 Sasha: My understanding of the next revision of VCCV is that the PW PID (first nybble 0x01) is the exclusive mechanism for distinguishing OAM flows as there are no bits universally available in the CW (first nybble 0x00). Not clear what the issue is? Dave -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wednesday, February 04, 2004 4:25 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 10:19:51 -0500 Organization: Cisco Systems, inc. Lines: 455 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0018_01C3EB08.71666EB0" Cc: , "'Rahul Aggarwal'" , "'Monique Morrow \(mmorrow\)'" , "'George Swallow \(swallow\)'" , "'Andrew G. Malis'" , "'Shahram Davari'" X-From: pwe3-admin@ietf.org Wed Feb 04 16:23:20 2004 Return-path: To: "'David Allan'" , "'Sasha Vainshtein'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C3EB08.71666EB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit And where does that stack go? What is the 1711 PDU format you refer to? --Tom -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 9:09 AM To: 'tnadeau@cisco.com'; 'Sasha Vainshtein' Cc: pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; 'Shahram Davari' Subject: RE: [PWE3] Comments on VCCV-01 Hi Tom: I have to admit I am not quite grokking your comment. Cannot parse "no real packet format defined for..." I envision the stack being PSN label PW label PW PID (avec PPP DLL) 1711 PDU cheers Dave -----Original Message----- From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] Sent: Wednesday, February 04, 2004 9:04 AM To: Allan, David [CAR:NS00:EXCH]; 'Sasha Vainshtein' Cc: pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; 'Shahram Davari' Subject: RE: [PWE3] Comments on VCCV-01 I think Andy is asking how you envision y1711 being used as a "mode" in VCCV. For example, since there is no real packet format defined for y1711, how to you envision VCCV will encapsulate it, etc...? In essence, the existing payloads of VCCV are recycled from other (well specified) places. --Tom -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 4:58 AM To: 'Sasha Vainshtein' Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 Sasha: My understanding of the next revision of VCCV is that the PW PID (first nybble 0x01) is the exclusive mechanism for distinguishing OAM flows as there are no bits universally available in the CW (first nybble 0x00). Not clear what the issue is? Dave -----Original Message----- From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] Sent: Wednesday, February 04, 2004 4:25 AM To: Allan, David [CAR:NS00:EXCH] Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram Davari Subject: RE: [PWE3] Comments on VCCV-01 David and all, Please see a brief comment inline. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) -----Original Message----- From: David Allan [mailto:dallan@nortelnetworks.com] Sent: Wednesday, February 04, 2004 11:12 AM To: 'Andrew G. Malis'; Shahram Davari Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' Subject: RE: [PWE3] Comments on VCCV-01 HI Andy: Y.1711 used with VCCV would use the PW PID as an alternative to the reserved label (and a PPP DLL value to be assigned). [Sasha] Please note that most PW encapsulations defined today do not use PW PID because hey have chosen to use the ECMP-safe control word. Can you please explain how this can be resolved without changing all the PW encapsulation formats? A draft requesting such a value will be posted shortly, and the requisite changes to 1711 are parked on the living list awaiting the IANA assignment. A further change would be required to PW setup procedures to synchronize TTSI values. IMO as VCCV procedures negotiate capability, 1711 support would not be a MUST any more than the other options. cheers Dave > -----Original Message----- > From: Andrew G. Malis [mailto:andymalis@comcast.net] > Sent: Tuesday, February 03, 2004 11:19 AM > To: Shahram Davari; Allan, David [CAR:NS00:EXCH] > Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; > 'Monique Morrow (mmorrow)'; 'George Swallow (swallow)' > Subject: RE: [PWE3] Comments on VCCV-01 > > > Shahram and Dave, > > I'm catching up on the list and I saw your emails regarding > Y.1711 as a > VCCV option. Given Y.1711's use of a reserved label, I would > like a better > understanding of exactly how one would implement Y.1711 in a > pseudowire - > especially what the PDUs would look like and the general theory of > operation. Is the Y.1711 label expected to work if it's not > the top label > in the stack? I don't think it's well specified enough to > just add another > codepoint to the VCCV document. Also, would you want Y.1711 > in VCCV to be > optional or required in implementations? > > Thanks, > Andy > > ----------- > > At 1/29/2004 07:12 AM -0800, Shahram Davari wrote: > > >> 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). > > > > > > If the working group desires such a mode to be > > >added, then we can, but lets hear from the WG before we > > >do this. > > > > > I am in favor of adding 1711 mode. > > > >-Shahram > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > ------=_NextPart_000_0018_01C3EB08.71666EB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
    And where does that stack go?  What is=20 the
1711=20 PDU format you refer to?
 
    --Tom
 
-----Original Message-----
From: = David Allan=20 [mailto:dallan@nortelnetworks.com]
Sent: Wednesday, = February 04,=20 2004 9:09 AM
To: 'tnadeau@cisco.com'; 'Sasha=20 Vainshtein'
Cc: pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique = Morrow=20 (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; 'Shahram=20 Davari'
Subject: RE: [PWE3] Comments on = VCCV-01

Hi Tom:

I have to admit I am not quite grokking your = comment. Cannot=20 parse "no real packet format defined for..."

I envision the stack being

        PSN = label=20
        PW = label=20
        PW PID = (avec PPP=20 DLL)
        1711=20 PDU

cheers
Dave

-----Original Message-----
From:=20 Thomas D. Nadeau [mailto:tnadeau@cisco.com] =
Sent: Wednesday, February 04, 2004 9:04 AM
To:=20 Allan, David [CAR:NS00:EXCH]; 'Sasha Vainshtein'
Cc:=20 pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George = Swallow=20 (swallow)'; 'Andrew G. Malis'; 'Shahram Davari'

Subject: RE: [PWE3] Comments on VCCV-01 =


    I think Andy is asking how you = envision=20 y1711 being
used as a "mode" in VCCV. For = example,=20 since there
is no real packet format defined = for=20 y1711, how to
you envision VCCV will = encapsulate it,=20 etc...?
In essence, the existing payloads of = VCCV=20 are
recycled from other (well specified)=20 places.

    --Tom


-----Original Message-----
From: David=20 Allan [mailto:dallan@nortelnetworks.co= m]=20
Sent: Wednesday, February 04, 2004 4:58 = AM=20
To: 'Sasha Vainshtein'
Cc:=20 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; 'Monique Morrow=20 (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; Shahram=20 Davari

Subject: RE: [PWE3] Comments on VCCV-01 =


Sasha:
My understanding of = the next=20 revision of VCCV is that the PW PID (first nybble 0x01) is the = exclusive=20 mechanism for distinguishing OAM flows as there are no bits = universally=20 available in the CW (first nybble 0x00). Not clear what the issue=20 is?

Dave



-----Original Message-----
From: Sasha=20 Vainshtein [mailto:Sasha@AXERRA.com]=20
Sent: Wednesday, February 04, 2004 4:25 AM=20
To: Allan, David [CAR:NS00:EXCH] =
Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; = 'Monique=20 Morrow (mmorrow)'; 'George Swallow (swallow)'; 'Andrew G. Malis'; = Shahram=20 Davari

Subject: RE: [PWE3] Comments on VCCV-01 =


David and all,
Please see = a brief=20 comment inline.
With best regards, =
          &nbs= p;            = ;           =20 Sasha Vainshtein
email:    =20 sasha@axerra.com
tel:       +972-3-7659993 = (office)=20
          =20 +972-8-9254948 (res.)
          =20 +972-58-674833 (cell.)
-----Original = Message-----=20
From: David Allan [mailto:dallan@nortelnetworks.co= m]=20
Sent: Wednesday, February 04, 2004 11:12 AM=20
To: 'Andrew G. Malis'; Shahram Davari =
Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; 'Rahul Aggarwal'; = 'Monique=20 Morrow (mmorrow)'; 'George Swallow (swallow)'
Subject:=20 RE: [PWE3] Comments on VCCV-01


HI Andy:
Y.1711 used with = VCCV would=20 use the PW PID as an alternative to the reserved label (and a PPP DLL = value to=20 be assigned). 

[Sasha] Please note that most PW encapsulations = defined today=20 do not use PW PID because hey have chosen to use the ECMP-safe control = word.=20 Can you please explain how this can be resolved without changing all = the PW=20 encapsulation formats?

A draft requesting such a value will be posted = shortly, and=20 the requisite changes to 1711 are parked on the living list awaiting = the IANA=20 assignment. A further change would be required to PW setup procedures = to=20 synchronize TTSI values.

IMO as VCCV procedures negotiate capability, 1711 = support=20 would not be a MUST any more than the other options.
cheers
Dave
>=20 -----Original Message-----
> From: Andrew = G. Malis=20 [mailto:andymalis@comcast.net]=20
> Sent: Tuesday, February 03, 2004 11:19 = AM=20
> To: Shahram Davari; Allan, David = [CAR:NS00:EXCH]=20
> Cc: 'tnadeau@cisco.com'; pwe3@ietf.org; = 'Rahul=20 Aggarwal';
> 'Monique Morrow (mmorrow)'; = 'George=20 Swallow (swallow)'
> Subject: RE: [PWE3] = Comments=20 on VCCV-01
>
>=20
> Shahram and Dave,
>=20
> I'm catching up on the list and I saw = your emails=20 regarding
> Y.1711 as a
> VCCV option.  Given Y.1711's use of a reserved = label, I would=20
> like a better
>=20 understanding of exactly how one would implement Y.1711 in a =
> pseudowire -
> especially = what the PDUs=20 would look like and the general theory of
>=20 operation.  Is the Y.1711 label expected to work if it's not=20
> the top label
> in the=20 stack?  I don't think it's well specified enough to =
> just add another
> = codepoint to the=20 VCCV document.  Also, would you want Y.1711
>=20 in VCCV to be
> optional or required in=20 implementations?
>
>=20 Thanks,
> Andy
>=20
> -----------
>=20
> At 1/29/2004 07:12 AM -0800, Shahram = Davari=20 wrote:
> > >> I'd also like to = see=20
> > >> 1711 as an option to the = CV types=20 field  (on the
> assumption the ITU=20
> > >> will seek a PPP DLL).=20
> > >
> >=20 >       If the working group desires = such a=20 mode to be
> > >added, then we can, = but lets=20 hear from the WG before we
> > >do = this.=20
> > >
> > =20 I am in favor of adding 1711 mode.
> > =
> >-Shahram
> >=20
>=20 >_______________________________________________
> >pwe3 mailing list
>=20 >pwe3@ietf.org
> >https://www1.ietf.org/mailman/listinfo/pwe3 =
>
>
>=20 _______________________________________________
>=20 pwe3 mailing list
> pwe3@ietf.org =
> https://www1.ietf.org/mailman/listinfo/pwe3 =
>

------=_NextPart_000_0018_01C3EB08.71666EB0-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: Comments on VCCV-01 Date: Wed, 4 Feb 2004 10:31:20 -0500 Lines: 19 Sender: pwe3-admin@ietf.org Cc: pwe3@ietf.org, "'Rahul Aggarwal'" , "'Monique Morrow (mmorrow)'" , "'George Swallow (swallow)'" , "'Andrew G. Malis'" , "'Shahram Davari'" X-From: pwe3-admin@ietf.org Wed Feb 04 16:34:04 2004 Return-path: To: "'tnadeau@cisco.com'" , "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Tom: You asked some questions.... > And where does that stack go? If by go, you mean how is it forwarded...between PEs. Same path anything else using the VCCV control channel would take. > What is the 1711 PDU format you refer to? It is specified in ITU-T recommendation Y.1711 (2002) You may want to ask George, he suggested this was possible during his MPLS 2003 presentation last October (I think you were there). Simply re-affirmed my estimation. rgds Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-atm-mib-00.txt Date: Wed, 04 Feb 2004 15:43:44 -0500 Lines: 84 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 04 21:44:16 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PW ATM Pseudo Wire (PW) Emulation Network Management Information Base Using SMIv2 Author(s) : T. Nadeau Filename : draft-ietf-pwe3-pw-atm-mib-00.txt Pages : 20 Date : 2003-10-16 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling an adaptation of ATM VCs over a Packet Switch Network (PSN) as defined in the PWE3 Framework [FRMWK]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-atm-mib-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-atm-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-atm-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: raymond zhang Subject: RE: Accept draft-nadeau-pwe3-vccv-01.txt as a WG document? Date: Thu, 05 Feb 2004 13:17:58 -0800 Lines: 16 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Thu Feb 05 22:21:07 2004 Return-path: X-Sender: zhangr@delta.info.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: pwe3@ietf.org In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > >> 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). > > > > If the working group desires such a mode to be > >added, then we can, but lets hear from the WG before we > >do this. > > I don't yet see a need for a 1711 mode... Regards, Raymond From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: PW status TLV Problem. Date: Fri, 06 Feb 2004 19:30:14 -0700 Organization: Cisco Systems Lines: 226 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Sat Feb 07 03:33:08 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: pwe3@ietf.org Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O WG, I received several e-mail pointing out that section 5.3. "Signaling of Pseudo Wire Status" is flawed. In rfc3036 the notification message in section 3.5.1 page 47 does not states clearly that the status TLV is mandatory. But After speaking with some of the authors it appears that the status TLV is mandatory. In the definition of the Pw status procedures section 5.3.2 I replaced the status TLV with a PW status TLV. This violates RFC3036. In section 5.3.3. "Pseudowire Status Negotiation Procedures" there is a statement that requires the PW status TLV to appear immediately after the PW FEC. However, the Label mapping TLV must appear immediately after the PW FEC. I would like to suggest a simple fix to this problem along these lines: - define the PW status TLV as an optional parameter for the notification message. - obtain a new status code "PW status message" next available code would be 0x00000028 - define the PW status TLV and relevant FEC in the optional parameter field. Here is the relevant text: 5.3. Signaling of Pseudo Wire Status 5.3.1. Use of Label Mappings. The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE-facing interface state. The PW label should not be withdrawn unless the user administratively configures the CE-facing interface down (or the PW configuration is deleted entirely). A simple label withdraw method MAY also be supported as an alternative. In any case if the Label mapping is not available the PW MUST be considered in Martini, et al. [Page 16] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 the down state. 5.3.2. Signaling PW status. The PE devices use an LDP TLV to indicate status to their remote peers. This PW Status TLV contains more information than the alternative simple Label Withdraw message. The format of the PW Status TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ note: TLV type 0x096A as defined in [13] pending IANA allocation ] Where the status code is a 4 octet bit field is specified in the PW IANA Allocations document [13]. Each bit in the status code field can be set individually to indicate more then a single failure at once. Each fault can be cleared by sending an appropriate status message with the respective bit cleared. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply. The Status TLV is transported to the remote PW peer via the LDP notification message. The general format of the Notification Message is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Parameters | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x00000028 "PW status", to Martini, et al. [Page 17] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 indicate that PW status follows. Since this notification does not refer to any particular message the Message Id, and Message Type fields are set to 0. [ note: Status Code 0x00000028 as defined in [13] pending IANA allocation ] The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. When a PE's CE-facing interface encounters an error, use of the PW status message allows the PE to send a single status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. As mentioned above the Group ID field can be used to send a status notification for all PWs associated with a particular group ID. This procedure is OPTIONAL, and if it is implemented the LDP Notification message should be as follows: the PW information length field is set to 0, the PW ID field is not present, and the interface parameters field is not present. For the purpose of this document this is called the "wild card PW status notification procedure", and all PEs implementing this design are REQUIRED to accept such a notification message, but are not required to send it. 5.3.3. Pseudowire Status Negotiation Procedures When a PW is first set up the PEs MUST attempt to negotiate the usage of the PW status TLV. This is accomplished as follows: A PE that supports the PW Status TLV MUST include it the initial label mapping signaling immediately following the PW FEC and the interface parameters field. The PW Status TLV will be used for the lifetime of the Pseudowire for PEs that support this TLV. If the PW Status TLV is not present immediately following the initial PW FEC Message received by a PE, then the PW Status TLV will not be used and both PEs supporting the pseudowire will revert to the label withdraw procedure for signaling status changes. If PW status TLV is sent immediately following the label mapping TLV in the initial PW FEC Message, but the remote PE corresponding FEC advertisement does not include a PW status TLV, or the remote PE does not support the PW Status TLV then the PW will revert to the label withdraw method to signal PW status. Note that if the PW Status TLV is not supported it will automatically be ignored since the LDP ignore bit is set. Martini, et al. [Page 18] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 If the negotiation process results in the usage of the PW status TLV, then the actual PW status is determined by the PW status TLV that was sent within the initial PW label mapping. Subsequent updates of PW status are conveyed through the notification message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PWId FEC or Generalized ID FEC + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x0???) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------------------------------------------------------------------------------------------------------------------------------------------- I also added the following : 11. Appendix B - Notification Message PW Status Diagram 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Status (0x0300) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|1| Status Code=0x00000028 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type=0 | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | PWId FEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | PWId FEC or Generalized ID FEC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Please send me comments on this text ..... ( last time nobody caught the problem in the last call ! ) After discussing this with the WG chairs we would like to reissue a last call for this section only. In lieu of some very good discussion in the RIFT draft does anybody thing that it might not be a bad idea to create a completely new message type ? this would avoid any interference between code that deals with the LDP session itself , and PW FEC which is a payload of the LDP session. Comments ? Thanks. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: draft-ietf-pwe3-cesopsn-00.txt and draft-vainshtein-pwe3-tdm-conn trol-protocol-extension-00.txt Date: Mon, 9 Feb 2004 13:54:05 +0200 Lines: 28 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" X-From: pwe3-admin@ietf.org Mon Feb 09 12:59:05 2004 Return-path: To: "PWE3 WG (E-mail)" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi all, I have submitted two Internet-Drafts listed in the subject line some time before the cut-off date, and I hope that they will be posted on time. Meanwhile, they can be retrieved from the following location: ftp://ftp.axerra.com/sasha/draft-ietf-pwe3-cesopsn-00.txt - the latest revision of the CESoPSN draft, posted as a WG document ftp://ftp.axerra.com/sasha/draft-vainshtein-pwe3-tdm-control-protocol-extens ion-00.txt - describes extensions to the PWE3 control protocol and IANA allocation drafts required to setup TDM PWs In addition, my colleage, Sharon Galtzur has posted an Internet Draft describing extensions to L2TPv3 required to setup TDM PWs over an IP PSN. It has been already publicly posted and can be retrieved from the following location: http://www.ietf.org/internet-drafts/draft-galtzur-l2tpext-tdm-00.txt ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-vccv-02.txt Date: Mon, 09 Feb 2004 16:22:02 -0500 Lines: 85 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 09 22:23:09 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) Author(s) : T. Nadeau, R. Aggarwal Filename : draft-ietf-pwe3-vccv-02.txt Pages : 16 Date : 2004-2-9 This document describes Virtual Circuit Connection Verification (VCCV) procedures for use with psuedowire connections. VCCV supports connection verification applications for pseudowire VCs regardless of the underlying MPLS or IP tunnel technology. VCCV makes use of IP based protocols such as Ping and MPLS-Ping to perform operations and maintenance functions. A network operator may use the VCCV procedures to test the network's forwarding plane liveliness. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-vccv-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-vccv-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: PW Status negotiation procedure Date: Wed, 11 Feb 2004 11:05:26 -0700 Organization: Cisco Systems Lines: 9 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Busschbach, Peter B (Peter)" , "'Shah, Himanshu'" , "'Rex Emmanuel Fernando'" , Srihari Ramachandra Sangli , Renwei Li , Avneesh Sachdev , Rajesh Parikh , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 11 19:08:06 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: tob@laurelnetworks.com In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Guys, Have you seen the message from a few days ago on the list about PW status issue ? Any comments ? ( I only got one comment so far ... ) Thanks. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PW status TLV Problem. Date: Wed, 11 Feb 2004 14:27:20 -0500 Lines: 327 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Feb 11 20:29:06 2004 Return-path: To: "'Luca Martini'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Comments in line marked as HS> > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Friday, February 06, 2004 9:30 PM > To: pwe3@ietf.org > Subject: [PWE3] PW status TLV Problem. > > > WG, > > I received several e-mail pointing out that section 5.3. > "Signaling of > Pseudo Wire Status" is flawed. > In rfc3036 the notification message in section 3.5.1 page 47 does not > states clearly that the status TLV is mandatory. But After > speaking with > some of the authors it appears that the status TLV is mandatory. > In the definition of the Pw status procedures section 5.3.2 I > replaced > the status TLV with a PW status TLV. This violates RFC3036. > In section 5.3.3. "Pseudowire Status Negotiation Procedures" > there is a > statement that requires the PW status TLV to appear immediately after > the PW FEC. However, the Label mapping TLV must appear > immediately after > the PW FEC. > > > I would like to suggest a simple fix to this problem along > these lines: > > - define the PW status TLV as an optional parameter for the > notification > message. > - obtain a new status code "PW status message" next available > code would > be 0x00000028 > - define the PW status TLV and relevant FEC in the optional parameter > field. > > Here is the relevant text: > > 5.3. Signaling of Pseudo Wire Status > > 5.3.1. Use of Label Mappings. > > The PEs MUST send PW label mapping messages to their peers > as soon as > the PW is configured and administratively enabled, > regardless of the > CE-facing interface state. The PW label should not be withdrawn > unless the user administratively configures the CE-facing interface > down (or the PW configuration is deleted entirely). A simple label > withdraw method MAY also be supported as an alternative. > In any case > if the Label mapping is not available the PW MUST be considered in > > > > Martini, et al. > [Page 16] > ^L > Internet Draft draft-ietf-pwe3-control-protocol-05.txt > December 2003 > > > the down state. > > > 5.3.2. Signaling PW status. > > The PE devices use an LDP TLV to indicate status to their remote > peers. This PW Status TLV contains more information than the > alternative simple Label Withdraw message. > > The format of the PW Status TLV is: > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x096A) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [ note: TLV type 0x096A as defined in [13] pending IANA > allocation ] > > Where the status code is a 4 octet bit field is specified in the PW > IANA Allocations document [13]. > > Each bit in the status code field can be set individually > to indicate > more then a single failure at once. Each fault can be cleared by > sending an appropriate status message with the respective bit > cleared. The presence of the lowest bit (PW Not > Forwarding) acts only > as a generic failure indication when there is a link-down event for > which none of the other bits apply. > > The Status TLV is transported to the remote PW peer via the LDP > notification message. The general format of the > Notification Message > is: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status (TLV) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Optional Parameters | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The Status TLV status code is set to 0x00000028 "PW status", to > > > > Martini, et al. > [Page 17] > ^L > Internet Draft draft-ietf-pwe3-control-protocol-05.txt > December 2003 > > > indicate that PW status follows. Since this notification does not > refer to any particular message the Message Id, and Message Type > fields are set to 0. > > [ note: Status Code 0x00000028 as defined in [13] pending IANA > allocation ] > > The PW FEC TLV SHOULD not include the interface parameters as they > are ignored in the context of this message. When a PE's CE-facing > interface encounters an error, use of the PW status message allows > the PE to send a single status message, using a PW FEC TLV > with only > the group ID set, to denote this change in status for all > affected PW > connections. > > As mentioned above the Group ID field can be used to send a status > notification for all PWs associated with a particular > group ID. This > procedure is OPTIONAL, and if it is implemented the LDP > Notification > message should be as follows: the PW information length > field is set > to 0, the PW ID field is not present, and the interface parameters > field is not present. For the purpose of this document > this is called > the "wild card PW status notification procedure", and all PEs > implementing this design are REQUIRED to accept such a notification > message, but are not required to send it. > HS> There might be room for confusion here in terms of how one should handle HS> wild card PW status in conjunction with pre-existing individual PW status HS> and vice-versa. I would suppose PE should continue to practice individual HS> fault clearing when they are non-overlapping. If it is true, sender must HS> still keep a record of what faults has been cleared on individual PW basis HS> even when individual and group status messages are used inter-mixedly. > > 5.3.3. Pseudowire Status Negotiation Procedures > > When a PW is first set up the PEs MUST attempt to > negotiate the usage > of the PW status TLV. This is accomplished as follows: > > A PE that supports the PW Status TLV MUST include it the initial > label mapping signaling immediately following the PW FEC and the > interface parameters field. The PW Status TLV will be used for the > lifetime of the Pseudowire for PEs that support this TLV. HS> The above paragraph should be reworded to be more clearer that HS> PW STATUS TLV follows the Label TLV and not "immediately" following HS> the PW FEC. So the order is - PW-FEC TLV, Label TLV, PW Status TLV. HS> It does mention this in the following paragraphs, but that is after HS> it has been mentioned twice that it should "immediately follow PW-FEC". > > If the PW Status TLV is not present immediately following > the initial > PW FEC Message received by a PE, then the PW Status TLV will not be > used and both PEs supporting the pseudowire will revert to > the label > withdraw procedure for signaling status changes. > > If PW status TLV is sent immediately following the label > mapping TLV > in the initial PW FEC Message, but the remote PE corresponding FEC > advertisement does not include a PW status TLV, or the > remote PE does > not support the PW Status TLV then the PW will revert to the label > withdraw method to signal PW status. Note that if the PW Status TLV > is not supported it will automatically be ignored since the LDP > ignore bit is set. > > > > > Martini, et al. > [Page 18] > ^L > Internet Draft draft-ietf-pwe3-control-protocol-05.txt > December 2003 > > > If the negotiation process results in the usage of the PW > status TLV, > then the actual PW status is determined by the PW status > TLV that was > sent within the initial PW label mapping. Subsequent updates of PW > status are conveyed through the notification message > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + PWId FEC or Generalized ID FEC + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Interface parameters | > | " | > | " | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x0???) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > HS> Note that above figure is misleading too. You should include HS> Label TLV before PW Status TLV and the status type as (0x096A) HS> as shown earlier. > -------------------------------------------------------------- > -------------------------------------------------------------- > --------------- > > I also added the following : > > 11. Appendix B - Notification Message PW Status Diagram > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| Status (0x0300) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| Status Code=0x00000028 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type=0 | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | PWId FEC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > | PWId FEC or Generalized ID FEC | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > HS> I would prefer to keep 16-bit field after message type as reserved HS> and start the PW-STATUS TLV on 4-byte boundary so the STATUS code HS> is not split on 2 16-bit words and so is PW-ID FEC information. > Please send me comments on this text ..... ( last time nobody > caught the > problem in the last call ! ) > After discussing this with the WG chairs we would like to > reissue a last > call for this section only. > > In lieu of some very good discussion in the RIFT draft does anybody > thing that it might not be a bad idea to create a completely > new message > type ? this would avoid any interference between code that deals with > the LDP session itself , and PW FEC which is a payload of the > LDP session. > > Comments ? > > > Thanks. > Luca > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-cesopsn-00.txt Date: Wed, 11 Feb 2004 15:51:44 -0500 Lines: 81 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 11 21:52:26 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) Author(s) : S. Vainshtein Filename : draft-ietf-pwe3-cesopsn-00.txt Pages : 28 Date : 2004-2-11 This document describes a method for encapsulating structured (NxDS0) TDM signals as pseudo-wires over packet-switching networks (PSN). In this regard, it complements similar work for structure-agnostic emulation of TDM bit-streams [PWE3-SAToP]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-cesopsn-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-cesopsn-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fragmentation-05.txt Date: Wed, 11 Feb 2004 16:27:49 -0500 Lines: 80 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 11 22:28:11 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, M. Townsley Filename : draft-ietf-pwe3-fragmentation-05.txt Pages : 13 Date : 2004-2-10 This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fragmentation-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fragmentation-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Danny McPherson Subject: Fwd: 59th IETF Agenda Date: Wed, 11 Feb 2004 14:51:59 -0700 Lines: 177 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Wed Feb 11 22:55:13 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O FYI... -danny Begin forwarded message: > From: agenda@ietf.org > Date: February 11, 2004 2:32:43 PM MST > To: iesg@ietf.org, wgchairs@ietf.org > Cc: agenda@ietf.org > Subject: 59th IETF Agenda > > Draft Agenda of the Fifty-ninth IETF > February 29 - March 5, 2004 > As of 2/11/2004 > > SUNDAY, February 29, 2004 > 1000-1700 IEPG Meeting - > 1200-1900 Registration - > 1300-1400 Newcomer's Training (English) - > 1400-1500 Newcomer's Training (Korean) - > 1300-1500 Editor's Training - > 1300-1500 Intro WG Chairs Training - > 1500-1700 Security Tutorial - > 1700-1900 Welcome Reception - > > MONDAY, March 1, 2004 > 0800-2000 IETF Registration - > 0800-0900 Continental Breakfast - > 0900-1130 Morning Sessions > APP apparea Applications Open Area Meeting > INT nemo Network Mobility WG * > OPS mboned MBONE Deployment WG * > SEC mobike IKEv2 Mobility and Multihoming WG > TSV pwe3 Pseudo Wire Emulation Edge to Edge WG > TSV sipping Session Initiation Proposal Investigation WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > INT mip6 Mobility for IPv6 WG > OPS dnsop Domain Name System Operations WG * > RTG mpls Multiprotocol Label Switching WG > SEC pki4ipsec Profiling Use of PKI in IPSEC WG > TSV sip Session Initiation Protocol WG > > 1500-1530 Break (Refreshments provided) - > 1530-1730 Afternoon Sessions II > APP iea Internationalizing Email Address BOF > INT pana Protocol for Carrying Authentication for Network > Access WG > OPS v6ops IPv6 Operations WG * > RTG idr Inter-Domain Routing WG > TSV tsvwg Transport Area Working Group > > 1730-1930 Break > 1930-2200 Evening Sessions > APP simple SIP for Instant Messaging and Presence Leveraging > Extensions WG > INT mip4 Mobility for IPv4 WG > IRTF hiprr HIP Related Research BOF > OPS rmonmib Remote Network Monitoring WG > RTG rtgarea Routing Area Meeting * > TSV nsis Next Steps in Signaling WG * > > TUESDAY, March 2, 2004 > 0800-1800 IETF Registration - > 0800-0900 Continental Breakfast - > 0900-1130 Morning Sessions > APP crisp Cross Registry Information Service Protocol WG > INT dhc Dynamic Host Configuration WG * > OPS psamp Packet Sampling WG > RTG forces Forwarding and Control Element Separation WG > TSV avt Audio/Video Transport WG * > > 1130-1300 Break > 1300-1400 Afternoon Sessions I > APP webdav WWW Distributed Authoring and Versioning WG > INT dna Detecting Network Attchment WG > OPS dnsop Domain Name System Operations WG * > SEC openpgp An Open Specification for Pretty Good Privacy WG > TSV nsis Next Steps in Signaling WG * > > 1415-1515 Afternoon Sessions II > APP calsch Calendaring and Scheduling WG > GEN newtrk New IETF Standards Track BOF > INT l3vpn Layer 3 Virtual Private Networks WG > INT magma Multicast and Anycast Group Membership WG * > OPS aaa Authentication, Authorization and Accounting WG > TSV midcom Middlebox Communication WG > > 1515-1545 Break (Refreshments provided) - > 1545-1645 Afternoon Sessions III > APP ldapbis LDAP (v3) Revision WG > INT ipv6 IP Version 6 WG * > OPS opsarea Operations and Management Open Area > SEC smime S/MIME Mail Security WG > TSV iptel IP Telephony WG > TSV ippm IP Performance Metrics WG > > 1700-1800 Afternoon Sessions IV > APP iea Internationalizing Email Address BOF > INT ipv6 IP Version 6 WG * > SEC sasl Simple Authentication and Security Layer WG > TSV rmt Reliable Multicast Transport WG > TSV speechsc Speech Services Control WG * > > WEDNESDAY, March 3, 2004 > 0800-1700 IETF Registration - > 0800-0900 Continental Breakfast - > 0900-1130 Morning Sessions > APP lemonade Enhancements to Internet email to Support Diverse > Service Environments > WG * > GEN icar Improved Cross Area Review WG > OPS hubmib Ethernet Interfaces and Hub MIB WG > OPS multi6 Site Multihoming in IPv6 WG > TSV enum Telephone Number Mapping WG > TSV mmusic Multiparty Multimedia Session Control WG * > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > INT l2vpn Layer 2 Virtual Private Network WG > IRTF mobopts IP Mobility Optimizations > OPS netconf Network Configuration WG > SEC pkix Public-Key Infrastructure (X.509) WG > TSV rserpool Reliable Server Pooling WG > TSV sipping Session Initiation Proposal Investigation WG > > 1500-1530 Break (Refreshments provided) - > 1530-1730 Afternoon Sessions II > INT hip Host Identity Protocol BOF > OPS capwap Control and Provisioning of Wireless Access Points WG > OPS ipfix IP Flow Information Export WG > SEC syslog Security Issues in Network Event Logging WG > TSV avt Audio/Video Transport WG * > TSV rddp Remote Direct Data Placement WG > > 1730-1930 Break > 1930-2200 Plenary - > > 2230 Late Night Session > PGP Key Signing > > THURSDAY, March 4, 2004 > 0800-1700 IETF Registration - > 0800-0900 Continental Breakfast - > 0900-1130 Morning Sessions > APP marid MTA Authorization Records in DNS BOF * > OPS netconf Network Configuration WG > RTG ccamp Common Control and Measurement Plane WG > TSV xcon Centralized Conferencing WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > OPS grow Global Routing Operations WG * > INT eap Extensible Authentication Protocol WG > SEC inch Extended Incident Handling WG > SEC ltans Long-Term Archive and Notary Services WG > TSV dccp Datagram Congestion Control Protocol WG * > TSV nfsv4 Network File System Version 4 WG > > 1500-1530 Break (Refreshments provided) - > 1530-1730 Afternoon Sessions II > APP geopriv Geographic Location/Privacy WG > OPS v6ops IPv6 Operations WG * > SEC saag Open Security Area Directorate > TSV pmtud Path MTU Discovery WG > > 1730-1930 Break > 1930-2200 Plenary - > > > Friday, March 5, 2004 > 0800-0900 Continental Breakfast - > 0900-1130 Morning Sessions > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Wei Luo Subject: Re: PW status TLV Problem. Date: Wed, 11 Feb 2004 14:42:37 -0800 Lines: 135 Sender: pwe3-admin@ietf.org References: <40244DB6.7050401@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 11 23:45:05 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: Luca Martini Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca, Comments inline. Another thing you may want to consider is to have a signaling procedure for implementations that support both FEC 128 and 129 to be able to determine the FEC type dynamically instead of through manual configuration. Some earlier revisions of the draft actually have that section. Luca Martini wrote: > 5.3.3. Pseudowire Status Negotiation Procedures > > When a PW is first set up the PEs MUST attempt to negotiate the usage > of the PW status TLV. This is accomplished as follows: > > A PE that supports the PW Status TLV MUST include it the initial > label mapping signaling immediately following the PW FEC and the > interface parameters field. The PW Status TLV will be used for the > lifetime of the Pseudowire for PEs that support this TLV. > > If the PW Status TLV is not present immediately following the initial > PW FEC Message received by a PE, then the PW Status TLV will not be > used and both PEs supporting the pseudowire will revert to the label > withdraw procedure for signaling status changes. What is the rationale to mandate the PW Status TLV be *immediately* following the FEC TLV? In other words, why does the ordering of the TLVs make any difference? Implementations always parse the entire Label Mapping message, decode TLVs into internal binary representations, and then apply appropiate actions. The location of the PW Status TLV inside the Label Mapping message does not seem to have any impact on operation. Unless I miss something obvious, I'd suggest we change the text to "the presence of the PW status TLV in the Label Mapping message indicates that a PE supports PW Status signaling." ---Wei > > If PW status TLV is sent immediately following the label mapping TLV > in the initial PW FEC Message, but the remote PE corresponding FEC > advertisement does not include a PW status TLV, or the remote PE does > not support the PW Status TLV then the PW will revert to the label > withdraw method to signal PW status. Note that if the PW Status TLV > is not supported it will automatically be ignored since the LDP > ignore bit is set. > > > > > Martini, et al. [Page 18] > ^L > Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 > > > If the negotiation process results in the usage of the PW status TLV, > then the actual PW status is determined by the PW status TLV that was > sent within the initial PW label mapping. Subsequent updates of PW > status are conveyed through the notification message > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + PWId FEC or Generalized ID FEC + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Interface parameters | > | " | > | " | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |1|0| PW Status (0x0???) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ------------------------------------------------------------------------------------------------------------------------------------------- > > > I also added the following : > > 11. Appendix B - Notification Message PW Status Diagram > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0| Notification (0x0001) | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| Status (0x0300) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0|1| Status Code=0x00000028 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message ID=0 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Message Type=0 | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | PW Status TLV | PWId FEC | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > | PWId FEC or Generalized ID FEC | > | | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Please send me comments on this text ..... ( last time nobody caught the > problem in the last call ! ) > After discussing this with the WG chairs we would like to reissue a last > call for this section only. > > In lieu of some very good discussion in the RIFT draft does anybody > thing that it might not be a bad idea to create a completely new message > type ? this would avoid any interference between code that deals with > the LDP session itself , and PW FEC which is a payload of the LDP session. > > Comments ? > > > Thanks. > Luca > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: Re: PW status TLV Problem. Date: Wed, 11 Feb 2004 16:37:32 -0700 Organization: Cisco Systems Lines: 378 Sender: pwe3-admin@ietf.org References: <8162DD929D7AD24CAD3FC5317CE41FB06D46BE@w2kmaexg02.wavesmithnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 12 00:40:07 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: "Shah, Himanshu" In-Reply-To: <8162DD929D7AD24CAD3FC5317CE41FB06D46BE@w2kmaexg02.wavesmithnet.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Himanshu, In general I seem to have issues with the pictures and some text. I fixed all these problems , and will post the new version shortly. more comments in line. Thanks. Luca Shah, Himanshu wrote: >Comments in line marked as HS> > > > >>-----Original Message----- >>From: Luca Martini [mailto:lmartini@cisco.com] >>Sent: Friday, February 06, 2004 9:30 PM >>To: pwe3@ietf.org >>Subject: [PWE3] PW status TLV Problem. >> >> >>WG, >> >>I received several e-mail pointing out that section 5.3. >>"Signaling of >>Pseudo Wire Status" is flawed. >>In rfc3036 the notification message in section 3.5.1 page 47 does not >>states clearly that the status TLV is mandatory. But After >>speaking with >>some of the authors it appears that the status TLV is mandatory. >>In the definition of the Pw status procedures section 5.3.2 I >>replaced >>the status TLV with a PW status TLV. This violates RFC3036. >>In section 5.3.3. "Pseudowire Status Negotiation Procedures" >>there is a >>statement that requires the PW status TLV to appear immediately after >>the PW FEC. However, the Label mapping TLV must appear >>immediately after >>the PW FEC. >> >> >>I would like to suggest a simple fix to this problem along >>these lines: >> >>- define the PW status TLV as an optional parameter for the >>notification >>message. >>- obtain a new status code "PW status message" next available >>code would >>be 0x00000028 >>- define the PW status TLV and relevant FEC in the optional parameter >>field. >> >>Here is the relevant text: >> >>5.3. Signaling of Pseudo Wire Status >> >>5.3.1. Use of Label Mappings. >> >> The PEs MUST send PW label mapping messages to their peers >>as soon as >> the PW is configured and administratively enabled, >>regardless of the >> CE-facing interface state. The PW label should not be withdrawn >> unless the user administratively configures the CE-facing interface >> down (or the PW configuration is deleted entirely). A simple label >> withdraw method MAY also be supported as an alternative. >>In any case >> if the Label mapping is not available the PW MUST be considered in >> >> >> >>Martini, et al. >> [Page 16] >>^L >>Internet Draft draft-ietf-pwe3-control-protocol-05.txt >>December 2003 >> >> >> the down state. >> >> >>5.3.2. Signaling PW status. >> >> The PE devices use an LDP TLV to indicate status to their remote >> peers. This PW Status TLV contains more information than the >> alternative simple Label Withdraw message. >> >> The format of the PW Status TLV is: >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|0| PW Status (0x096A) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status Code | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> [ note: TLV type 0x096A as defined in [13] pending IANA >>allocation ] >> >> Where the status code is a 4 octet bit field is specified in the PW >> IANA Allocations document [13]. >> >> Each bit in the status code field can be set individually >>to indicate >> more then a single failure at once. Each fault can be cleared by >> sending an appropriate status message with the respective bit >> cleared. The presence of the lowest bit (PW Not >>Forwarding) acts only >> as a generic failure indication when there is a link-down event for >> which none of the other bits apply. >> >> The Status TLV is transported to the remote PW peer via the LDP >> notification message. The general format of the >>Notification Message >> is: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Notification (0x0001) | Message Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status (TLV) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Optional Parameters | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> The Status TLV status code is set to 0x00000028 "PW status", to >> >> >> >> >> I fixed this diagram as well. >>Martini, et al. >> [Page 17] >>^L >>Internet Draft draft-ietf-pwe3-control-protocol-05.txt >>December 2003 >> >> >> indicate that PW status follows. Since this notification does not >> refer to any particular message the Message Id, and Message Type >> fields are set to 0. >> >> [ note: Status Code 0x00000028 as defined in [13] pending IANA >> allocation ] >> >> The PW FEC TLV SHOULD not include the interface parameters as they >> are ignored in the context of this message. When a PE's CE-facing >> interface encounters an error, use of the PW status message allows >> the PE to send a single status message, using a PW FEC TLV >>with only >> the group ID set, to denote this change in status for all >>affected PW >> connections. >> >> As mentioned above the Group ID field can be used to send a status >> notification for all PWs associated with a particular >>group ID. This >> procedure is OPTIONAL, and if it is implemented the LDP >>Notification >> message should be as follows: the PW information length >>field is set >> to 0, the PW ID field is not present, and the interface parameters >> field is not present. For the purpose of this document >>this is called >> the "wild card PW status notification procedure", and all PEs >> implementing this design are REQUIRED to accept such a notification >> message, but are not required to send it. >> >> >> > >HS> There might be room for confusion here in terms of how one should handle >HS> wild card PW status in conjunction with pre-existing individual PW status >HS> and vice-versa. I would suppose PE should continue to practice individual >HS> fault clearing when they are non-overlapping. If it is true, sender must >HS> still keep a record of what faults has been cleared on individual PW basis >HS> even when individual and group status messages are used inter-mixedly. > > > > yes this is correct. This problem is similar to the wildcard withdraw/release procedure defined in rfc3036. I'm not inventing anything new here. presumably the group id is saved along with the rest of the PW information. Wildcard status messages will then be applied to all PWs matching the group id in the status message. > > > >>5.3.3. Pseudowire Status Negotiation Procedures >> >> When a PW is first set up the PEs MUST attempt to >>negotiate the usage >> of the PW status TLV. This is accomplished as follows: >> >> A PE that supports the PW Status TLV MUST include it the initial >> label mapping signaling immediately following the PW FEC and the >> interface parameters field. The PW Status TLV will be used for the >> lifetime of the Pseudowire for PEs that support this TLV. >> >> > > >HS> The above paragraph should be reworded to be more clearer that >HS> PW STATUS TLV follows the Label TLV and not "immediately" following >HS> the PW FEC. So the order is - PW-FEC TLV, Label TLV, PW Status TLV. >HS> It does mention this in the following paragraphs, but that is after >HS> it has been mentioned twice that it should "immediately follow PW-FEC". > > > yes , fixed. >> If the PW Status TLV is not present immediately following >>the initial >> PW FEC Message received by a PE, then the PW Status TLV will not be >> used and both PEs supporting the pseudowire will revert to >>the label >> withdraw procedure for signaling status changes. >> >> If PW status TLV is sent immediately following the label >>mapping TLV >> in the initial PW FEC Message, but the remote PE corresponding FEC >> advertisement does not include a PW status TLV, or the >>remote PE does >> not support the PW Status TLV then the PW will revert to the label >> withdraw method to signal PW status. Note that if the PW Status TLV >> is not supported it will automatically be ignored since the LDP >> ignore bit is set. >> >> >> >> >>Martini, et al. >> [Page 18] >>^L >>Internet Draft draft-ietf-pwe3-control-protocol-05.txt >>December 2003 >> >> >> If the negotiation process results in the usage of the PW >>status TLV, >> then the actual PW status is determined by the PW status >>TLV that was >> sent within the initial PW label mapping. Subsequent updates of PW >> status are conveyed through the notification message >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + PWId FEC or Generalized ID FEC + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Interface parameters | >> | " | >> | " | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|0| PW Status (0x0???) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status Code | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> > > >HS> Note that above figure is misleading too. You should include >HS> Label TLV before PW Status TLV and the status type as (0x096A) >HS> as shown earlier. > > > > > > >>-------------------------------------------------------------- >>-------------------------------------------------------------- >>--------------- >> >>I also added the following : >> >>11. Appendix B - Notification Message PW Status Diagram >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Notification (0x0001) | Message Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0|1| Status (0x0300) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0|1| Status Code=0x00000028 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID=0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message Type=0 | PW Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Status TLV | PWId FEC | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | | >> | PWId FEC or Generalized ID FEC | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> > > >HS> I would prefer to keep 16-bit field after message type as reserved >HS> and start the PW-STATUS TLV on 4-byte boundary so the STATUS code >HS> is not split on 2 16-bit words and so is PW-ID FEC information. > > > i'm not sure that being 32-bit word aligned was a design parameter in LDP. I'll ask Bob Thomas about it. ( there are lot's of instances where LDP is not word aligned. ) > > > > > >>Please send me comments on this text ..... ( last time nobody >>caught the >>problem in the last call ! ) >>After discussing this with the WG chairs we would like to >>reissue a last >>call for this section only. >> >>In lieu of some very good discussion in the RIFT draft does anybody >>thing that it might not be a bad idea to create a completely >>new message >>type ? this would avoid any interference between code that deals with >>the LDP session itself , and PW FEC which is a payload of the >>LDP session. >> >>Comments ? >> >> >>Thanks. >>Luca >> >> >> >> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> >> >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: Re: PW status TLV Problem. Date: Wed, 11 Feb 2004 17:15:09 -0700 Organization: Cisco Systems Lines: 156 Sender: pwe3-admin@ietf.org References: <40244DB6.7050401@cisco.com> <402AAFDD.3040306@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 12 01:18:04 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: Wei Luo In-Reply-To: <402AAFDD.3040306@cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Wei Luo wrote: > Luca, > > Comments inline. > > Another thing you may want to consider is to have a signaling > procedure for implementations that support both FEC 128 and 129 to be > able to determine the FEC type dynamically instead of through manual > configuration. Some earlier revisions of the draft actually have that > section. > ??? I think that the diagram points out that this applies to all FEC in this draft.... what section ? > Luca Martini wrote: > >> 5.3.3. Pseudowire Status Negotiation Procedures >> >> When a PW is first set up the PEs MUST attempt to negotiate the usage >> of the PW status TLV. This is accomplished as follows: >> >> A PE that supports the PW Status TLV MUST include it the initial >> label mapping signaling immediately following the PW FEC and the >> interface parameters field. The PW Status TLV will be used for the >> lifetime of the Pseudowire for PEs that support this TLV. >> >> If the PW Status TLV is not present immediately following the initial >> PW FEC Message received by a PE, then the PW Status TLV will not be >> used and both PEs supporting the pseudowire will revert to the label >> withdraw procedure for signaling status changes. > > > What is the rationale to mandate the PW Status TLV be *immediately* > following the FEC TLV? In other words, why does the ordering of the > TLVs make any difference? > > Implementations always parse the entire Label Mapping message, decode > TLVs into internal binary representations, and then apply appropiate > actions. The location of the PW Status TLV inside the Label Mapping > message does not seem to have any impact on operation. Unless I miss > something obvious, I'd suggest we change the text to "the presence of > the PW status TLV in the Label Mapping message indicates that a PE > supports PW Status signaling." > this actually comes from rfc3036 where the order is specified. the label must immediately follow the FEC etc. I don't really care where the TLV is , but RFC3036 does. > ---Wei > >> >> If PW status TLV is sent immediately following the label mapping TLV >> in the initial PW FEC Message, but the remote PE corresponding FEC >> advertisement does not include a PW status TLV, or the remote PE does >> not support the PW Status TLV then the PW will revert to the label >> withdraw method to signal PW status. Note that if the PW Status TLV >> is not supported it will automatically be ignored since the LDP >> ignore bit is set. >> >> >> >> >> Martini, et al. [Page 18] >> ^L >> Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 >> >> >> If the negotiation process results in the usage of the PW status TLV, >> then the actual PW status is determined by the PW status TLV that was >> sent within the initial PW label mapping. Subsequent updates of PW >> status are conveyed through the notification message >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + PWId FEC or Generalized ID FEC + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Interface parameters | >> | " | >> | " | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |1|0| PW Status (0x0???) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Status Code | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> ------------------------------------------------------------------------------------------------------------------------------------------- >> >> >> I also added the following : >> >> 11. Appendix B - Notification Message PW Status Diagram >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0| Notification (0x0001) | Message Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0|1| Status (0x0300) | Length | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0|1| Status Code=0x00000028 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message ID=0 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Message Type=0 | PW Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Status TLV | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | PW Status TLV | PWId FEC | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> | | >> | PWId FEC or Generalized ID FEC | >> | | >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> Please send me comments on this text ..... ( last time nobody caught >> the problem in the last call ! ) >> After discussing this with the WG chairs we would like to reissue a >> last call for this section only. >> >> In lieu of some very good discussion in the RIFT draft does anybody >> thing that it might not be a bad idea to create a completely new >> message type ? this would avoid any interference between code that >> deals with the LDP session itself , and PW FEC which is a payload of >> the LDP session. >> >> Comments ? >> >> >> Thanks. >> Luca >> >> >> >> >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: RE: PW status TLV Problem - text update Date: Wed, 11 Feb 2004 17:38:22 -0700 Organization: Cisco Systems Lines: 192 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Feb 12 01:41:15 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: pwe3@ietf.org, "Shah, Himanshu" , "Tom Nadeau (tnadeau)" , Wei Luo Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Updated text according to comments. Thanks. Luca 5.3. Signaling of Pseudo Wire Status 5.3.1. Use of Label Mappings. The PEs MUST send PW label mapping messages to their peers as soon as the PW is configured and administratively enabled, regardless of the CE-facing interface state. The PW label should not be withdrawn unless the user administratively configures the CE-facing interface down (or the PW configuration is deleted entirely). Using the procedures outlined in this section a simple label withdraw method MAY also be supported as a primitive means of signaling WP status. It Martini, et al. [Page 16] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 is strongly RECOMMENDED that the PW status signaling procedures below be fully implemented. In any case if the Label mapping is not available the PW MUST be considered in the down state. 5.3.2. Signaling PW status. The PE devices use an LDP TLV to indicate status to their remote peers. This PW Status TLV contains more information than the alternative simple Label Withdraw message. The format of the PW Status TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x096A) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [ note: TLV type 0x096A as defined in [13] pending IANA allocation ] Where the status code is a 4 octet bit field is specified in the PW IANA Allocations document [13]. Each bit in the status code field can be set individually to indicate more then a single failure at once. Each fault can be cleared by sending an appropriate status message with the respective bit cleared. The presence of the lowest bit (PW Not Forwarding) acts only as a generic failure indication when there is a link-down event for which none of the other bits apply. The Status TLV is transported to the remote PW peer via the LDP notification message. The general format of the Notification Message is: Martini, et al. [Page 17] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Notification (0x0001) | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status (TLV) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW Status TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PWId FEC or Generalized ID FEC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Status TLV status code is set to 0x00000028 "PW status", to indicate that PW status follows. Since this notification does not refer to any particular message the Message Id, and Message Type fields are set to 0. [ note: Status Code 0x00000028 as defined in [13] pending IANA allocation ] A more detailed diagram is shown in Appendix B. The PW FEC TLV SHOULD not include the interface parameters as they are ignored in the context of this message. When a PE's CE-facing interface encounters an error, use of the PW status message allows the PE to send a single status message, using a PW FEC TLV with only the group ID set, to denote this change in status for all affected PW connections. As mentioned above the Group ID field can be used to send a status notification for all PWs associated with a particular group ID. This procedure is OPTIONAL, and if it is implemented the LDP Notification message should be as follows: the PW information length field is set to 0, the PW ID field is not present, and the interface parameters field is not present. For the purpose of this document this is called the "wild card PW status notification procedure", and all PEs implementing this design are REQUIRED to accept such a notification message, but are not required to send it. 5.3.3. Pseudowire Status Negotiation Procedures When a PW is first set up the PEs MUST attempt to negotiate the usage of the PW status TLV. This is accomplished as follows: A PE that supports the PW Status TLV MUST include it the initial label mapping signaling immediately following label mapping TLV, the PW FEC, and the interface parameters field. The PW Status TLV will then be used for the lifetime of the Pseudowire. This is shown in the following Martini, et al. [Page 18] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 diagram: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PWId FEC or Generalized ID FEC + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface parameters | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| Generic Label (0x0200) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0| PW Status (0x0???) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If PW status TLV is sent immediately following the label mapping TLV in the initial PW FEC Message, but the remote PE corresponding FEC advertisement does not include a PW status TLV, or the remote PE does not support the PW Status TLV and the PW will revert to the label withdraw method to signal PW status. Note that if the PW Status TLV is not supported, by the remote peer, it will automatically be ignored, since the LDP ignore bit is set. The PW Status TLV, therefore, will not be present in the corresponding FEC advertisement from the remote LDP peer resulting in exactly the above behavior. If the PW Status TLV is not present immediately following the label mapping TLV in the initial PW FEC Message received by a PE, then the PW Status TLV will not be used and both PEs supporting the pseudowire will revert to the label withdraw procedure for signaling status changes. If the negotiation process results in the usage of the PW status TLV, then the actual PW status is determined by the PW status TLV that was sent within the initial PW label mapping. Subsequent updates of PW status are conveyed through the notification message Martini, et al. [Page 19] ^L Internet Draft draft-ietf-pwe3-control-protocol-05.txt December 2003 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Wei Luo Subject: Re: PW status TLV Problem. Date: Wed, 11 Feb 2004 16:42:13 -0800 Lines: 72 Sender: pwe3-admin@ietf.org References: <40244DB6.7050401@cisco.com> <402AAFDD.3040306@cisco.com> <402AC58D.4030701@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 12 01:45:06 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: Luca Martini Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Luca Martini wrote: > > > Wei Luo wrote: > >> Luca, >> >> Comments inline. >> >> Another thing you may want to consider is to have a signaling >> procedure for implementations that support both FEC 128 and 129 to be >> able to determine the FEC type dynamically instead of through manual >> configuration. Some earlier revisions of the draft actually have that >> section. >> > ??? I think that the diagram points out that this applies to all FEC in > this draft.... > what section ? Sorry, I should have clarified that I was making a comment to the draft in general, not this particular section being discussed. I suggested having a section address the compatibility issue of FEC 128 and FEC 129. > >> Luca Martini wrote: >> >>> 5.3.3. Pseudowire Status Negotiation Procedures >>> >>> When a PW is first set up the PEs MUST attempt to negotiate the usage >>> of the PW status TLV. This is accomplished as follows: >>> >>> A PE that supports the PW Status TLV MUST include it the initial >>> label mapping signaling immediately following the PW FEC and the >>> interface parameters field. The PW Status TLV will be used for the >>> lifetime of the Pseudowire for PEs that support this TLV. >>> >>> If the PW Status TLV is not present immediately following the initial >>> PW FEC Message received by a PE, then the PW Status TLV will not be >>> used and both PEs supporting the pseudowire will revert to the label >>> withdraw procedure for signaling status changes. >> >> >> >> What is the rationale to mandate the PW Status TLV be *immediately* >> following the FEC TLV? In other words, why does the ordering of the >> TLVs make any difference? >> >> Implementations always parse the entire Label Mapping message, decode >> TLVs into internal binary representations, and then apply appropiate >> actions. The location of the PW Status TLV inside the Label Mapping >> message does not seem to have any impact on operation. Unless I miss >> something obvious, I'd suggest we change the text to "the presence of >> the PW status TLV in the Label Mapping message indicates that a PE >> supports PW Status signaling." >> > this actually comes from rfc3036 where the order is specified. the label > must immediately follow the FEC etc. > I don't really care where the TLV is , but RFC3036 does. Could you kindly point me to the text in RFC3036 requiring such an ordering? All I found is that the Label Mapping message was drawn in such a way that FEC TLV happens to be in front of Label TLV. Given there is TLV type associated with each, I don't see why the order matters. But that's not the point I am trying to make. Since PW Status TLV could be one of the many optional parameters in the Label Mapping Message and the order doesn't seem to be important for the optional parameters, I would suggest not making that as a mandate. ---Wei From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: Fwd: I-D ACTION:draft-ietf-pwe3-fragmentation-05.txt Date: Thu, 12 Feb 2004 01:13:44 -0500 Lines: 73 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Thu Feb 12 07:16:06 2004 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: "PWE3 (IETF)" Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This revision of the fragmentation draft adds a paragraph to the introduction in response to Sasha's last call comment. It is now ready for IESG review. Cheers, Andy ------- Begin of Forwarded Message ------- To: IETF-Announce: ; Cc: pwe3@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 11 Feb 2004 16:27:49 -0500 Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-fragmentation-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : PWE3 Fragmentation and Reassembly Author(s) : A. Malis, M. Townsley Filename : draft-ietf-pwe3-fragmentation-05.txt Pages : 13 Date : 2004-2-10 This document defines a generalized method of performing fragmentation for use by PWE3 protocols and services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fragmentation-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-fragmentation-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-fragmentation-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-2-10165535.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-fragmentation-05.txt ------- End of Forwarded Message ------- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Florin Balus" Subject: VCCV draft and related sub-TLV options in LSP Ping Date: Thu, 12 Feb 2004 13:44:11 -0500 Lines: 97 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F198.34CE06CA" Cc: l2vpn@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 12 19:47:06 2004 Return-path: To: pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C3F198.34CE06CA Content-Type: text/plain I have some comments related to PW OAM: 1. LSP Ping does not have a sub-TLV for the GID FEC - see 3.2 in draft-ietf-mpls-lsp-ping-04.txt. Just for the VC ID (sub-TLV of 9)- see 3.2.8 paragraph of the above draft. Shouldn't we have one for the Gid FEC (i.e. 10) as it is one of the 2 FECs described in a WG doc - see 5.2.2 of draft-ietf-pwe3-control-protocol-05.txt? 2. Also I just got a chance to check the latest version of the VCCV draft (draft-ietf-pwe3-vccv-02.txt) and I noticed that section 5.2. "MPLS Ping Packet" says: "The LSP Ping header must be used as described [LSP-PING] and must also contain the sub-TLV of 8 for PW circuits. This sub-TLV must be sent containing the circuit to be verified as the "VC ID" field:" First VC ID is identified by sub-TLV of 9 (see 3.2 in draft-ietf-mpls-lsp-ping-04.txt) - sub-TLV of 8 is actually associated with the L2VPN Endpoint. Also I think that we should let this option opened to all related PWE3 structures: VCID and GID FEC (wehenever we get the sub-TLV for it). Florin Balus Nortel Networks Tel: 1-613-768-4997 ESN: 398-4997 Fax: 1-613-765-4123 ESN: 395-4123 Email: mailto:balus@nortelnetworks.com DNE site: http://navigate.us.nortel.com/dne NPW 2003 http://www.nortelnetworks.com/npw2003 ------_=_NextPart_001_01C3F198.34CE06CA Content-Type: text/html Content-Transfer-Encoding: quoted-printable VCCV draft and related sub-TLV options in LSP Ping

I have some comments related to PW OAM:

1. LSP Ping does not have a sub-TLV for the GID FEC - = see 3.2 in draft-ietf-mpls-lsp-ping-04.txt. Just for the VC ID (sub-TLV = of 9)- see 3.2.8 paragraph of the above draft. Shouldn't we have one = for the Gid FEC (i.e. 10) as it is one of the 2 FECs described in a WG = doc - see 5.2.2 of draft-ietf-pwe3-control-protocol-05.txt?

2. Also I just got a chance to check the latest = version of the VCCV draft (draft-ietf-pwe3-vccv-02.txt) and I noticed = that section 5.2. "MPLS Ping Packet" says:

"The LSP Ping header must be used as described = [LSP-PING] and must also contain the sub-TLV of 8 for PW circuits. = This
 sub-TLV must be sent containing the circuit to = be verified as the "VC ID" field:"

First VC ID is identified by sub-TLV of 9 (see 3.2 in = draft-ietf-mpls-lsp-ping-04.txt) - sub-TLV of 8 is actually associated = with the L2VPN Endpoint. Also I think that we should let this option = opened to all related PWE3 structures: VCID and GID FEC (wehenever we = get the sub-TLV for it).

Florin Balus
Nortel Networks
Tel: 1-613-768-4997  ESN: 398-4997
Fax: 1-613-765-4123 ESN: 395-4123
Email: mailto:balus@nortelnetworks.com=
DNE site: http://navigate.us.nortel.com/dne
NPW 2003 http://www.nortelnetworks.com/npw2003

------_=_NextPart_001_01C3F198.34CE06CA-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: Re: VCCV draft and related sub-TLV options in LSP Ping Date: Fri, 13 Feb 2004 09:54:39 -0800 (PST) Lines: 46 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org, "" X-From: pwe3-admin@ietf.org Fri Feb 13 18:58:05 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: Florin Balus In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Florin, On Thu, 12 Feb 2004, Florin Balus wrote: > > I have some comments related to PW OAM: > > 1. LSP Ping does not have a sub-TLV for the GID FEC - see 3.2 in > draft-ietf-mpls-lsp-ping-04.txt. Just for the VC ID (sub-TLV of 9)- see > 3.2.8 paragraph of the above draft. Shouldn't we have one for the Gid FEC > (i.e. 10) as it is one of the 2 FECs described in a WG doc - see 5.2.2 of > draft-ietf-pwe3-control-protocol-05.txt? > > 2. Also I just got a chance to check the latest version of the VCCV draft > (draft-ietf-pwe3-vccv-02.txt) and I noticed that section 5.2. "MPLS Ping > Packet" says: > "The LSP Ping header must be used as described [LSP-PING] and must also > contain the sub-TLV of 8 for PW circuits. This > sub-TLV must be sent containing the circuit to be verified as the "VC ID" > field:" > > First VC ID is identified by sub-TLV of 9 (see 3.2 in > draft-ietf-mpls-lsp-ping-04.txt) - sub-TLV of 8 is actually associated with > the L2VPN Endpoint. Thanks for catching that. We will fix it. > Also I think that we should let this option opened to > all related PWE3 structures: VCID and GID FEC (wehenever we get the sub-TLV > for it). > Agreed. We will generalize the text to cover this. Thanks for your comments ! rahul > Florin Balus > Nortel Networks > Tel: 1-613-768-4997 ESN: 398-4997 > Fax: 1-613-765-4123 ESN: 395-4123 > Email: mailto:balus@nortelnetworks.com > DNE site: http://navigate.us.nortel.com/dne > NPW 2003 http://www.nortelnetworks.com/npw2003 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: IETF59 PWE3 slots Date: Fri, 13 Feb 2004 17:43:24 +0000 Organization: Cisco Systems, Inc. Lines: 18 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Feb 13 18:59:03 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I have the following slot requests for Seoul: Monique Morrow - OAM Msg Mapping Orly Nicklass - SAToP MIB Orly Nicklass - TDM PW MIB Sasha Vainshtein - SAToP Sasha Vainshtein - TDM control protocol extensions Have I missed anyone? The chairs will do the usual status update, and I will set aside some time for new charter Any other slot requests? Any other topic requests? - Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: PWE3 new WG items? Date: Fri, 13 Feb 2004 18:25:09 +0000 Organization: Cisco Systems, Inc. Lines: 7 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Feb 13 19:28:08 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O As we mentioned at last IETF we need to start the process of re-chartering the PWE3 WG. What do WG members think we need to work on next? - Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? Date: Fri, 13 Feb 2004 13:50:15 -0500 Lines: 41 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Fri Feb 13 19:53:04 2004 Return-path: To: "'stbryant@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O QOS stuff of course... :-) We submitted PWE3 Control protocol extension to exchange capabilities as a way to add more stuff and to negotiate. I think QOS for PW is important. Others are, 1) IP PW 2) Multiprotocol PW 3) Inter-carrier PW (PW switching?) 4) PW bundling 5) PW fault tolerence 6) PW congestion (Eric Rosen already has a proposal on this) /himanshu PS. assuming that OAM is ongoing and underway already. > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Friday, February 13, 2004 1:25 PM > To: pwe3@ietf.org > Subject: [PWE3] PWE3 new WG items? > > > > As we mentioned at last IETF we need to start the > process of re-chartering the PWE3 WG. > > What do WG members think we need to work on next? > > - Stewart > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Chris Metz Subject: Re: PWE3 new WG items? Date: Fri, 13 Feb 2004 11:01:04 -0800 Lines: 23 Sender: pwe3-admin@ietf.org References: <402D1685.30906@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Fri Feb 13 20:04:06 2004 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: stbryant@cisco.com In-Reply-To: <402D1685.30906@cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O At 06:25 PM 2/13/2004 +0000, Stewart Bryant wrote: >As we mentioned at last IETF we need to start the >process of re-chartering the PWE3 WG. > >What do WG members think we need to work on next? PW Stitching - that is the concatenation of two or more PW segments forming a multi-segment/multi-hop PW. Cheers ... >- Stewart > > > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt Date: Mon, 16 Feb 2004 12:00:27 +0000 Organization: Cisco Systems, Inc. Lines: 145 Sender: pwe3-admin@ietf.org References: <200402091628.i19GSwRa084489@workhorse.fictitious.org> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Feb 16 13:04:07 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Curtis Villamizar In-Reply-To: <200402091628.i19GSwRa084489@workhorse.fictitious.org> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O There are some operations that need to be able to distinguish between IP and non-IP MPLS payloads. For example a router performing ECMP based on the IP addresses or other information in the IP header, or an IPFIX/PSAMP packet sampling system that needs to analyse the payload contents. We identified this need in PWE3 and proposed a solution. This is described in sections 5.4.3 and 5.4.4 of the PWE3 Architecture draft: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-06.txt In essence we proposed that the nibble that immediately follows the MPLS bottom label has the following semantics: Value Meaning 0 PWE3 payload* 1 Identified payload type (see below) 4 IPv4 6 IPv6 * It might be argued that this should be changed to mean "unidentified payload type" The identified payload type above is the first nibble in a longword with the following definition: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1| reserved = 0 | PA | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | As defined by PPP DLL protocol definition | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: PWE3 PID The meaning of the fields of the PWE3 PID (Figure 14) is as follows: PA protocol authority for the user plane or the control plane protocol ID 0 = PPP DLL 1-15 = Reserved Protocol ID Protocol ID following the format defined by the protocol authority identified in PA. Bits 4 to 11 inclusive are reserved for future use and must be zero. PWE3 currently describes this in terms of historic IP version numbers, but IESG feedback is that we need to use a new registry. The proposal is that there is a new "nibble that follows the MPLS label" registry. This will still have the values and semantics described above. A new draft describing this will be submitted when the IETF embargo on new drafts lifts, and the PWE3 architecture draft modified accordingly. Note that this does not change the existing PWE3 protocol or headers, just the way that we describe the protocol. If this proposal gains approval, the implication for ecrtp-over-mpls would be that it should either: 1) Run under first nibble 0 2) Run under first nibble 1 with an ecrtp-over-mpls as the PPP-DLL value 3) Request a first nibble value from the new registry - Stewart Curtis Villamizar wrote: > ------- Blind-Carbon-Copy > > To: "Ash, Gerald R (Jerry), ALABS" > cc: avt@ietf.org > Reply-To: curtis@fictitious.org > Subject: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt > In-reply-to: Your message of "Mon, 09 Feb 2004 07:39:42 CST." > <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com> > Date: Mon, 09 Feb 2004 11:28:58 -0500 > From: Curtis Villamizar > > > In message <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com> > , "Ash, Gerald R (Jerry), ALABS" writes: > >>All, >> >>Please review and comment on 'Protocol Extensions for ECRTP over MPLS' http:/ >>/www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt. >> The protocol extensions enable the use of MPLS to route enhanced compressed >>RTP (ECRTP) compressed packets over an MPLS LSP without compression/decompres >>sion cycles at each router. >> >>The proposed extensions are based on the requirements documented in 'Requirem >>ents for ECRTP over MPLS' http://www.ietf.org/internet-drafts/draft-ash-avt-e >>crtp-over-mpls-reqs-01.txt. >> >>Thanks, >>Jerry >> >> >> Title : Protocol Extensions for ECRTP over MPLS >> Author(s) : J. Ash >> Filename : draft-ash-avt-ecrtp-over-mpls-protocol-00.txt >> Pages : 0 >> Date : 2004-2-5 > > > > Jerry, > > This looks to be a very good direction to go in. I've dropped MPLS > from the Cc and put MPLS on the bcc so people know the discussion is > on the AVT mailing list only. > > In your encapsulations you should make sure to avoid any values in the > first byte that could be mistaken as IPv4 or IPv6 or any of the > encapsulations being worked on by those working on VPN and PW. See > "The PWE3 Control Word", Jonathan Stein, 22-Oct-02, > draft-stein-pwe3-controlword-00.txt, for some early discussion on > that. Note though that "Payload Type" is something that many > providers require so that multipath can be used on IP traffic which > consitutes the majority of traffic yet reordering is avoided for > traffic which cannot be split based on what appears to be an IP header > and the IP src/dst pair. > > It might be best to reserve a single fixed first byte for the "Packet > Type" (and I suggest you make up a name for this shim such as > SCID_Packet_Type) and use the second byte for the packet types that > you have defined. Just as you have to get numbers for SCID_Request > Object and Header_Compression_Reply Object from IANA, you'll have to > coordinate with others over this number space, though it is less clear > if IANA is the authority on this quite yet. > > Curtis > > ------- End of Blind-Carbon-Copy > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt Date: Mon, 16 Feb 2004 14:26:08 +0200 Lines: 210 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: avt@ietf.org, pwe3@ietf.org, Curtis Villamizar X-From: pwe3-admin@ietf.org Mon Feb 16 13:32:07 2004 Return-path: To: "'stbryant@cisco.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Stewart and all, I am not sure I understand the idea about the new registry. ECMP safety of the "generic" CW is based on the fact that value 0 is not used in the "protocol versions" registry, and the decision to swap the CW and RTP header in TDM PWs over MPLS has been based on value 8 (that is what the nibble in question is in the RTP header) has been allocated for something called PIP in this registry even if it probably has never been used. If we go for the new registry, what is going to happen if somebody, at some time, decides to allocate value 4 (or, in fact, any value between 4 and 9) in it? Do we expect IANA to maintain the linkage between the two seemingly unrelated registries? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Monday, February 16, 2004 2:00 PM > To: Curtis Villamizar > Cc: avt@ietf.org; pwe3@ietf.org > Subject: [PWE3] Re: I-D > ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt > > > > There are some operations that need to be able to distinguish > between IP and non-IP MPLS payloads. For example a router > performing ECMP based on the IP addresses or other information > in the IP header, or an IPFIX/PSAMP packet sampling system > that needs to analyse the payload contents. > > We identified this need in PWE3 and proposed a solution. This > is described in sections 5.4.3 and 5.4.4 of the PWE3 Architecture > draft: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-06.txt > > In essence we proposed that the nibble that immediately follows > the MPLS bottom label has the following semantics: > > Value Meaning > 0 PWE3 payload* > 1 Identified payload type (see below) > 4 IPv4 > 6 IPv6 > > * It might be argued that this should be changed to mean > "unidentified payload type" > > The identified payload type above is the first nibble > in a longword with the following definition: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |0 0 0 1| reserved = 0 | PA | Protocol ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | As defined by PPP DLL protocol definition > | > | > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 14: PWE3 PID > > The meaning of the fields of the PWE3 PID (Figure 14) is > as follows: > > > PA protocol authority for the user plane or the > control plane > protocol ID > 0 = PPP DLL > 1-15 = Reserved > > Protocol ID > Protocol ID following the format defined by the protocol > authority identified in PA. > > Bits 4 to 11 inclusive are reserved for future use and > must be zero. > > PWE3 currently describes this in terms of historic IP version numbers, > but IESG feedback is that we need to use a new registry. > > The proposal is that there is a new "nibble that follows the MPLS > label" registry. This will still have the values and > semantics described > above. A new draft describing this will be submitted when the IETF > embargo on new drafts lifts, and the PWE3 architecture draft modified > accordingly. Note that this does not change the existing PWE3 protocol > or headers, just the way that we describe the protocol. > > If this proposal gains approval, the implication for ecrtp-over-mpls > would be that it should either: > > 1) Run under first nibble 0 > 2) Run under first nibble 1 with an ecrtp-over-mpls as the > PPP-DLL value > 3) Request a first nibble value from the new registry > > - Stewart > > > Curtis Villamizar wrote: > > > ------- Blind-Carbon-Copy > > > > To: "Ash, Gerald R (Jerry), ALABS" > > cc: avt@ietf.org > > Reply-To: curtis@fictitious.org > > Subject: Re: I-D > ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt > > In-reply-to: Your message of "Mon, 09 Feb 2004 07:39:42 CST." > > > <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com> > > Date: Mon, 09 Feb 2004 11:28:58 -0500 > > From: Curtis Villamizar > > > > > > In message > <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com> > > , "Ash, Gerald R (Jerry), ALABS" writes: > > > >>All, > >> > >>Please review and comment on 'Protocol Extensions for ECRTP > over MPLS' http:/ > >>/www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls- > protocol-00.txt. > >> The protocol extensions enable the use of MPLS to route > enhanced compressed > >>RTP (ECRTP) compressed packets over an MPLS LSP without > compression/decompres > >>sion cycles at each router. > >> > >>The proposed extensions are based on the requirements > documented in 'Requirem > >>ents for ECRTP over MPLS' > http://www.ietf.org/internet-drafts/draft-ash-avt-e > >>crtp-over-mpls-reqs-01.txt. > >> > >>Thanks, > >>Jerry > >> > >> > >> Title : Protocol Extensions for ECRTP over MPLS > >> Author(s) : J. Ash > >> Filename : draft-ash-avt-ecrtp-over-mpls-protocol-00.txt > >> Pages : 0 > >> Date : 2004-2-5 > > > > > > > > Jerry, > > > > This looks to be a very good direction to go in. I've dropped MPLS > > from the Cc and put MPLS on the bcc so people know the discussion is > > on the AVT mailing list only. > > > > In your encapsulations you should make sure to avoid any > values in the > > first byte that could be mistaken as IPv4 or IPv6 or any of the > > encapsulations being worked on by those working on VPN and PW. See > > "The PWE3 Control Word", Jonathan Stein, 22-Oct-02, > > draft-stein-pwe3-controlword-00.txt, for some early discussion on > > that. Note though that "Payload Type" is something that many > > providers require so that multipath can be used on IP traffic which > > consitutes the majority of traffic yet reordering is avoided for > > traffic which cannot be split based on what appears to be > an IP header > > and the IP src/dst pair. > > > > It might be best to reserve a single fixed first byte for > the "Packet > > Type" (and I suggest you make up a name for this shim such as > > SCID_Packet_Type) and use the second byte for the packet types that > > you have defined. Just as you have to get numbers for SCID_Request > > Object and Header_Compression_Reply Object from IANA, you'll have to > > coordinate with others over this number space, though it is > less clear > > if IANA is the authority on this quite yet. > > > > Curtis > > > > ------- End of Blind-Carbon-Copy > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: Re: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt Date: Mon, 16 Feb 2004 13:06:11 +0000 Organization: Cisco Systems, Inc. Lines: 267 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, pwe3@ietf.org, Curtis Villamizar X-From: pwe3-admin@ietf.org Mon Feb 16 14:09:06 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Sasha Vainshtein In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Sasha Vainshtein wrote: > Stewart and all, > > I am not sure I understand the idea about the new registry. > ECMP safety of the "generic" CW is based on the fact that > value 0 is not used in the "protocol versions" registry, and > the decision to swap the CW and RTP header in TDM PWs over MPLS > has been based on value 8 (that is what the nibble in question is > in the RTP header) has been allocated for something called PIP in this > registry even if it probably has never been used. The protocol (and values) will stay the same. We are only talking about the way that we formally describe the protocol. The issue was that the IESG did not like PWE3 changing the IP version registry, but our incomming AD thought that a new registry, as described, would be more acceptable. > > If we go for the new registry, what is going to happen if somebody, > at some time, decides to allocate value 4 (or, in fact, any value between 4 > and 9) in it? Do we expect IANA to maintain the linkage between the > two seemingly unrelated registries? 4 and 6 will be preallocated, so that they do not get trodden on. We need to find out if there is any use of 5, 7, 8 and 9. I.e. are there any routers in the Internet that carry IP versions 5, 7, 8 or 9 over MPLS. If there are, we need to include them in the registry as pre-allocated values. If not, then a new implementation would need to operate under the rules proposed below (i.e. run under 0, 1 or their own value). The IESG would advise IANA on the usage of this registry. - Stewart > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) > > > > >>-----Original Message----- >>From: Stewart Bryant [mailto:stbryant@cisco.com] >>Sent: Monday, February 16, 2004 2:00 PM >>To: Curtis Villamizar >>Cc: avt@ietf.org; pwe3@ietf.org >>Subject: [PWE3] Re: I-D >>ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt >> >> >> >>There are some operations that need to be able to distinguish >>between IP and non-IP MPLS payloads. For example a router >>performing ECMP based on the IP addresses or other information >>in the IP header, or an IPFIX/PSAMP packet sampling system >>that needs to analyse the payload contents. >> >>We identified this need in PWE3 and proposed a solution. This >>is described in sections 5.4.3 and 5.4.4 of the PWE3 Architecture >>draft: >> >>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-06.txt >> >>In essence we proposed that the nibble that immediately follows >>the MPLS bottom label has the following semantics: >> >>Value Meaning >>0 PWE3 payload* >>1 Identified payload type (see below) >>4 IPv4 >>6 IPv6 >> >>* It might be argued that this should be changed to mean >>"unidentified payload type" >> >>The identified payload type above is the first nibble >>in a longword with the following definition: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >>7 8 9 0 1 >> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |0 0 0 1| reserved = 0 | PA | Protocol ID >> | >> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | As defined by PPP DLL protocol definition >> | >> | >> | >> >>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Figure 14: PWE3 PID >> >> The meaning of the fields of the PWE3 PID (Figure 14) is >>as follows: >> >> >> PA protocol authority for the user plane or the >>control plane >> protocol ID >> 0 = PPP DLL >> 1-15 = Reserved >> >> Protocol ID >> Protocol ID following the format defined by the protocol >> authority identified in PA. >> >> Bits 4 to 11 inclusive are reserved for future use and >>must be zero. >> >>PWE3 currently describes this in terms of historic IP version numbers, >>but IESG feedback is that we need to use a new registry. >> >>The proposal is that there is a new "nibble that follows the MPLS >>label" registry. This will still have the values and >>semantics described >>above. A new draft describing this will be submitted when the IETF >>embargo on new drafts lifts, and the PWE3 architecture draft modified >>accordingly. Note that this does not change the existing PWE3 protocol >>or headers, just the way that we describe the protocol. >> >>If this proposal gains approval, the implication for ecrtp-over-mpls >>would be that it should either: >> >>1) Run under first nibble 0 >>2) Run under first nibble 1 with an ecrtp-over-mpls as the >>PPP-DLL value >>3) Request a first nibble value from the new registry >> >>- Stewart >> >> >>Curtis Villamizar wrote: >> >> >>>------- Blind-Carbon-Copy >>> >>>To: "Ash, Gerald R (Jerry), ALABS" >>>cc: avt@ietf.org >>>Reply-To: curtis@fictitious.org >>>Subject: Re: I-D >> >>ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt >> >>>In-reply-to: Your message of "Mon, 09 Feb 2004 07:39:42 CST." >>> >> >><9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com> >> >>>Date: Mon, 09 Feb 2004 11:28:58 -0500 >>>From: Curtis Villamizar >>> >>> >>>In message >> >><9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com> >> >>>, "Ash, Gerald R (Jerry), ALABS" writes: >>> >>> >>>>All, >>>> >>>>Please review and comment on 'Protocol Extensions for ECRTP >> >>over MPLS' http:/ >> >>>>/www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls- >> >>protocol-00.txt. >> >>>>The protocol extensions enable the use of MPLS to route >> >>enhanced compressed >> >>>>RTP (ECRTP) compressed packets over an MPLS LSP without >> >>compression/decompres >> >>>>sion cycles at each router. >>>> >>>>The proposed extensions are based on the requirements >> >>documented in 'Requirem >> >>>>ents for ECRTP over MPLS' >> >>http://www.ietf.org/internet-drafts/draft-ash-avt-e >> >>>>crtp-over-mpls-reqs-01.txt. >>>> >>>>Thanks, >>>>Jerry >>>> >>>> >>>> Title : Protocol Extensions for ECRTP over MPLS >>>> Author(s) : J. Ash >>>> Filename : draft-ash-avt-ecrtp-over-mpls-protocol-00.txt >>>> Pages : 0 >>>> Date : 2004-2-5 >>> >>> >>> >>>Jerry, >>> >>>This looks to be a very good direction to go in. I've dropped MPLS >>>from the Cc and put MPLS on the bcc so people know the discussion is >>>on the AVT mailing list only. >>> >>>In your encapsulations you should make sure to avoid any >> >>values in the >> >>>first byte that could be mistaken as IPv4 or IPv6 or any of the >>>encapsulations being worked on by those working on VPN and PW. See >>>"The PWE3 Control Word", Jonathan Stein, 22-Oct-02, >>>draft-stein-pwe3-controlword-00.txt, for some early discussion on >>>that. Note though that "Payload Type" is something that many >>>providers require so that multipath can be used on IP traffic which >>>consitutes the majority of traffic yet reordering is avoided for >>>traffic which cannot be split based on what appears to be >> >>an IP header >> >>>and the IP src/dst pair. >>> >>>It might be best to reserve a single fixed first byte for >> >>the "Packet >> >>>Type" (and I suggest you make up a name for this shim such as >>>SCID_Packet_Type) and use the second byte for the packet types that >>>you have defined. Just as you have to get numbers for SCID_Request >>>Object and Header_Compression_Reply Object from IANA, you'll have to >>>coordinate with others over this number space, though it is >> >>less clear >> >>>if IANA is the authority on this quite yet. >>> >>>Curtis >>> >>>------- End of Blind-Carbon-Copy >>> >>> >>> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-tdmoip-00.txt Date: Mon, 16 Feb 2004 10:33:16 -0500 Lines: 80 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 16 16:34:34 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : TDM over IP Author(s) : Y. Stein Filename : draft-ietf-pwe3-tdmoip-00.txt Pages : 28 Date : 2004-2-13 This document describes methods for transporting time division multiplexed (TDM) voice and data signals over Pseudowires. It is a revision of draft-anavi-tdmoip-06. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdmoip-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-tdmoip-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-tdmoip-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt Date: Mon, 16 Feb 2004 21:05:14 +0200 Lines: 70 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: avt@ietf.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 16 20:10:07 2004 Return-path: To: "'curtis@fictitious.org'" , stbryant@cisco.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Curtis and Stewart, Thank you for the detailed explanation. To handle the new registry in a "safe" way, I would suggest to specify that only values 0 to 3 can be used, with 0 assigned to unindentified payload type, 1 - to identified payload type and leave 2 and 3 unassigned. In parallel IANA should declare values 1 to 3 (currently unassigned) as reserved in the version numbers registry to prevent any attempt to assign these values in future. Does it make sense? With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > Sent: Monday, February 16, 2004 5:08 PM > To: stbryant@cisco.com > Cc: Sasha Vainshtein; avt@ietf.org; pwe3@ietf.org; Curtis Villamizar > Subject: Re: [PWE3] Re: I-D > ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt > > > > In message <4030C043.3030509@cisco.com>, Stewart Bryant writes: > > > > > > 4 and 6 will be preallocated, so that they do not get trodden on. > > > > We need to find out if there is any use of 5, 7, 8 and 9. I.e. > > are there any routers in the Internet that carry IP versions > > 5, 7, 8 or 9 over MPLS. If there are, we need to include them > > in the registry as pre-allocated values. If not, then a > > new implementation would need to operate under the rules > > proposed below (i.e. run under 0, 1 or their own value). > > > > The IESG would advise IANA on the usage of this registry. > > > > - Stewart > > > For all pracical purposes 7, 8 and 9 are not used at all, over MPLS or > otherwise. These are left overs from the competing proposals to > replace IPv4. The decision was made to go with IPv6. Since then none > of them have been used. It would be reasonable for IESG/IANA to > declare these values as having been temporarily assigned for protocol > experiments which are long ago over and available for reclaim, but > apparently they are choosing not to do so. There is (or was at some > point) some use of 5 (ST-II). Use of ST-II may have disappeared, but > I'm uncertain of that. > > IESG does have a very good point in that what these are being used for > is not IP version numbers where the other 20 bytes are also an IP > header. That IPv4 and IPv6 values are reserved in the new registry to > allow the largest single contributor of traffic to be placed in MPLS > without a shim is good, and not breaking very widespread current usage > is good. If you reserve any number for "other IP version" then an IP > packet with 5, 7, 8 and 9 or any new assignments of IP versions could > be carried with a shim. > > Curtis > From avt-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Curtis Villamizar Subject: Re: [PWE3] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt Date: Mon, 16 Feb 2004 15:17:24 -0500 Lines: 108 Sender: avt-admin@ietf.org References: Reply-To: curtis@fictitious.org Cc: "'curtis@fictitious.org'" , stbryant@cisco.com, avt@ietf.org, pwe3@ietf.org X-From: avt-admin@ietf.org Tue Feb 17 10:55:29 2004 Return-path: To: Sasha Vainshtein In-reply-to: Your message of "Mon, 16 Feb 2004 21:05:14 +0200." Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Status: O In message , Sasha Vainshtein writ es: > Curtis and Stewart, > Thank you for the detailed explanation. > > To handle the new registry in a "safe" way, I would suggest to specify > that only values 0 to 3 can be used, with 0 assigned to unindentified > payload type, 1 - to identified payload type and leave 2 and 3 unassigned. > > In parallel IANA should declare values 1 to 3 (currently unassigned) > as reserved in the version numbers registry to prevent any attempt to > assign these values in future. > > Does it make sense? > > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > tel: +972-3-7659993 (office) > +972-8-9254948 (res.) > +972-58-674833 (cell.) No it doesn't make sense. Separate number spaces allow a value to be reserved for "other IP version" in which case there would be a shim followed by the complete 20 byte IP header with the version number filled in there. The values of 4 and 6 can be marked as "reserved to accommodate direct encapsulation of IPv4 and IPv6". If you wanted to be nice to ST-II then you could also reserve the number 5, but there is no ST-II over MPLS currently flowing so there is no concern over breaking a current deployment by requiring a shim. For the purpose of multipath, 4 and 6 are splitable, looking into the IPv4 or IPv6 headers for src/dst addresses. Any other value is either not supported by the multipath implementation or if supported, must look deeper into the packet. For example with TUBA traffic (version 7?) the shim would have the value for "other IP version" followed by a full header with the actual version in it. The TUBA traffic would be splitable by looking into the 20 byte addresses (but chances of running at line rate would be real small which is part of why we don't see any TUBA traffic). Curtis ps - No modern router supports IPv 7 8, or 9. No commercial router, or ISP deployed router ever supported IPv 7 8, or 9. No IPv 7 8, or 9 has been seen on a commercial network in nearly a decade. Other than TUBA (over OSI) there probably has never been any of this traffic on anything but a demo setup. > > -----Original Message----- > > From: Curtis Villamizar [mailto:curtis@workhorse.fictitious.org] > > Sent: Monday, February 16, 2004 5:08 PM > > To: stbryant@cisco.com > > Cc: Sasha Vainshtein; avt@ietf.org; pwe3@ietf.org; Curtis Villamizar > > Subject: Re: [PWE3] Re: I-D > > ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt > > > > > > > > In message <4030C043.3030509@cisco.com>, Stewart Bryant writes: > > > > > > > > > 4 and 6 will be preallocated, so that they do not get trodden on. > > > > > > We need to find out if there is any use of 5, 7, 8 and 9. I.e. > > > are there any routers in the Internet that carry IP versions > > > 5, 7, 8 or 9 over MPLS. If there are, we need to include them > > > in the registry as pre-allocated values. If not, then a > > > new implementation would need to operate under the rules > > > proposed below (i.e. run under 0, 1 or their own value). > > > > > > The IESG would advise IANA on the usage of this registry. > > > > > > - Stewart > > > > > > For all pracical purposes 7, 8 and 9 are not used at all, over MPLS or > > otherwise. These are left overs from the competing proposals to > > replace IPv4. The decision was made to go with IPv6. Since then none > > of them have been used. It would be reasonable for IESG/IANA to > > declare these values as having been temporarily assigned for protocol > > experiments which are long ago over and available for reclaim, but > > apparently they are choosing not to do so. There is (or was at some > > point) some use of 5 (ST-II). Use of ST-II may have disappeared, but > > I'm uncertain of that. > > > > IESG does have a very good point in that what these are being used for > > is not IP version numbers where the other 20 bytes are also an IP > > header. That IPv4 and IPv6 values are reserved in the new registry to > > allow the largest single contributor of traffic to be placed in MPLS > > without a shim is good, and not breaking very widespread current usage > > is good. If you reserve any number for "other IP version" then an IP > > packet with 5, 7, 8 and 9 or any new assignments of IP versions could > > be carried with a shim. > > > > Curtis > > > _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From avt-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Curtis Villamizar Subject: Re: [PWE3] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt Date: Mon, 16 Feb 2004 10:08:24 -0500 Lines: 44 Sender: avt-admin@ietf.org References: <4030C043.3030509@cisco.com> Reply-To: curtis@fictitious.org Cc: Sasha Vainshtein , avt@ietf.org, pwe3@ietf.org, Curtis Villamizar X-From: avt-admin@ietf.org Tue Feb 17 10:55:29 2004 Return-path: To: stbryant@cisco.com In-reply-to: Your message of "Mon, 16 Feb 2004 13:06:11 GMT." <4030C043.3030509@cisco.com> Errors-To: avt-admin@ietf.org X-BeenThere: avt@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Audio/Video Transport Working Group List-Post: List-Help: List-Subscribe: , Status: O In message <4030C043.3030509@cisco.com>, Stewart Bryant writes: > > > 4 and 6 will be preallocated, so that they do not get trodden on. > > We need to find out if there is any use of 5, 7, 8 and 9. I.e. > are there any routers in the Internet that carry IP versions > 5, 7, 8 or 9 over MPLS. If there are, we need to include them > in the registry as pre-allocated values. If not, then a > new implementation would need to operate under the rules > proposed below (i.e. run under 0, 1 or their own value). > > The IESG would advise IANA on the usage of this registry. > > - Stewart For all pracical purposes 7, 8 and 9 are not used at all, over MPLS or otherwise. These are left overs from the competing proposals to replace IPv4. The decision was made to go with IPv6. Since then none of them have been used. It would be reasonable for IESG/IANA to declare these values as having been temporarily assigned for protocol experiments which are long ago over and available for reclaim, but apparently they are choosing not to do so. There is (or was at some point) some use of 5 (ST-II). Use of ST-II may have disappeared, but I'm uncertain of that. IESG does have a very good point in that what these are being used for is not IP version numbers where the other 20 bytes are also an IP header. That IPv4 and IPv6 values are reserved in the new registry to allow the largest single contributor of traffic to be placed in MPLS without a shim is good, and not breaking very widespread current usage is good. If you reserve any number for "other IP version" then an IP packet with 5, 7, 8 and 9 or any new assignments of IP versions could be carried with a shim. Curtis _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-tc-mib-04.txt Date: Tue, 17 Feb 2004 10:35:57 -0500 Lines: 81 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 17 16:37:05 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Definitions for Textual Conventions and OBJECT-IDENTITIES for Pseudo-Wires Management Author(s) : T. Nadeau, D. Danenberg, D. Zelig, A. Malis Filename : draft-ietf-pwe3-pw-tc-mib-04.txt Pages : 12 Date : 2004-2-17 This memo defines an experimental portion of the Management information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the textual conventions to be used in the various Pseudo Wire (PW) MIB modules. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-tc-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-tc-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-mpls-mib-05.txt Date: Tue, 17 Feb 2004 10:36:20 -0500 Lines: 82 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 17 16:37:10 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) over MPLS PSN Management Information Base Author(s) : D. Zelig, T. Nadeau, D. Danenberg Filename : draft-ietf-pwe3-pw-mpls-mib-05.txt Pages : 27 Date : 2004-2-17 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes MIB module for PW operation over Multi-Protocol Label Switching (MPLS) Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mpls-mib-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mpls-mib-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-enet-mib-04.txt Date: Tue, 17 Feb 2004 10:36:04 -0500 Lines: 81 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 17 16:37:06 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Ethernet Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-enet-mib-04.txt Pages : 21 Date : 2004-2-17 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Ethernet Pseudo Wire (PW) services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-enet-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-enet-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-pw-mib-04.txt Date: Tue, 17 Feb 2004 10:36:12 -0500 Lines: 82 Sender: pwe3-admin@ietf.org Reply-To: Internet-Drafts@ietf.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 17 16:37:05 2004 Return-path: To: IETF-Announce: ; Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF. Title : Pseudo Wire (PW) Management Information Base Author(s) : D. Zelig, T. Nadeau, D. Danenberg, S. Mantin Filename : draft-ietf-pwe3-pw-mib-04.txt Pages : 48 Date : 2004-2-17 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudo Wire (PW) services on a general Packet Switched Net (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pwe3-pw-mib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pwe3-pw-mib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: PWE3 new WG items? Date: Tue, 17 Feb 2004 18:44:13 -0000 Lines: 43 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Tue Feb 17 19:47:04 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: RE: [PWE3] PWE3 new WG items? Thread-Index: AcP1hgm1mqPmwlHVQmmUcH8h/qhtcQ== To: X-OriginalArrivalTime: 17 Feb 2004 18:44:13.0776 (UTC) FILETIME=[09F1A500:01C3F586] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Folks, > QOS stuff of course... :-) >=20 > We submitted PWE3 Control protocol extension to=20 > exchange capabilities as a way to add more stuff > and to negotiate. I think QOS for PW is important. An observation/fact: A PW acts as a client to a server layer (be it = MPLS, IP or whatever) and as a result the QoS that can be provided by a = PW cannot be better than the QoS provided by the server layer used by = the PW. My comments: 1) Assuming that the QoS in the available server layers (e.g EXP = bits/DiffServ for the MPLS/IP server layers) is adequate (and it could = be argued that it isn't) then given that a PW is basically a MPLS LSP = with sequence number support, why does PW QoS need its own = specification? Why can't a PW use the same QoS mechanisms as MPLS LSPs? For example, why would a service provider deploying PWs over a MPLS core = want to use two different but interacting QoS mechanisms (one for PWs, = one for MPLS LSPs) and add significant additional fault = conditions/complexity/opex to their network when they could use the same = QoS mechanism for both PWs and MPLS? 2) Assuming that QoS in the available server layers is not adequate then = seeing as PW QoS is dependant on the server layer QoS, shouldn't the = problem of specifying adequate QoS in the available server layers be = addressed first? Once there is adequate QoS in the available server = layers then comment (1) above applies. So either: QoS for MPLS is adequate and ergo the problem of QoS for PWs has already = been addressed. Or, QoS for MPLS is inadequate and ergo QoS for MPLS should be addressed = first and then the problem of QoS for PWs has already been addressed. Ben The above is my personal view and does not necessarily reflect the = opinion of my employer. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? Date: Tue, 17 Feb 2004 14:21:28 -0500 Lines: 81 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-From: pwe3-admin@ietf.org Tue Feb 17 20:24:04 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Ben, Lets suppose PE1 and PE2 has PW between them. When exchanging PW-FEC, PE2 tells PE1 what PW-Label to use when sending traffic from PE1 to PE2. With QOS, PE2 also tells PE1, what QOS to use when sending traffic from PE1 to PE2. In a traffic engineered mpls core, PE1 would then select a (CAC enabled)transport tunnel (assuming there is more than one) that suits PW's QOS requirement that goes from PE1 to PE2. It is also possible to create and/or adjust transport tunnel aperture that suits PW's QOS requirement. This is the motivation. /himanshu > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Tuesday, February 17, 2004 1:44 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > Folks, > > > QOS stuff of course... :-) > > > > We submitted PWE3 Control protocol extension to > > exchange capabilities as a way to add more stuff > > and to negotiate. I think QOS for PW is important. > > An observation/fact: A PW acts as a client to a server layer > (be it MPLS, IP or whatever) and as a result the QoS that can > be provided by a PW cannot be better than the QoS provided by > the server layer used by the PW. > > My comments: > 1) Assuming that the QoS in the available server layers (e.g > EXP bits/DiffServ for the MPLS/IP server layers) is adequate > (and it could be argued that it isn't) then given that a PW > is basically a MPLS LSP with sequence number support, why > does PW QoS need its own specification? Why can't a PW use > the same QoS mechanisms as MPLS LSPs? > > For example, why would a service provider deploying PWs over > a MPLS core want to use two different but interacting QoS > mechanisms (one for PWs, one for MPLS LSPs) and add > significant additional fault conditions/complexity/opex to > their network when they could use the same QoS mechanism for > both PWs and MPLS? > > 2) Assuming that QoS in the available server layers is not > adequate then seeing as PW QoS is dependant on the server > layer QoS, shouldn't the problem of specifying adequate QoS > in the available server layers be addressed first? Once > there is adequate QoS in the available server layers then > comment (1) above applies. > > So either: > QoS for MPLS is adequate and ergo the problem of QoS for PWs > has already been addressed. > > Or, QoS for MPLS is inadequate and ergo QoS for MPLS should > be addressed first and then the problem of QoS for PWs has > already been addressed. > > Ben > > The above is my personal view and does not necessarily > reflect the opinion of my employer. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? Date: Tue, 17 Feb 2004 14:26:45 -0500 Lines: 73 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Tue Feb 17 20:30:04 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Tuesday, February 17, 2004 1:44 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > Folks, > > > QOS stuff of course... :-) > > > > We submitted PWE3 Control protocol extension to > > exchange capabilities as a way to add more stuff > > and to negotiate. I think QOS for PW is important. > > An observation/fact: A PW acts as a client to a server layer > (be it MPLS, IP or whatever) and as a result the QoS that can > be provided by a PW cannot be better than the QoS provided by > the server layer used by the PW. > > My comments: > 1) Assuming that the QoS in the available server layers (e.g > EXP bits/DiffServ for the MPLS/IP server layers) is adequate > (and it could be argued that it isn't) then given that a PW > is basically a MPLS LSP with sequence number support, why > does PW QoS need its own specification? Why can't a PW use > the same QoS mechanisms as MPLS LSPs? > Benjamin, I think the issue is not that there is a need for a PW specific QoS mechanism. As you observe correctly, QoS guarantees must be given to the PSN tunnel over which the PW rides. The QoS parameters in the PW Control messages serve merely to exchange information between PEs. E.g. suppose PE1 sets up a PW triggered by an event on one of its Attachment Circuits. Based on the nature of the event, PE1 may decide that the underlying PSN Tunnel needs to provide specific QoS guarantees. However, PE2 may not be aware of that, unless it is told by PE1. Hence, the need for QoS parameters in the PW Control messages. Peter > For example, why would a service provider deploying PWs over > a MPLS core want to use two different but interacting QoS > mechanisms (one for PWs, one for MPLS LSPs) and add > significant additional fault conditions/complexity/opex to > their network when they could use the same QoS mechanism for > both PWs and MPLS? > > 2) Assuming that QoS in the available server layers is not > adequate then seeing as PW QoS is dependant on the server > layer QoS, shouldn't the problem of specifying adequate QoS > in the available server layers be addressed first? Once > there is adequate QoS in the available server layers then > comment (1) above applies. > > So either: > QoS for MPLS is adequate and ergo the problem of QoS for PWs > has already been addressed. > > Or, QoS for MPLS is inadequate and ergo QoS for MPLS should > be addressed first and then the problem of QoS for PWs has > already been addressed. > > Ben > > The above is my personal view and does not necessarily > reflect the opinion of my employer. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Danny McPherson Subject: Fwd: 59th IETF - FINAL AGENDA Date: Tue, 17 Feb 2004 14:56:13 -0700 Lines: 255 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Tue Feb 17 22:59:08 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O =09 FYI... We're slotted for Monday morning, 0900-1130. -danny Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: February 17, 2004 1:59:30 PM MST > To: IETF-Announce: ; > Subject: 59th IETF - FINAL AGENDA > > PLEASE NOTE: There are no scheduled IETF activities on Friday, March = 5. > > Agenda of the Fifty-ninth IETF > February 29 - March 4, 2004 > > SUNDAY, February 29, 2004 > 1000-1700 IEPG Meeting - Sapphire 1 > 1200-1900 Registration - 2nd Floor Foyer > 1300-1400 Newcomer's Training (English) - Sapphire 4 > 1400-1500 Newcomer's Training (Korean) - Sapphire 4 > 1300-1500 Editor's Training - Gardenia A-2 > 1300-1500 Intro WG Chairs Training - Astor > 1500-1700 Security Tutorial - Sapphire 4 > 1700-1900 Welcome Reception - Crystal Ballroom > > MONDAY, March 1, 2004 > 0800-2000 IETF Registration - 2nd Floor Foyer > 0800-0900 Continental Breakfast - 2nd Floor Foyer > 0900-1130 Morning Sessions > Sapphire 1 APP apparea Applications Open Area Meeting > Crystal 1/2 INT nemo Network Mobility WG * > Crystal 3 OPS mboned MBONE Deployment WG * > Emerald SEC mobike IKEv2 Mobility and Multihoming WG > Sapphire 2/3 TSV pwe3 Pseudo Wire Emulation Edge to Edge WG > Sapphire 4 TSV sipping Session Initiation Proposal =20 > Investigation WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > Sapphire 2/3 APP iiri Internet Information Retrieval =20 > Infrastructure BOF > Emerald INT mip6 Mobility for IPv6 WG > Crystal 3 OPS dnsop Domain Name System Operations WG * > Sapphire 4 RTG mpls Multiprotocol Label Switching WG > Sapphire 1 SEC pki4ipsec Profiling Use of PKI in IPSEC WG > Crystal 1/2 TSV sip Session Initiation Protocol WG > > 1500-1530 Break (Refreshments provided) - 2nd Floor Foyer > 1530-1730 Afternoon Sessions II > Emerald APP iea Internationalizing Email Address BOF > Sapphire 2/3 INT pana Protocol for Carrying Authentication for = =20 > Network > Access WG > Crystal 1/2 OPS v6ops IPv6 Operations WG * > Crystal 3 RTG idr Inter-Domain Routing WG > Saphire 4 SEC pkix Public-Key Infrastructure (X.509) WG > Sapphire 1 TSV tsvwg Transport Area Working Group > > 1730-1930 Break > 1930-2200 Evening Sessions > Sapphire 4 APP simple SIP for Instant Messaging and Presence =20= > Leveraging > Extensions WG > Crystal 3 GEN genarea General Area Open Meeting * > Sapphire 2/3 INT mip4 Mobility for IPv4 WG > Emerald IRTF hiprr HIP Related Research BOF > Sapphire 1 OPS rmonmib Remote Network Monitoring WG > Crystal 1/2 TSV nsis Next Steps in Signaling WG * > > * Designates Multicast Sessions > > > TUESDAY, March 2, 2004 > 0800-1800 IETF Registration - 2nd Floor Foyer > 0800-0900 Continental Breakfast - 2nd Floor Foyer > 0900-1130 Morning Sessions > Sapphire 1 APP crisp Cross Registry Information Service =20 > Protocol WG > Crystal 3 INT dhc Dynamic Host Configuration WG * > Sapphire 2/3 OPS psamp Packet Sampling WG > Emerald RTG forces Forwarding and Control Element =20 > Separation WG > Sapphire 4 SEC opsec Operational Security Requirements BOF > Crystal 1/2 TSV avt Audio/Video Transport WG * > > 1130-1300 Break > 1300-1400 Afternoon Sessions I > Sapphire 1 APP webdav WWW Distributed Authoring and Versioning = =20 > WG > Emerald INT dna Detecting Network Attachment WG > Crystal 3 OPS dnsop Domain Name System Operations WG * > Sapphire 2/3 RTG manet Mobile Ad-hoc Networks WG > Sapphire 4 SEC openpgp An Open Specification for Pretty Good =20= > Privacy WG > Crystal 1/2 TSV nsis Next Steps in Signaling WG * > > 1415-1515 Afternoon Sessions II > Sapphire 1 APP calsch Calendaring and Scheduling WG > Crystal 1/2 GEN newtrk New IETF Standards Track BOF > Sapphire 4 INT l3vpn Layer 3 Virtual Private Networks WG > Crystal 3 INT magma Multicast and Anycast Group Membership =20= > WG * > Sapphire 2/3 OPS aaa Authentication, Authorization and =20 > Accounting WG > Emerald TSV midcom Middlebox Communication WG > > 1515-1545 Break (Refreshments provided) - 2nd Floor Foyer > 1545-1645 Afternoon Sessions III > Sapphire 1 APP ldapbis LDAP (v3) Revision WG > Crystal 1/2 INT ipv6 IP Version 6 WG * > Crystal 3 OPS opsarea Operations and Management Open Area > Emerald SEC smime S/MIME Mail Security WG > Sapphire 4 TSV iptel IP Telephony WG > Sapphire 2/3 TSV ippm IP Performance Metrics WG > > 1700-1800 Afternoon Sessions IV > Crystal 1/2 INT ipv6 IP Version 6 WG * > Sapphire 2/3 OPS disman Distributed Management WG > Sapphire 4 SEC sasl Simple Authentication and Security Layer = =20 > WG > Emerald TSV rmt Reliable Multicast Transport WG > Sapphire 1 TSV speechsc Speech Services Control WG * > > * Designates Multicast Sessions > > > WEDNESDAY, March 3, 2004 > 0800-1700 IETF Registration - 2nd Floor Foyer > 0800-0900 Continental Breakfast - 2nd Floor Foyer > 0900-1130 Morning Sessions > Crystal 3 APP lemonade Enhancements to Internet email to =20 > Support Diverse > Service Environments WG * > Emerald GEN icar Improved Cross Area Review WG > Sapphire 1 OPS hubmib Ethernet Interfaces and Hub MIB WG > Sapphire 2/3 OPS multi6 Site Multihoming in IPv6 WG > Sapphire 4 TSV enum Telephone Number Mapping WG > Crystal 1/2 TSV mmusic Multiparty Multimedia Session Control WG = =20 > * > > 1130-1300 Break > 1300-1500 Afternoon Sessions I=09 > Sapphire 4 INT l2vpn Layer 2 Virtual Private Network WG > Emerald IRTF mobopts IP Mobility Optimizations > Sapphire 2/3 OPS netconf Network Configuration WG > Sapphire 1 TSV rserpool Reliable Server Pooling WG > Crystal 3 TSV sipping Session Initiation Proposal =20 > Investigation WG > > 1500-1530 Break (Refreshments provided) - 2nd Floor Foyer > 1530-1730 Afternoon Sessions II > Sapphire 4 INT hipbof Host Identity Protocol BOF > Sapphire 2/3 OPS capwap Control and Provisioning of Wireless =20 > Access Points WG > Emerald OPS ipfix IP Flow Information Export WG > Crystal 1/2 RTG rtgarea Routing Area Meeting * > Gardenia A-2 SEC syslog Security Issues in Network Event Logging = =20 > WG > Crystal 3 TSV avt Audio/Video Transport WG * > Sapphire 1 TSV rddp Remote Direct Data Placement WG > > 1730-1930 Break > 1930-2200 Plenary =96 IETF Business Meeting - Crystal Ballroom > > - Welcome, and introduction - Harald Alvestrand > - Welcome from the local hosts > - State of operations: > RFC Editor report > IANA report > IESG operations (Allison Mankin) > - IESG Open Plenary > - Review of Architectural Activities > IAB Chair report > IRTF Chair report > - IAB Open Plenary > > 2230 Late Night Session > Sapphire 1 PGP Key Signing > > * Designates Multicast Sessions > > > THURSDAY, March 4, 2004 > 0800-1700 IETF Registration - 2nd Floor Foyer > 0800-0900 Continental Breakfast - 2nd Floor Foyer > 0900-1130 Morning Sessions=09 > Crystal 3 APP marid MTA Authorization Records in DNS BOF * > Sapphire 2/3 OPS netconf Network Configuration WG > Sapphire 4 RTG ccamp Common Control and Measurement Plane WG > Sapphire 1 SEC krb-wg Kerberos WG > Emerald TSV xcon Centralized Conferencing WG > > 1130-1300 Break > 1300-1500 Afternoon Sessions I > Sapphire 4 INT eap Extensible Authentication Protocol WG > Crystal 3 OPS grow Global Routing Operations WG * > Sapphire 2/3 SEC inch Extended Incident Handling WG > Emerald SEC ltans Long-Term Archive and Notary Services WG > Crystal 1/2 TSV dccp Datagram Congestion Control Protocol WG = * > Sapphire 1 TSV nfsv4 Network File System Version 4 WG > > 1500-1530 Break (Refreshments provided) - 2nd Floor Foyer > 1530-1730 Afternoon Sessions II > Emerald APP geopriv Geographic Location/Privacy WG > Crystal 3 OPS v6ops IPv6 Operations WG * > Sapphire 4 SEC saag Open Security Area Directorate > Sapphire 2/3 TSV pmtud Path MTU Discovery WG > > 1730-1930 Break > 1930-2200 Plenary - IETF Planning Meeting - Crystal Ballroom > > - Welcome, and introduction - Leslie Daigle > - Technical issue: Multihoming, Identifiers and Locations > - IETF Reorg: Status report and discussion - Harald Alvestrand > - IETF AdminRest: Status report and discussion - Leslie Daigle & =20= > Harald Alvestrand > > > * Designates Multicast Sessions > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > =3D > > AREA DIRECTORS > APP Applications Ted Hardie/Qualcomm & Ned Freed/ Sun Microsystems > GEN General Harald Alvestrand/Cisco Systems > INT Internet Thomas Narten/IBM Corp. & Margaret =20 > Wasserman/ThingMagic > OPS Operations & David Kessens/Nokia & Bert Wijnen/Lucent =20 > Technologies > Management > RTG Routing Bill Fenner/AT&T & Alex Zinin/Alcatel > SEC Security Steven Bellovin/AT&T and Russ Housley/Vigil =20 > Security > SUB Sub-IP Area Alex Zinin/Alcatel & Bert Wijnen/Lucent =20 > Technologies > TSV Transport Allison Mankin/Bell Labs, Lucent & Jon =20 > Peterson/NeuStar > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: PWE3 new WG items? Date: Tue, 17 Feb 2004 22:02:57 -0000 Lines: 97 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Tue Feb 17 23:06:05 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 new WG items? Thread-Index: AcP1iz+yUs30OzGjT/uB4yVm+BuBJQAFgYCg To: , X-OriginalArrivalTime: 17 Feb 2004 22:02:58.0223 (UTC) FILETIME=[CD77DBF0:01C3F5A1] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O So what you are proposing is the problem of signalling the QoS = parameters that should be associated with a given PW. As PW signalling = is based on MPLS signalling, I believe that the signalling of QoS = parameters is a generic MPLS problem and not one specific to PWs. In = which case it is a problem that should be addressed by the MPLS WG and = not the PWE WG. Ben -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com] Sent: Tue 17-Feb-04 19:21 To: Niven-Jenkins,B,Ben,XGH5 R; pwe3@ietf.org Cc:=09 Subject: RE: [PWE3] PWE3 new WG items? Hi Ben, Lets suppose PE1 and PE2 has PW between them. When exchanging PW-FEC, PE2 tells PE1 what PW-Label to use when sending traffic from PE1 to PE2. With QOS, PE2 also tells PE1, what QOS to use when sending traffic from PE1 to PE2. In a traffic engineered mpls core, PE1 would then select a (CAC enabled)transport tunnel (assuming there is more than one) that suits PW's QOS=20 requirement that goes from PE1 to PE2. It is also possible to create and/or adjust transport tunnel aperture that suits PW's=20 QOS requirement. This is the motivation. /himanshu > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Tuesday, February 17, 2004 1:44 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? >=20 >=20 > Folks, >=20 > > QOS stuff of course... :-) > >=20 > > We submitted PWE3 Control protocol extension to=20 > > exchange capabilities as a way to add more stuff > > and to negotiate. I think QOS for PW is important. >=20 > An observation/fact: A PW acts as a client to a server layer=20 > (be it MPLS, IP or whatever) and as a result the QoS that can=20 > be provided by a PW cannot be better than the QoS provided by=20 > the server layer used by the PW. >=20 > My comments: > 1) Assuming that the QoS in the available server layers (e.g=20 > EXP bits/DiffServ for the MPLS/IP server layers) is adequate=20 > (and it could be argued that it isn't) then given that a PW=20 > is basically a MPLS LSP with sequence number support, why=20 > does PW QoS need its own specification? Why can't a PW use=20 > the same QoS mechanisms as MPLS LSPs? >=20 > For example, why would a service provider deploying PWs over=20 > a MPLS core want to use two different but interacting QoS=20 > mechanisms (one for PWs, one for MPLS LSPs) and add=20 > significant additional fault conditions/complexity/opex to=20 > their network when they could use the same QoS mechanism for=20 > both PWs and MPLS? >=20 > 2) Assuming that QoS in the available server layers is not=20 > adequate then seeing as PW QoS is dependant on the server=20 > layer QoS, shouldn't the problem of specifying adequate QoS=20 > in the available server layers be addressed first? Once=20 > there is adequate QoS in the available server layers then=20 > comment (1) above applies. >=20 > So either: > QoS for MPLS is adequate and ergo the problem of QoS for PWs=20 > has already been addressed. >=20 > Or, QoS for MPLS is inadequate and ergo QoS for MPLS should=20 > be addressed first and then the problem of QoS for PWs has=20 > already been addressed. >=20 > Ben >=20 > The above is my personal view and does not necessarily=20 > reflect the opinion of my employer. >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? Date: Tue, 17 Feb 2004 17:18:14 -0500 Lines: 116 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-From: pwe3-admin@ietf.org Tue Feb 17 23:21:07 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Signaling of the QOS parameters that is specific to a given PW-FEC falls within the charter of PWE3 as it is an attribute of a PW-FEC. This is my understanding. /himanshu > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Tuesday, February 17, 2004 5:03 PM > To: Shah, Himanshu; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > > So what you are proposing is the problem of signalling the > QoS parameters that should be associated with a given PW. As > PW signalling is based on MPLS signalling, I believe that the > signalling of QoS parameters is a generic MPLS problem and > not one specific to PWs. In which case it is a problem that > should be addressed by the MPLS WG and not the PWE WG. > > Ben > > -----Original Message----- > From: Shah, Himanshu [mailto:hshah@ciena.com] > Sent: Tue 17-Feb-04 19:21 > To: Niven-Jenkins,B,Ben,XGH5 R; pwe3@ietf.org > Cc: > Subject: RE: [PWE3] PWE3 new WG items? > Hi Ben, > > Lets suppose PE1 and PE2 has PW between them. > When exchanging PW-FEC, PE2 tells PE1 what PW-Label > to use when sending traffic from PE1 to PE2. > > With QOS, PE2 also tells PE1, what QOS to use when > sending traffic from PE1 to PE2. In a traffic engineered > mpls core, PE1 would then select a (CAC enabled)transport tunnel > (assuming there is more than one) that suits PW's QOS > requirement that goes from PE1 to PE2. It is also possible to > create and/or adjust transport tunnel aperture that suits PW's > QOS requirement. > > This is the motivation. > > /himanshu > > > > > -----Original Message----- > > From: benjamin.niven-jenkins@bt.com > > [mailto:benjamin.niven-jenkins@bt.com] > > Sent: Tuesday, February 17, 2004 1:44 PM > > To: pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 new WG items? > > > > > > Folks, > > > > > QOS stuff of course... :-) > > > > > > We submitted PWE3 Control protocol extension to > > > exchange capabilities as a way to add more stuff > > > and to negotiate. I think QOS for PW is important. > > > > An observation/fact: A PW acts as a client to a server layer > > (be it MPLS, IP or whatever) and as a result the QoS that can > > be provided by a PW cannot be better than the QoS provided by > > the server layer used by the PW. > > > > My comments: > > 1) Assuming that the QoS in the available server layers (e.g > > EXP bits/DiffServ for the MPLS/IP server layers) is adequate > > (and it could be argued that it isn't) then given that a PW > > is basically a MPLS LSP with sequence number support, why > > does PW QoS need its own specification? Why can't a PW use > > the same QoS mechanisms as MPLS LSPs? > > > > For example, why would a service provider deploying PWs over > > a MPLS core want to use two different but interacting QoS > > mechanisms (one for PWs, one for MPLS LSPs) and add > > significant additional fault conditions/complexity/opex to > > their network when they could use the same QoS mechanism for > > both PWs and MPLS? > > > > 2) Assuming that QoS in the available server layers is not > > adequate then seeing as PW QoS is dependant on the server > > layer QoS, shouldn't the problem of specifying adequate QoS > > in the available server layers be addressed first? Once > > there is adequate QoS in the available server layers then > > comment (1) above applies. > > > > So either: > > QoS for MPLS is adequate and ergo the problem of QoS for PWs > > has already been addressed. > > > > Or, QoS for MPLS is inadequate and ergo QoS for MPLS should > > be addressed first and then the problem of QoS for PWs has > > already been addressed. > > > > Ben > > > > The above is my personal view and does not necessarily > > reflect the opinion of my employer. > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? Date: Tue, 17 Feb 2004 17:31:19 -0500 Lines: 131 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" X-From: pwe3-admin@ietf.org Tue Feb 17 23:34:05 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O more correctly - "... attribute of an (egress) AC" > -----Original Message----- > From: Shah, Himanshu > Sent: Tuesday, February 17, 2004 5:18 PM > To: 'benjamin.niven-jenkins@bt.com'; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > Signaling of the QOS parameters that is specific to > a given PW-FEC falls within the charter of PWE3 as > it is an attribute of a PW-FEC. > > This is my understanding. > > /himanshu > > > -----Original Message----- > > From: benjamin.niven-jenkins@bt.com > > [mailto:benjamin.niven-jenkins@bt.com] > > Sent: Tuesday, February 17, 2004 5:03 PM > > To: Shah, Himanshu; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 new WG items? > > > > > > > > So what you are proposing is the problem of signalling the > > QoS parameters that should be associated with a given PW. As > > PW signalling is based on MPLS signalling, I believe that the > > signalling of QoS parameters is a generic MPLS problem and > > not one specific to PWs. In which case it is a problem that > > should be addressed by the MPLS WG and not the PWE WG. > > > > Ben > > > > -----Original Message----- > > From: Shah, Himanshu [mailto:hshah@ciena.com] > > Sent: Tue 17-Feb-04 19:21 > > To: Niven-Jenkins,B,Ben,XGH5 R; pwe3@ietf.org > > Cc: > > Subject: RE: [PWE3] PWE3 new WG items? > > Hi Ben, > > > > Lets suppose PE1 and PE2 has PW between them. > > When exchanging PW-FEC, PE2 tells PE1 what PW-Label > > to use when sending traffic from PE1 to PE2. > > > > With QOS, PE2 also tells PE1, what QOS to use when > > sending traffic from PE1 to PE2. In a traffic engineered > > mpls core, PE1 would then select a (CAC enabled)transport tunnel > > (assuming there is more than one) that suits PW's QOS > > requirement that goes from PE1 to PE2. It is also possible to > > create and/or adjust transport tunnel aperture that suits PW's > > QOS requirement. > > > > This is the motivation. > > > > /himanshu > > > > > > > > > -----Original Message----- > > > From: benjamin.niven-jenkins@bt.com > > > [mailto:benjamin.niven-jenkins@bt.com] > > > Sent: Tuesday, February 17, 2004 1:44 PM > > > To: pwe3@ietf.org > > > Subject: RE: [PWE3] PWE3 new WG items? > > > > > > > > > Folks, > > > > > > > QOS stuff of course... :-) > > > > > > > > We submitted PWE3 Control protocol extension to > > > > exchange capabilities as a way to add more stuff > > > > and to negotiate. I think QOS for PW is important. > > > > > > An observation/fact: A PW acts as a client to a server layer > > > (be it MPLS, IP or whatever) and as a result the QoS that can > > > be provided by a PW cannot be better than the QoS provided by > > > the server layer used by the PW. > > > > > > My comments: > > > 1) Assuming that the QoS in the available server layers (e.g > > > EXP bits/DiffServ for the MPLS/IP server layers) is adequate > > > (and it could be argued that it isn't) then given that a PW > > > is basically a MPLS LSP with sequence number support, why > > > does PW QoS need its own specification? Why can't a PW use > > > the same QoS mechanisms as MPLS LSPs? > > > > > > For example, why would a service provider deploying PWs over > > > a MPLS core want to use two different but interacting QoS > > > mechanisms (one for PWs, one for MPLS LSPs) and add > > > significant additional fault conditions/complexity/opex to > > > their network when they could use the same QoS mechanism for > > > both PWs and MPLS? > > > > > > 2) Assuming that QoS in the available server layers is not > > > adequate then seeing as PW QoS is dependant on the server > > > layer QoS, shouldn't the problem of specifying adequate QoS > > > in the available server layers be addressed first? Once > > > there is adequate QoS in the available server layers then > > > comment (1) above applies. > > > > > > So either: > > > QoS for MPLS is adequate and ergo the problem of QoS for PWs > > > has already been addressed. > > > > > > Or, QoS for MPLS is inadequate and ergo QoS for MPLS should > > > be addressed first and then the problem of QoS for PWs has > > > already been addressed. > > > > > > Ben > > > > > > The above is my personal view and does not necessarily > > > reflect the opinion of my employer. > > > > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 14:38:29 -0000 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Feb 18 15:41:11 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 new WG items? Thread-Index: AcP1o/Gv2avkJrFvTbOjWsEDzxQNKgAhgYfw To: , X-OriginalArrivalTime: 18 Feb 2004 14:38:30.0129 (UTC) FILETIME=[E0756610:01C3F62C] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Signaling of the QOS parameters that is specific to=20 > a given PW-FEC falls within the charter of PWE3 as > it is an attribute of a PW-FEC. >=20 > This is my understanding. Well, I would say that as: 1) PWs are basically LSPs (and therefore they inherit all the properties = of a LSP and add their own PW specific properties) 2) PW signalling is an extension to LSP signalling (and therefore it = inherits all the properties of LSP signalling and adds its own PW = specific properties) The problem of signalling QoS parameters is not a PW specific problem = and therefore should not be addressed by the PWE3 WG. If the QoS signalling mechanisms that exist already (e.g. CR-LDP) are = adequate then why not re-use them for PWs because PWs should = automatically inherit any traffic parameters signalled at the same time = as the PW-FEC? If the existing QoS signalling mechanisms are not = adequate then fix them but in such a way that they can be used for MPLS = LSPs and PWs. IMO defining PW specific QoS signalling just limits the amount of = functional convergence/re-use that can be achieved and therefore = increases the complexity of any solution (and by implication increases = the opex for any service provider wishing to deploy that solution). Unfortunately CR-LDP has been deprecated so the opportunities for = functional convergence/re-use are more limited and it looks like = re-inventing the wheel[1] is one possible (although I would consider it = to be an undesirable) solution :-( Ben [1] either the PW signalling wheel (e.g. add PW signalling to RSVP-TE) = or the LDP QoS wheel (e.g. add QoS signalling to LDP). From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 10:02:48 -0500 Lines: 64 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Feb 18 16:06:21 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" , hshah@ciena.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ben, I agree that the PWE3 WG could have decided to treat PWs as LSPs (which currently is not true) and to use RSVP as the protocol for PW set up. I have argued on this mailing list that that would have been a better approach, e.g. because it would provide a solution for the creation of multi-hop PWs, preferable to the splicing approach that is now on the table. Similarly, RSVP would provide an immediate solution for signaling QoS parameters. I am in favor of adopting RSVP as a valid protocol for PW set up. However, as long as that is not accepted by the WG, there is a need to address QoS for PWs in a different way. You can call it re-inventing the wheel, but it needs to be done. Peter > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Wednesday, February 18, 2004 9:38 AM > To: hshah@ciena.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > > Signaling of the QOS parameters that is specific to > > a given PW-FEC falls within the charter of PWE3 as > > it is an attribute of a PW-FEC. > > > > This is my understanding. > > Well, I would say that as: > > 1) PWs are basically LSPs (and therefore they inherit all the > properties of a LSP and add their own PW specific properties) > > 2) PW signalling is an extension to LSP signalling (and > therefore it inherits all the properties of LSP signalling > and adds its own PW specific properties) > > The problem of signalling QoS parameters is not a PW specific > problem and therefore should not be addressed by the PWE3 WG. > > If the QoS signalling mechanisms that exist already (e.g. > CR-LDP) are adequate then why not re-use them for PWs because > PWs should automatically inherit any traffic parameters > signalled at the same time as the PW-FEC? If the existing > QoS signalling mechanisms are not adequate then fix them but > in such a way that they can be used for MPLS LSPs and PWs. > > IMO defining PW specific QoS signalling just limits the > amount of functional convergence/re-use that can be achieved > and therefore increases the complexity of any solution (and > by implication increases the opex for any service provider > wishing to deploy that solution). > > Unfortunately CR-LDP has been deprecated so the opportunities > for functional convergence/re-use are more limited and it > looks like re-inventing the wheel[1] is one possible > (although I would consider it to be an undesirable) solution :-( > > Ben > > [1] either the PW signalling wheel (e.g. add PW signalling to > RSVP-TE) or the LDP QoS wheel (e.g. add QoS signalling to LDP). > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 10:14:13 -0500 Lines: 96 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Feb 18 16:17:17 2004 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'benjamin.niven-jenkins@bt.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ditto. Understand your concern but like Peter says we can not scrap everything and start from the scratch. /himanshu > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Wednesday, February 18, 2004 10:03 AM > To: 'benjamin.niven-jenkins@bt.com'; Shah, Himanshu; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > Ben, > > I agree that the PWE3 WG could have decided to treat PWs as > LSPs (which currently is not true) and to use RSVP as the > protocol for PW set up. I have argued on this mailing list > that that would have been a better approach, e.g. because it > would provide a solution for the creation of multi-hop PWs, > preferable to the splicing approach that is now on the table. > Similarly, RSVP would provide an immediate solution for > signaling QoS parameters. > > I am in favor of adopting RSVP as a valid protocol for PW set > up. However, as long as that is not accepted by the WG, there > is a need to address QoS for PWs in a different way. You can > call it re-inventing the wheel, but it needs to be done. > > Peter > > > -----Original Message----- > > From: benjamin.niven-jenkins@bt.com > > [mailto:benjamin.niven-jenkins@bt.com] > > Sent: Wednesday, February 18, 2004 9:38 AM > > To: hshah@ciena.com; pwe3@ietf.org > > Subject: RE: [PWE3] PWE3 new WG items? > > > > > > > Signaling of the QOS parameters that is specific to > > > a given PW-FEC falls within the charter of PWE3 as > > > it is an attribute of a PW-FEC. > > > > > > This is my understanding. > > > > Well, I would say that as: > > > > 1) PWs are basically LSPs (and therefore they inherit all the > > properties of a LSP and add their own PW specific properties) > > > > 2) PW signalling is an extension to LSP signalling (and > > therefore it inherits all the properties of LSP signalling > > and adds its own PW specific properties) > > > > The problem of signalling QoS parameters is not a PW specific > > problem and therefore should not be addressed by the PWE3 WG. > > > > If the QoS signalling mechanisms that exist already (e.g. > > CR-LDP) are adequate then why not re-use them for PWs because > > PWs should automatically inherit any traffic parameters > > signalled at the same time as the PW-FEC? If the existing > > QoS signalling mechanisms are not adequate then fix them but > > in such a way that they can be used for MPLS LSPs and PWs. > > > > IMO defining PW specific QoS signalling just limits the > > amount of functional convergence/re-use that can be achieved > > and therefore increases the complexity of any solution (and > > by implication increases the opex for any service provider > > wishing to deploy that solution). > > > > Unfortunately CR-LDP has been deprecated so the opportunities > > for functional convergence/re-use are more limited and it > > looks like re-inventing the wheel[1] is one possible > > (although I would consider it to be an undesirable) solution :-( > > > > Ben > > > > [1] either the PW signalling wheel (e.g. add PW signalling to > > RSVP-TE) or the LDP QoS wheel (e.g. add QoS signalling to LDP). > > > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 15:23:15 -0000 Lines: 31 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Feb 18 16:29:56 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 new WG items? Thread-Index: AcP2MFAq2RGVl4svQ+acRqqusQEI3wAAI/6Q To: X-OriginalArrivalTime: 18 Feb 2004 15:23:15.0461 (UTC) FILETIME=[210A8B50:01C3F633] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, > I agree that the PWE3 WG could have decided to treat PWs as=20 > LSPs (which currently is not true) and to use RSVP as the=20 > protocol for PW set up. The PWE3 WG may have decided not to treat PWs as LSPs but it doesn't = (IMO) avoid the fact that a PW *always* uses a LSP for transport. AIUI = a PW consists of two parts: 1) An adaptation function that describes how to encapsulate a client = layer (e.g. Ethernet) onto a server layer (e.g. MPLS). This is defined = by the PWE WG. 2) A LSP (let's call it the 'PW LSP') that transports the above = adaptation function (and its client payload) across a network. This is = defined by the MPLS WG with some PW specific extensions (e.g. PW FEC) For scalability etc. a second LSP (let's call it the 'transport LSP') is = also used and a 2 level LSP hierarchy/stack is created with the inner = LSP being the 'PW LSP' (which is a single hop) and the outer LSP being = the 'transport LSP'. Now my argument is that any QoS parameters associated with a PW are in = actual fact associated with the 'PW LSP' and not the adaptation = function. Therefore any QoS parameters/signalling that are associated = with a PW are in actual fact associated with the 'PW LSP'. Therefore I believe that the signalling of PW QoS parameters is the same = problem as the signalling of LSP QoS parameters and therefore does not = fall under the PWE3 WG. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 15:38:56 -0000 Lines: 34 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Feb 18 16:42:26 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 new WG items? Thread-Index: AcP2MfX/V9Ak0UjMQ0ukDDrqGd8tEgAAXdeQ To: , , X-OriginalArrivalTime: 18 Feb 2004 15:38:57.0303 (UTC) FILETIME=[526C3A70:01C3F635] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Understand your concern but like Peter says > we can not scrap everything and start > from the scratch. Which is better: 1) To admit a mistake may have been made and attempt to resolve it. 2) To refuse to admit a mistake may have been made and attempt to work = around it whilst adding extra complexity/opex in the process. I'm not suggesting people start over (although that is obviously one = possible approach), however as I see it: 1) The problem of signalling PW QoS is actually the more general problem = of signalling MPLS LSP QoS and therefore comes under the remit of the = MPLS WG. 2) The MPLS WG has already looked at constraint based LSP setup (with = QoS being one posslbe constraint) and developed CR-LDP and RSVP-TE as a = result.=20 Therefore IMO the signalling of PW QoS has one of two solutions: 1) Add PW signalling to CR-LDP (although this would be the easiest = solution, CR-LDP has been deprecated). 2) Add PW signalling to RSVP-TE. Neither of which require PW specific QoS signalling mechanism because = adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or RSVP-TE) = is not necessary IMO and would only lead to increased complexity/opex. Ben From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: PWE3 new WG items? Date: Wed, 18 Feb 2004 10:50:03 -0500 Lines: 16 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 18 16:53:03 2004 Return-path: To: benjamin.niven-jenkins@bt.com In-reply-to: Your message of Wed, 18 Feb 2004 15:23:15 +0000. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > a PW *always* uses a LSP for transport No it doesn't. But I think that's irrelevant anyway. I think that all you're really saying is that the QoS belongs to the transport (the enclosing LSP or the L2TPv3 session), not to the PW. (Of course, it's hard to see through the gibberish of buzz words.) The opposite point of view is that you need to know the PW QoS in order to select a transport LSP or L2TPv3 session properly, one endpoint might want to signal this to the other, and the PW QoS might even impact (or be impacted by) some characteristic of the AC. I think this is what Himanshu was saying, and prima facie it seems right to me. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 15:59:08 -0000 Lines: 24 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Feb 18 17:02:01 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 new WG items? Thread-Index: AcP2NuMCVcf7c2gvTzCtEAEsAjvK0QAAKo7g To: X-OriginalArrivalTime: 18 Feb 2004 15:59:08.0897 (UTC) FILETIME=[2496CD10:01C3F638] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I think that all you're really saying is that the QoS =20 > belongs to the > transport (the enclosing LSP or the L2TPv3 session), not=20 > to the PW. (Of > course, it's hard to see through the gibberish of buzz words.)=20 >=20 > The opposite point of view is that you need to know the PW=20 > QoS in order to > select a transport LSP or L2TPv3 session properly, one=20 > endpoint might want > to signal this to the other, and the PW QoS might even =20 > impact (or be > impacted by) some characteristic of the AC. I think this=20 > is what Himanshu > was saying, and prima facie it seems right to me. =20 I agree that you need to know the QoS a PW requires in order to = associate it with a transport LSP etc. However as PW signalling is = basically piggybacked onto LSP signalling what is the motivation for a = PW specific QoS signalling mechanism (as suggested by Himanshu) when LSP = QoS signalling mechanisms already exist? Ben From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: PWE3 new WG items? Date: Wed, 18 Feb 2004 11:22:56 -0500 Lines: 10 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 18 17:26:06 2004 Return-path: To: benjamin.niven-jenkins@bt.com In-reply-to: Your message of Wed, 18 Feb 2004 15:59:08 +0000. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > what is the motivation for a PW specific QoS signalling mechanism (as > suggested by Himanshu) when LSP QoS signalling mechanisms already exist? Obviously the appropriate mechanisms do not already exist. Once we see a proposal, we'll be able to judge whether it has more general applicability to MPLS than just PWs. It's possible that it will (in which case the MPLS WG may need to get involved), but it's also possible that it won't. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 17:40:11 +0200 Lines: 85 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 18 18:50:06 2004 Return-path: To: "'benjamin.niven-jenkins@bt.com'" X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ben and all, You may argue that the transport LSP is added for scalability reasons. However, you seem to ignore two facts: 1. The PW LSP is *always* a one-hop LSP, so that its label is understood only buy the receiving PE but not by any intermediate LSR. 2. As a consequence, in a (common) case where the transport LSP exists the QoS parameters associated with its specific PW clients MUST be reflected in the transport label stack entries (since only these are processed by the intermediate LSRs). This means that the QoS problem for MPLS PWs is real: e.g., if your PW assumes a certain set of QoS parameters which cannot be supported by the given transport LSP between the pair of the PEs, the PW setup SHOULD either fail or result in setup of a new transport LSP which then would be used by the PW. (Of course this is exactly what Himanshu and Peter say, even if the wording is different:-). With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: benjamin.niven-jenkins@bt.com > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Wednesday, February 18, 2004 5:23 PM > To: pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > Peter, > > > I agree that the PWE3 WG could have decided to treat PWs as > > LSPs (which currently is not true) and to use RSVP as the > > protocol for PW set up. > > The PWE3 WG may have decided not to treat PWs as LSPs but it > doesn't (IMO) avoid the fact that a PW *always* uses a LSP > for transport. AIUI a PW consists of two parts: > > 1) An adaptation function that describes how to encapsulate a > client layer (e.g. Ethernet) onto a server layer (e.g. MPLS). > This is defined by the PWE WG. > > 2) A LSP (let's call it the 'PW LSP') that transports the > above adaptation function (and its client payload) across a > network. This is defined by the MPLS WG with some PW > specific extensions (e.g. PW FEC) > > For scalability etc. a second LSP (let's call it the > 'transport LSP') is also used and a 2 level LSP > hierarchy/stack is created with the inner LSP being the 'PW > LSP' (which is a single hop) and the outer LSP being the > 'transport LSP'. > > Now my argument is that any QoS parameters associated with a > PW are in actual fact associated with the 'PW LSP' and not > the adaptation function. Therefore any QoS > parameters/signalling that are associated with a PW are in > actual fact associated with the 'PW LSP'. > > Therefore I believe that the signalling of PW QoS parameters > is the same problem as the signalling of LSP QoS parameters > and therefore does not fall under the PWE3 WG. > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Nick DelRegno Subject: Re: PWE3 new WG items? Date: Wed, 18 Feb 2004 17:08:52 -0600 Lines: 20 Sender: pwe3-admin@ietf.org References: <200402181622.i1IGMu0K010172@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-From: pwe3-admin@ietf.org Thu Feb 19 00:12:03 2004 Return-path: In-reply-to: <200402181622.i1IGMu0K010172@rtp-core-2.cisco.com> X-Sender: nick.delregno@mci.com@pop.mcilink.com To: pwe3@ietf.org X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 References: <200402181622.i1IGMu0K010172@rtp-core-2.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O A means of signaling/negotiating the QOS associated with a PW would be beneficial. And doable. We have seen implementations that already support two levels of QOS: one aggregate QOS for the PSN tunnel (usually a LSP) and discrete QOS for constituent PW Virtual Circuits. I like this model. Any transit LSRs in the LSP path with provide QOS on the aggregate LSP only, ensuring that the PSN tunnel has the proscribed bandwidth. The PW QOS negotiation would be used at the PE function (traditionally at each end of the PW). However, as we find new ways to apply these tools, the ability to signal the VC QOS and bandwidth becomes very interesting. At some point, when we have multi-hop PWs (through stitching or other mechanisms) signaling the PW QOS instead of manually provisioning it would be helpful. Whether we use CR-LDP, RSVP-TE or PW-specific extensions of "draft-ietf-pwe3-control-protocol-xx.txt" is immaterial at this point. I agree that this should be a PWE3 WG item, as well as PW stitching and hierarchy. Nick From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 18:41:35 -0800 (PST) Lines: 43 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: hshah@ciena.com, "" , "" X-From: pwe3-admin@ietf.org Thu Feb 19 03:45:08 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: benjamin.niven-jenkins@bt.com In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Ben, [snip] > > Therefore IMO the signalling of PW QoS has one of two solutions: > > 1) Add PW signalling to CR-LDP (although this would be the easiest solution, CR-LDP has been deprecated). > > 2) Add PW signalling to RSVP-TE. > For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup: - LDP - RSVP-TE Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement. There is no reason why PWE setup cannot follow a similar model: - LDP for PW signaling without QoS - RSVP-TE for PW signaling with QoS rahul > Neither of which require PW specific QoS signalling mechanism because > adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or RSVP-TE) > is not necessary IMO and would only lead to increased complexity/opex. > > > Ben > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Cui, Yongxin (Yongxin)" Subject: RE: PWE3 new WG items? Date: Wed, 18 Feb 2004 21:53:39 -0500 Lines: 65 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: hshah@ciena.com, "Busschbach, Peter B (Peter)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 03:56:03 2004 Return-path: To: Rahul Aggarwal , benjamin.niven-jenkins@bt.com X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Rahul, If the PW has the QoS requirement and needs to reserve resources inside the PSN tunnel, can LDP help? In particular, when the PW is carrying ATM traffic, how does the LDP with CR work? For example, I have a PSN tunnel with 10Mbps bandwidth configured. Inside the tunnel, I have two PWs, each booking 2Mbps bandwidth. Thanks, Yongxin -----Original Message----- From: Rahul Aggarwal [mailto:rahul@juniper.net] Sent: Thursday, February 19, 2004 10:42 AM To: benjamin.niven-jenkins@bt.com Cc: hshah@ciena.com; busschbach@lucent.com; pwe3@ietf.org Subject: RE: [PWE3] PWE3 new WG items? Hi Ben, [snip] > > Therefore IMO the signalling of PW QoS has one of two solutions: > > 1) Add PW signalling to CR-LDP (although this would be the easiest > solution, CR-LDP has been deprecated). > > 2) Add PW signalling to RSVP-TE. > For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup: - LDP - RSVP-TE Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement. There is no reason why PWE setup cannot follow a similar model: - LDP for PW signaling without QoS - RSVP-TE for PW signaling with QoS rahul > Neither of which require PW specific QoS signalling mechanism because > adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or > RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex. > > > Ben > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: PWE3 new WG items? Date: Thu, 19 Feb 2004 07:31:06 +0200 Lines: 58 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Thu Feb 19 06:35:07 2004 Return-path: To: "'Nick DelRegno'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Nick and all, I also think that PW stitching (a.k.a splicing) and QoS are relevant new WG items. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) > -----Original Message----- > From: Nick DelRegno [mailto:nick.delregno@mci.com] > Sent: Thursday, February 19, 2004 1:09 AM > To: pwe3@ietf.org > Subject: Re: [PWE3] PWE3 new WG items? > > > > A means of signaling/negotiating the QOS associated with a PW > would be > beneficial. And doable. We have seen implementations that > already support > two levels of QOS: one aggregate QOS for the PSN tunnel > (usually a LSP) and > discrete QOS for constituent PW Virtual Circuits. I like this model. > > Any transit LSRs in the LSP path with provide QOS on the > aggregate LSP > only, ensuring that the PSN tunnel has the proscribed > bandwidth. The PW > QOS negotiation would be used at the PE function > (traditionally at each end > of the PW). However, as we find new ways to apply these > tools, the ability > to signal the VC QOS and bandwidth becomes very interesting. At some > point, when we have multi-hop PWs (through stitching or other > mechanisms) > signaling the PW QOS instead of manually provisioning it > would be helpful. > > Whether we use CR-LDP, RSVP-TE or PW-specific extensions of > "draft-ietf-pwe3-control-protocol-xx.txt" is immaterial at > this point. I > agree that this should be a PWE3 WG item, as well as PW stitching and > hierarchy. > > Nick > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: RE: PWE3 new WG items? Date: Thu, 19 Feb 2004 09:09:06 +0200 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Thu Feb 19 08:12:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] PWE3 new WG items? Thread-Index: AcP2knNBtG5StXfISfKtQlNZgdxLjQAJGNNg To: Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O =20 > There is no reason why PWE setup cannot follow a similar model: > - LDP for PW signaling without QoS > - RSVP-TE for PW signaling with QoS I agree that we need two models. But we are not always over MPLS. Are we going to use RSVP in the pure IP case? or is QoS only for MPLS infrastructure? Y(J)S From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ping Pan Subject: Re: PWE3 new WG items? Date: Thu, 19 Feb 2004 00:30:17 -0800 Lines: 27 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hshah@ciena.com, busschbach@lucent.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 09:32:12 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: benjamin.niven-jenkins@bt.com In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ben, You first said, > I'm not suggesting people start over (although that is obviously one possible approach), however as I see it: > ... Then you added, > Therefore IMO the signalling of PW QoS has one of two solutions: > > 1) Add PW signalling to CR-LDP (although this would be the easiest solution, CR-LDP has been deprecated). > > 2) Add PW signalling to RSVP-TE. > But to support either of your solutions in (1) and (2) means starting over. No? I thought the problem is pretty straightforward: we have tunnel that may be used to pass one or multiple PW's. Each PW requires some traffic conditioning at ingress and egress. So we exchange the CoS/QoS/token bucket/... information between two ends for each PW within the framework of PWE3. - Ping From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: TDM and SAToP MIBs Date: Thu, 19 Feb 2004 13:30:11 +0200 Lines: 77 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F6DB.BC6F7232" X-From: pwe3-admin@ietf.org Thu Feb 19 12:33:05 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: TDM and SAToP MIBs Thread-Index: AcP227wkb4GrLCCgS9q/Jeewa3Gd6Q== To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F6DB.BC6F7232 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone,=20 Although submitted well in advance of the cutoff date, for some reason these MIB drafts have not yet appeared on the IETF site. In the meantime you can find them at http://www.dspcsp.com/tdmoip/draft-orly-pwe3-TDM-mib-00.txt and http://www.dspcsp.com/tdmoip/draft-orly-pwe3-satop-mib-00.txt . Y(J)S ------_=_NextPart_001_01C3F6DB.BC6F7232 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable TDM and SAToP MIBs

Hi = everyone,

Although = submitted well in advance of the cutoff date,

for some = reason these MIB drafts have not yet appeared

on the = IETF site.

In the = meantime you can find them at

http://www.dspcsp.com/tdmoip/draft-orly-pwe3-TDM-mib-00.tx= t

and

http://www.dspcsp.com/tdmoip/draft-orly-pwe3-satop-mib-00.= txt .

Y(J)S

------_=_NextPart_001_01C3F6DB.BC6F7232-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Proch, Daniel" Subject: RE: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 09:20:54 -0500 Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: hshah@ciena.com, busschbach@lucent.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 15:24:04 2004 Return-path: To: "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O >>For the purpose of PW QoS, this is reasonable. Note that the >>MPLS WG has 2 defined mechanisms for transport LSP setup: >> - LDP >> - RSVP-TE >> >>Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the >>other hand is deemed easier to configure and manage when TE is not a >>requirement. >> >>There is no reason why PWE setup cannot follow a similar model: >> - LDP for PW signaling without QoS >> - RSVP-TE for PW signaling with QoS >> >>rahul >> >> dan - Maybe I misunderstand the problem, but it seems that RSVP-TE is not necessary. Signaling PW QoS is separate from PSN tunnel QoS. The problem that I see is how to inform the other side of a pseudo wire what QoS considerations should be taken the connection. It is an implementation specific task for the PE router to determine how to multiplex the PW into a PSN tunnel based on the requested QoS. LDP already exists for PW label distribution and the any LDP conversation is targeted to the directly to the other PE router (invisible to core). Therefore LDP can be extended to add QoS signaling for the PW as is. If RSVP-TE was already used for PW setup, I'd agree that it could also be used to signal QoS, but absent that, why would it be used in this application? For example, in the ATM Forum ATM/MPLS interworking specs PNNI is used for PW label distribution for ATM VCs and therefore PW QoS is supported as is. dan proch From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 09:35:03 -0500 Lines: 64 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: hshah@ciena.com, "Busschbach, Peter B (Peter)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 15:38:05 2004 Return-path: To: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Proch, Daniel [mailto:Daniel.Proch@marconi.com] > Sent: Thursday, February 19, 2004 9:21 AM > To: 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com > Cc: hshah@ciena.com; busschbach@lucent.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? PW QoS > > > >>For the purpose of PW QoS, this is reasonable. Note that the > >>MPLS WG has 2 defined mechanisms for transport LSP setup: > >> - LDP > >> - RSVP-TE > >> > >>Of these RSVP-TE is used primarily for QoS/TE and Fast > Reroute. LDP on the > >>other hand is deemed easier to configure and manage when TE is not a > >>requirement. > >> > >>There is no reason why PWE setup cannot follow a similar model: > >> - LDP for PW signaling without QoS > >> - RSVP-TE for PW signaling with QoS > >> > >>rahul > >> > >> > > dan - > Maybe I misunderstand the problem, but it seems that RSVP-TE is not > necessary. Signaling PW QoS is separate from PSN tunnel QoS. > The problem > that I see is how to inform the other side of a pseudo wire what QoS > considerations should be taken the connection. It is an > implementation > specific task for the PE router to determine how to multiplex > the PW into a > PSN tunnel based on the requested QoS. > > LDP already exists for PW label distribution and the any LDP > conversation is > targeted to the directly to the other PE router (invisible to core). > Therefore LDP can be extended to add QoS signaling for the PW as is. > I would agree that if QoS were the only problem that needs to be solved it could be acceptable to carry QoS information in the LDP messages that are used for PW setup (albeit that it is somewhat ugly since it makes LDP look like CR-LDP which has been depreciated). However, there are other issues that need to be solved. Several people on this mailing list suggested that we need to address PW stitching. It seems to me that stitching of PWs requires a signaling protocol that establishes a multi-hop PW through switches that switch based on the PW label. RSVP is in my view the only reasonable solution. Hence, if we don't look at one problem at a time, but at the entire problem space, I think we need to adopt RSVP as a way to establish PWs. It would solve the problems of both QoS and stitching. Peter > If RSVP-TE was already used for PW setup, I'd agree that it > could also be > used to signal QoS, but absent that, why would it be used in this > application? For example, in the ATM Forum ATM/MPLS > interworking specs PNNI > is used for PW label distribution for ATM VCs and therefore PW QoS is > supported as is. > > dan proch > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: Re: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 08:50:57 -0700 Lines: 33 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 16:27:06 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6a) Gecko/20031029 X-Accept-Language: Italian [it],French/Canada [fr-CA],French/France [fr-FR],English/United States [en-US] To: "Busschbach, Peter B (Peter)" In-Reply-To: X-PMX-Version: 4.1.1.86173 X-from-outside-Cisco: [161.44.70.232] Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: [snip] >I would agree that if QoS were the only problem that needs to be solved it could be acceptable to carry QoS information in the LDP messages that are used for PW setup (albeit that it is somewhat ugly since it makes LDP look like CR-LDP which has been depreciated). > >However, there are other issues that need to be solved. Several people on this mailing list suggested that we need to address PW stitching. It seems to me that stitching of PWs requires a signaling protocol that establishes a multi-hop PW through switches that switch based on the PW label. RSVP is in my view the only reasonable solution. > >Hence, if we don't look at one problem at a time, but at the entire problem space, I think we need to adopt RSVP as a way to establish PWs. It would solve the problems of both QoS and stitching. > >Peter > > > Peter, It is possible ( I already know of one implementation ) to select an RSVP LSP to transport a single PW. That does not change the protocol , and does carry QoS information needed by the PSN. It also achieves another property that as it turns out is quite useful in practice: explicit routing of the PW across the PSN. ( this is for TE , but also other reasons like avoiding shared PSN failure modes ) Luca > >_______________________________________________ >pwe3 mailing list >pwe3@ietf.org >https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 10:52:56 -0500 Lines: 75 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 16:55:08 2004 Return-path: To: "'Luca Martini'" , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O If one was to map one PW per transport LSP, one does not need RSVP signaling for PW QOS....:-) I remember a debate at IETF where a group of people were concerned about scaling of RSVP's use for LSP signaling. Well, PWs are multi magnitude higher order than transport LSPs. Also, isn't direction an issue? Target PE (tail end) tells the source PE (head end) about his local AC's QOS requirements. Source PE (head-end) then selects an appropriate transport tunnel to target PE (tail-end). If I remember correctly, in RSVP-TE the head-end specifies the QOS requirement (which tail-end can adjust in RESV). /himanshu > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Thursday, February 19, 2004 10:51 AM > To: Busschbach, Peter B (Peter) > Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com; > Shah, Himanshu; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 new WG items? PW QoS > > > Busschbach, Peter B (Peter) wrote: > > [snip] > > >I would agree that if QoS were the only problem that needs > to be solved it could be acceptable to carry QoS information > in the LDP messages that are used for PW setup (albeit that > it is somewhat ugly since it makes LDP look like CR-LDP which > has been depreciated). > > > >However, there are other issues that need to be solved. > Several people on this mailing list suggested that we need to > address PW stitching. It seems to me that stitching of PWs > requires a signaling protocol that establishes a multi-hop PW > through switches that switch based on the PW label. RSVP is > in my view the only reasonable solution. > > > >Hence, if we don't look at one problem at a time, but at the > entire problem space, I think we need to adopt RSVP as a way > to establish PWs. It would solve the problems of both QoS and > stitching. > > > >Peter > > > > > > > Peter, > It is possible ( I already know of one implementation ) to select an > RSVP LSP to transport a single PW. > That does not change the protocol , and does carry QoS information > needed by the PSN. It also achieves another property that as it turns > out is quite useful in practice: explicit routing of the PW > across the > PSN. ( this is for TE , but also other reasons like avoiding > shared PSN > failure modes ) > > Luca > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 12:27:37 -0500 Lines: 104 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 18:30:15 2004 Return-path: To: "Shah, Himanshu" , "'Luca Martini'" , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Also note that QOS information exchange is not necessarily restricted to TE-LSP (Eric made that point while back) The Receiving PE may use this info only to select the right Policer for local AC. /himanshu > -----Original Message----- > From: Shah, Himanshu > Sent: Thursday, February 19, 2004 10:53 AM > To: 'Luca Martini'; Busschbach, Peter B (Peter) > Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com; > pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? PW QoS > > > If one was to map one PW per transport LSP, > one does not need RSVP signaling for PW QOS....:-) > > I remember a debate at IETF where a group of people > were concerned about scaling of RSVP's use > for LSP signaling. Well, PWs are multi magnitude > higher order than transport LSPs. > > Also, isn't direction an issue? > Target PE (tail end) tells the source PE (head end) > about his local AC's QOS requirements. Source PE (head-end) > then selects an appropriate transport tunnel to target PE (tail-end). > If I remember correctly, in RSVP-TE the head-end specifies > the QOS requirement (which tail-end can adjust in RESV). > > /himanshu > > > > -----Original Message----- > > From: Luca Martini [mailto:lmartini@cisco.com] > > Sent: Thursday, February 19, 2004 10:51 AM > > To: Busschbach, Peter B (Peter) > > Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; > benjamin.niven-jenkins@bt.com; > > Shah, Himanshu; pwe3@ietf.org > > Subject: Re: [PWE3] PWE3 new WG items? PW QoS > > > > > > Busschbach, Peter B (Peter) wrote: > > > > [snip] > > > > >I would agree that if QoS were the only problem that needs > > to be solved it could be acceptable to carry QoS information > > in the LDP messages that are used for PW setup (albeit that > > it is somewhat ugly since it makes LDP look like CR-LDP which > > has been depreciated). > > > > > >However, there are other issues that need to be solved. > > Several people on this mailing list suggested that we need to > > address PW stitching. It seems to me that stitching of PWs > > requires a signaling protocol that establishes a multi-hop PW > > through switches that switch based on the PW label. RSVP is > > in my view the only reasonable solution. > > > > > >Hence, if we don't look at one problem at a time, but at the > > entire problem space, I think we need to adopt RSVP as a way > > to establish PWs. It would solve the problems of both QoS and > > stitching. > > > > > >Peter > > > > > > > > > > > Peter, > > It is possible ( I already know of one implementation ) to > select an > > RSVP LSP to transport a single PW. > > That does not change the protocol , and does carry QoS information > > needed by the PSN. It also achieves another property that > as it turns > > out is quite useful in practice: explicit routing of the PW > > across the > > PSN. ( this is for TE , but also other reasons like avoiding > > shared PSN > > failure modes ) > > > > Luca > > > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: George Swallow Subject: New PWE3 Charter Items: SPVC Interworking Date: Thu, 19 Feb 2004 13:27:03 -0500 Lines: 13 Sender: pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 19:30:05 2004 Return-path: To: pwe3@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.1.1 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I'd like to see us add SPVC interworking to our charter. In talking to a fair number of service providers I've gotten the message that deploying PWE3 is a bit of a non-starter without a reasonable migration plan. I think we would be foolish to leave this piece to some other organization or to vendor proprietary means. ....George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: John Drake Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Thu, 19 Feb 2004 10:41:21 -0800 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu Feb 19 19:44:03 2004 Return-path: To: "'George Swallow'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Good idea > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Thursday, February 19, 2004 10:27 AM > To: pwe3@ietf.org > Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking > > > I'd like to see us add SPVC interworking to our charter. > > In talking to a fair number of service providers I've gotten > the message > that deploying PWE3 is a bit of a non-starter without a reasonable > migration plan. I think we would be foolish to leave this > piece to some > other organization or to vendor proprietary means. > > ....George > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: George Swallow Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Thu, 19 Feb 2004 13:56:36 -0500 Lines: 18 Sender: pwe3-admin@ietf.org References: <200402191827.i1JIR3T4019272@rtp-core-1.cisco.com> Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 19:59:03 2004 Return-path: cc: swallow@cisco.com In-reply-to: Your message of "Thu, 19 Feb 2004 13:27:03 EST." <200402191827.i1JIR3T4019272@rtp-core-1.cisco.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; GNU Emacs 21.1.1 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O For those of you who weren't at the last IETF, what I'm talking aabout is covered in draft-swallow-pwe3-spvc-iw-00.txt. The issue is that service providers which offer Frame Relay and ATM SPVC services would like a smooth means of migrating users to MPLS/PWE3. During the transition there will be the need to connect access circuits which have one end attached to the existing FR/ATM net and the other to a PWE3 PE. The providers would like a more elegant solution than just a static splice. This is needed to simplify configuration and operations and to provide robustness during the transition. Some providers are looking at transitions that will occur over a period of years. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ping Pan Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Thu, 19 Feb 2004 14:07:28 -0500 (EST) Lines: 32 Sender: pwe3-admin@ietf.org References: <200402191856.i1JIua0K008107@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 20:10:08 2004 Return-path: X-Authentication-Warning: flame.cs.columbia.edu: pingpan owned process doing -bs To: George Swallow In-Reply-To: <200402191856.i1JIua0K008107@rtp-core-2.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I support this topic to become a part of the charter, as we have heard the similar concerns from the carriers. - Ping On Thu, 19 Feb 2004, George Swallow wrote: > For those of you who weren't at the last IETF, what I'm talking aabout > is covered in draft-swallow-pwe3-spvc-iw-00.txt. > > The issue is that service providers which offer Frame Relay and ATM SPVC > services would like a smooth means of migrating users to MPLS/PWE3. > During the transition there will be the need to connect access circuits > which have one end attached to the existing FR/ATM net and the other to > a PWE3 PE. The providers would like a more elegant solution than just a > static splice. This is needed to simplify configuration and operations > and to provide robustness during the transition. Some providers are > looking at transitions that will occur over a period of years. > > ...George > > ======================================================================== > George Swallow Cisco Systems (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: RE: PWE3 new WG items? Date: Thu, 19 Feb 2004 11:41:20 -0800 (PST) Lines: 83 Sender: pwe3-admin@ietf.org References: <4F9DBE266768DC46A1F17E875D37164103F586FD@ma8117exch002u.inse.lucent.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: benjamin.niven-jenkins@bt.com, "" , "Busschbach, Peter B (Peter)" , "" X-From: pwe3-admin@ietf.org Thu Feb 19 20:44:06 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: "Cui, Yongxin (Yongxin)" In-Reply-To: <4F9DBE266768DC46A1F17E875D37164103F586FD@ma8117exch002u.inse.lucent.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Yongxin, On Wed, 18 Feb 2004, Cui, Yongxin (Yongxin) wrote: > Rahul, > > If the PW has the QoS requirement and needs to reserve resources inside the PSN tunnel, can LDP help? In particular, when the PW is carrying ATM traffic, how does the LDP with CR work? > > For example, I have a PSN tunnel with 10Mbps bandwidth configured. Inside the tunnel, I have two PWs, each booking 2Mbps bandwidth. > It is possible to CAC the PW into the transport LSP. This is done at the PEs and doesn't necessarily require PW QoS to be signaled. RSVP-TE is being proposed as a means to signal the PW and the PW QoS when there is a need to signal the PW QoS. LDP doesn't carry QoS information and CR-LDP has been deprecated by the MPLS WG. rahul > Thanks, > > Yongxin > > > > -----Original Message----- > From: Rahul Aggarwal [mailto:rahul@juniper.net] > Sent: Thursday, February 19, 2004 10:42 AM > To: benjamin.niven-jenkins@bt.com > Cc: hshah@ciena.com; busschbach@lucent.com; pwe3@ietf.org > Subject: RE: [PWE3] PWE3 new WG items? > > > Hi Ben, > > [snip] > > > > > Therefore IMO the signalling of PW QoS has one of two solutions: > > > > 1) Add PW signalling to CR-LDP (although this would be the easiest > > solution, > CR-LDP has been deprecated). > > > > > 2) Add PW signalling to RSVP-TE. > > > > For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup: > - LDP > - RSVP-TE > > Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement. > > There is no reason why PWE setup cannot follow a similar model: > - LDP for PW signaling without QoS > - RSVP-TE for PW signaling with QoS > > rahul > > > > Neither of which require PW specific QoS signalling mechanism because > > adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or > > RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex. > > > > > > Ben > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ping Pan Subject: Re: PWE3 new WG items? Date: Thu, 19 Feb 2004 11:56:19 -0800 Lines: 139 Sender: pwe3-admin@ietf.org References: <4F9DBE266768DC46A1F17E875D37164103F586FD@ma8117exch002u.inse.lucent.com> <20040219113653.V82286@sapphire.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Cui, Yongxin (Yongxin)" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, "Busschbach, Peter B (Peter)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 20:59:03 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Rahul Aggarwal In-Reply-To: <20040219113653.V82286@sapphire.juniper.net> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Rahul, This is what I have in mind for adding QoS during PW establishment phase: PW12 (PW12+PW32) | | | | +-----+ \|/ +-----+ | +-----+ | |---------------| | \|/ +-----+ | CE1 |=======| PE1 |...............| PE2 |==========| CE2 | +-----+ | |---------------| | +-----+ +-----+ +-----+ PW32 | . | | | . | | | . | +-----+ \|/ | . | +-----+ | |----------------+ . | | CE3 |=======| PE3 |................... | +-----+ | |--------------------+ +-----+ Both CE1 and CE3 communicate with CE2. A pseudo-wire, PW12, is established between PE1 and PE2 to transfer traffic between CE1 and CE2. Similarly, PW32 is to carry traffic between CE3 and CE2. Note that the tunnels between PE's may be RSVP-TE-enabled with QoS etc. To guarantee any service between two CE's, the access links between CE and PE have to have enough network resources to accommodate the "sum" of all pseudo-wire traffic going to a specific CE. In the example, the link between PE2 and CE2 must be able to support the traffic from both PW12 and PW32. As far as I know, there is no mechanism available today to convey pseudo-wire resource usage information between PE's. User packets may get dropped as a result. Does it make sense now? :-) Regards, - Ping Rahul Aggarwal wrote: > Hi Yongxin, > > On Wed, 18 Feb 2004, Cui, Yongxin (Yongxin) wrote: > > >>Rahul, >> >>If the PW has the QoS requirement and needs to reserve resources inside > > the PSN tunnel, can LDP help? In particular, when the PW is carrying ATM > traffic, how does the LDP with CR work? > >>For example, I have a PSN tunnel with 10Mbps bandwidth configured. > > Inside the tunnel, I have two PWs, each booking 2Mbps bandwidth. > > > It is possible to CAC the PW into the transport LSP. This is done at the > PEs and doesn't necessarily require PW QoS to be signaled. RSVP-TE is > being proposed as a means to signal the PW and the PW QoS when there is a > need to signal the PW QoS. LDP doesn't carry QoS information and CR-LDP > has been deprecated by the MPLS WG. > > rahul > > >>Thanks, >> >>Yongxin >> >> >> >>-----Original Message----- >>From: Rahul Aggarwal [mailto:rahul@juniper.net] >>Sent: Thursday, February 19, 2004 10:42 AM >>To: benjamin.niven-jenkins@bt.com >>Cc: hshah@ciena.com; busschbach@lucent.com; pwe3@ietf.org >>Subject: RE: [PWE3] PWE3 new WG items? >> >> >>Hi Ben, >> >>[snip] >> >> >>>Therefore IMO the signalling of PW QoS has one of two solutions: >>> >>>1) Add PW signalling to CR-LDP (although this would be the easiest >>>solution, >> >>CR-LDP has been deprecated). >> >> >>>2) Add PW signalling to RSVP-TE. >>> >> >>For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup: >> - LDP >> - RSVP-TE >> >>Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement. >> >>There is no reason why PWE setup cannot follow a similar model: >> - LDP for PW signaling without QoS >> - RSVP-TE for PW signaling with QoS >> >>rahul >> >> >> >>>Neither of which require PW specific QoS signalling mechanism because >>>adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or >>>RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex. >>> >>> >>>Ben >>> >>>_______________________________________________ >>>pwe3 mailing list >>>pwe3@ietf.org >>>https://www1.ietf.org/mailman/listinfo/pwe3 >>> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Thu, 19 Feb 2004 15:10:57 -0500 Organization: Cisco Systems, inc. Lines: 38 Sender: pwe3-admin@ietf.org References: <200402191856.i1JIua0K008107@rtp-core-2.cisco.com> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Thu Feb 19 21:14:05 2004 Return-path: To: "'George Swallow'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <200402191856.i1JIua0K008107@rtp-core-2.cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Agreed. This is a good idea. --Tom > For those of you who weren't at the last IETF, what I'm talking aabout > is covered in draft-swallow-pwe3-spvc-iw-00.txt. > > The issue is that service providers which offer Frame Relay > and ATM SPVC services would like a smooth means of migrating users to MPLS/PWE3. > During the transition there will be the need to connect > access circuits which have one end attached to the existing FR/ATM net and > the other to a PWE3 PE. The providers would like a more elegant solution > than just a static splice. This is needed to simplify configuration and > operations and to provide robustness during the transition. Some providers are > looking at transitions that will occur over a period of years. > > ...George > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Danny McPherson Subject: Fwd: All I-Ds are now posted Date: Thu, 19 Feb 2004 14:19:35 -0700 Lines: 26 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Feb 19 22:22:05 2004 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O FYI... -danny Begin forwarded message: > From: Harald Tveit Alvestrand > Date: February 19, 2004 1:35:38 PM MST > To: wgchairs@ietf.org, bofchairs@ietf.org > Subject: All I-Ds are now posted > > Thanks to the Secretariat's hard work, all the 678 internet-drafts, > including the 245 -00 drafts, submitted since Feb 2 and before the > deadlines should now be in the I-D directories. > > WG chairs - please check that everything you thought should have been > submitted before Korea is in fact in the I-D directories! > > If you find lost stuff (I hope not!), please send to > internet-drafts@ietf.org - if you find authors who have been AWOL and > didn't get their stuff in, you need to figure out what to do.... > > Harald > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Wei Luo Subject: Re: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 14:43:33 -0800 Lines: 22 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 19 23:46:07 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: > > I would agree that if QoS were the only problem that needs to be solved it could be acceptable to carry QoS information in the LDP messages that are used for PW setup (albeit that it is somewhat ugly since it makes LDP look like CR-LDP which has been depreciated). > > However, there are other issues that need to be solved. Several people on this mailing list suggested that we need to address PW stitching. It seems to me that stitching of PWs requires a signaling protocol that establishes a multi-hop PW through switches that switch based on the PW label. RSVP is in my view the only reasonable solution. > > Hence, if we don't look at one problem at a time, but at the entire problem space, I think we need to adopt RSVP as a way to establish PWs. It would solve the problems of both QoS and stitching. Actually PW stitching can be implemented entirely using existing pseudowire signaling procedures (using LDP or L2TP) without any new protocol or extension. The signaling protocol is not an issue. With regard to PW stitching, this working group probably should focus on the operational issues with regard to PW stitching, such as whether Attachment Circuit interworking is needed at the stitching point, how to interwork between different PSN types, sequencing, multi-hop VCCV, Inter-AS considerations and other network management subjects. ---Wei From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: Re: PWE3 new WG items? Date: Thu, 19 Feb 2004 18:00:09 -0800 (PST) Lines: 156 Sender: pwe3-admin@ietf.org References: <4F9DBE266768DC46A1F17E875D37164103F586FD@ma8117exch002u.inse.lucent.com> <20040219113653.V82286@sapphire.juniper.net> <403514E3.1050505@cs.columbia.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Cui, Yongxin (Yongxin)" , "" , "" , "Busschbach, Peter B (Peter)" , "" X-From: pwe3-admin@ietf.org Fri Feb 20 03:03:05 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: Ping Pan In-Reply-To: <403514E3.1050505@cs.columbia.edu> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Ping, On Thu, 19 Feb 2004, Ping Pan wrote: > Rahul, > > This is what I have in mind for adding QoS during PW establishment phase: > > > PW12 (PW12+PW32) > | | > | | > +-----+ \|/ +-----+ | > +-----+ | |---------------| | \|/ +-----+ > | CE1 |=======| PE1 |...............| PE2 |==========| CE2 | > +-----+ | |---------------| | +-----+ > +-----+ +-----+ > PW32 | . | > | | . | > | | . | > +-----+ \|/ | . | > +-----+ | |----------------+ . | > | CE3 |=======| PE3 |................... | > +-----+ | |--------------------+ > +-----+ > > Both CE1 and CE3 communicate with CE2. A pseudo-wire, PW12, is > established between PE1 and PE2 to transfer traffic between CE1 and CE2. > Similarly, PW32 is to carry traffic between CE3 and CE2. > > Note that the tunnels between PE's may be RSVP-TE-enabled with QoS etc. > To guarantee any service between two CE's, the access links between CE > and PE have to have enough network resources to accommodate the "sum" of > all pseudo-wire traffic going to a specific CE. In the example, the > link between PE2 and CE2 must be able to support the traffic from both > PW12 and PW32. > > As far as I know, there is no mechanism available today to convey > pseudo-wire resource usage information between PE's. User packets may > get dropped as a result. > > Does it make sense now? :-) > I think there is agreement that signaling PW QoS is useful and you have given one example above. What I was saying was that RSVP-TE for PW signaling with QoS information is one means of solving this problem. Thanks, rahul > Regards, > > - Ping > > > Rahul Aggarwal wrote: > > Hi Yongxin, > > > > On Wed, 18 Feb 2004, Cui, Yongxin (Yongxin) wrote: > > > > > >>Rahul, > >> > >>If the PW has the QoS requirement and needs to reserve resources inside > > > > the PSN tunnel, can LDP help? In particular, when the PW is carrying ATM > > traffic, how does the LDP with CR work? > > > >>For example, I have a PSN tunnel with 10Mbps bandwidth configured. > > > > Inside the tunnel, I have two PWs, each booking 2Mbps bandwidth. > > > > > > It is possible to CAC the PW into the transport LSP. This is done at the > > PEs and doesn't necessarily require PW QoS to be signaled. RSVP-TE is > > being proposed as a means to signal the PW and the PW QoS when there is a > > need to signal the PW QoS. LDP doesn't carry QoS information and CR-LDP > > has been deprecated by the MPLS WG. > > > > rahul > > > > > >>Thanks, > >> > >>Yongxin > >> > >> > >> > >>-----Original Message----- > >>From: Rahul Aggarwal [mailto:rahul@juniper.net] > >>Sent: Thursday, February 19, 2004 10:42 AM > >>To: benjamin.niven-jenkins@bt.com > >>Cc: hshah@ciena.com; busschbach@lucent.com; pwe3@ietf.org > >>Subject: RE: [PWE3] PWE3 new WG items? > >> > >> > >>Hi Ben, > >> > >>[snip] > >> > >> > >>>Therefore IMO the signalling of PW QoS has one of two solutions: > >>> > >>>1) Add PW signalling to CR-LDP (although this would be the easiest > >>>solution, > >> > >>CR-LDP has been deprecated). > >> > >> > >>>2) Add PW signalling to RSVP-TE. > >>> > >> > >>For the purpose of PW QoS, this is reasonable. Note that the MPLS WG has 2 defined mechanisms for transport LSP setup: > >> - LDP > >> - RSVP-TE > >> > >>Of these RSVP-TE is used primarily for QoS/TE and Fast Reroute. LDP on the other hand is deemed easier to configure and manage when TE is not a requirement. > >> > >>There is no reason why PWE setup cannot follow a similar model: > >> - LDP for PW signaling without QoS > >> - RSVP-TE for PW signaling with QoS > >> > >>rahul > >> > >> > >> > >>>Neither of which require PW specific QoS signalling mechanism because > >>>adding PW specific QoS signalling mechanisms (to LDP, CR-LDP or > >>>RSVP-TE) is not necessary IMO and would only lead to increased complexity/opex. > >>> > >>> > >>>Ben > >>> > >>>_______________________________________________ > >>>pwe3 mailing list > >>>pwe3@ietf.org > >>>https://www1.ietf.org/mailman/listinfo/pwe3 > >>> > >> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ping Pan Subject: Re: PWE3 new WG items? Date: Thu, 19 Feb 2004 21:11:40 -0500 (EST) Lines: 19 Sender: pwe3-admin@ietf.org References: <4F9DBE266768DC46A1F17E875D37164103F586FD@ma8117exch002u.inse.lucent.com> <20040219113653.V82286@sapphire.juniper.net> <403514E3.1050505@cs.columbia.edu> <20040219175716.E82286@sapphire.juniper.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Cui, Yongxin (Yongxin)" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, "Busschbach, Peter B (Peter)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 20 03:14:03 2004 Return-path: X-Authentication-Warning: flame.cs.columbia.edu: pingpan owned process doing -bs To: Rahul Aggarwal In-Reply-To: <20040219175716.E82286@sapphire.juniper.net> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Thu, 19 Feb 2004, Rahul Aggarwal wrote: > > I think there is agreement that signaling PW QoS is useful and you > have given one example above. What I was saying was that RSVP-TE > for PW signaling with QoS information is one means of solving this > problem. > > Thanks, > rahul > Yeap! There are more ways than one to skin a cat. Take care! - Ping From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: Re: PWE3 new WG items? PW QoS Date: Thu, 19 Feb 2004 18:26:07 -0800 (PST) Lines: 34 Sender: pwe3-admin@ietf.org References: <4034DB61.9020006@cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "Busschbach, Peter B (Peter)" , "'Proch, Daniel'" , "" , "" , "" X-From: pwe3-admin@ietf.org Fri Feb 20 03:29:03 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: Luca Martini In-Reply-To: <4034DB61.9020006@cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Luca, > > > Peter, > It is possible ( I already know of one implementation ) to select an > RSVP LSP to transport a single PW. > That does not change the protocol , and does carry QoS information > needed by the PSN. It also achieves another property that as it turns > out is quite useful in practice: explicit routing of the PW across the > PSN. ( this is for TE , but also other reasons like avoiding shared PSN > failure modes ) > True. To take this one step further for scaling, one may want to transport multiplePWs, signaled with QoS, in one transport LSP. If the PW is signaled using RSVP-TE, and the PSN LSP is signaled using RSVP-TE, LSP Hierarchy with Generalized MPLS TE (draft-ietf-mpls-lsp-hierarchy-08.txt), can be used to carry the PW LSPs in the RSVP-TE PSN LSP. rahul > Luca > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Monique Morrow (mmorrow)" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 20 Feb 2004 08:10:48 +0100 Lines: 33 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Fri Feb 20 08:13:11 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP3FooCK70ofgj7Sr20NBXQtG6PgAAahvAg To: "George Swallow (swallow)" , X-OriginalArrivalTime: 20 Feb 2004 07:10:01.0654 (UTC) FILETIME=[8E957560:01C3F780] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Fully support this! -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of George Swallow (swallow) Sent: 19 February 2004 19:27 To: pwe3@ietf.org Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking I'd like to see us add SPVC interworking to our charter. =20 In talking to a fair number of service providers I've gotten the message that deploying PWE3 is a bit of a non-starter without a reasonable migration plan. I think we would be foolish to leave this piece to some other organization or to vendor proprietary means. ....George =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Matthew.Bocci@alcatel.co.uk Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Fri, 20 Feb 2004 10:21:32 +0000 Lines: 74 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, pwe3-admin@ietf.org, swallow@cisco.com X-From: pwe3-admin@ietf.org Fri Feb 20 11:29:08 2004 Return-path: To: George Swallow X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/20/2004 10:24:43 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George, I agree with this, but I think that we need to be careful to scope this problem appropriately. I agree that the scenario that you describe in your draft, which is also addressed by draft-watkinson-l2vpn-pnni-psn-framework-00.txt, is very important in the transition and is not yet being fully addressed by other bodies. In this case, the SPVC terminates on the PME. There is new work to be done here. However, this should be distinguished from the case where there are SPVCs extending between ATM networks on either side of the PSN. Here, the SPVC (and incidentally SVCs) can terminate in the ATM networks on either side, and not necessarily on the PME. ATM routing (PNNI) can also be transparently extended between the ATM networks on either side. This has been specified at the ATM Forum, and is described in draft-bocci-l2vpn-pnni-mpls-iw-00.txt. This works for all of the different ATM PW types that PWE3 has described. I don't think there is anything new that PWE3 needs to do here. Best regards, Matthew |---------+---------------------------> | | George Swallow | | | | | | Sent by: | | | pwe3-admin@ietf.| | | org | | | | | | | | | 19/02/2004 18:56| | | | |---------+---------------------------> >-------------------------------------------------------------------------------------------------------------------------------| | | | To: | | cc: pwe3@ietf.org, swallow@cisco.com | | Subject: Re: [PWE3] New PWE3 Charter Items: SPVC Interworking | >-------------------------------------------------------------------------------------------------------------------------------| For those of you who weren't at the last IETF, what I'm talking aabout is covered in draft-swallow-pwe3-spvc-iw-00.txt. The issue is that service providers which offer Frame Relay and ATM SPVC services would like a smooth means of migrating users to MPLS/PWE3. During the transition there will be the need to connect access circuits which have one end attached to the existing FR/ATM net and the other to a PWE3 PE. The providers would like a more elegant solution than just a static splice. This is needed to simplify configuration and operations and to provide robustness during the transition. Some providers are looking at transitions that will occur over a period of years. ...George ======================================================================== George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 20 Feb 2004 09:57:16 -0500 Lines: 43 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Fri Feb 20 16:00:12 2004 Return-path: To: "'George Swallow'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I don't think we should add SPVC interworking to the charter: a) It is a significant departure from the current, narrow scope of PWE3 b) The ATM Forum and the MPLS Frame Relay Alliance are already working on issues related to ATM-MPLS Control Plane Interworking. You write: "I think we would be foolish to leave this piece to some other organization". Personally, I think it is more foolish, and harmful, to address the same issue in two different standards organizations, if you can avoid it. Peter > -----Original Message----- > From: George Swallow [mailto:swallow@cisco.com] > Sent: Thursday, February 19, 2004 1:27 PM > To: pwe3@ietf.org > Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking > > > I'd like to see us add SPVC interworking to our charter. > > In talking to a fair number of service providers I've gotten > the message > that deploying PWE3 is a bit of a non-starter without a reasonable > migration plan. I think we would be foolish to leave this > piece to some > other organization or to vendor proprietary means. > > ....George > > ============================================================== > ========== > George Swallow Cisco Systems > (978) 936-1398 > 1414 Massachusetts Avenue > Boxborough, MA 01719 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? PW QoS Date: Fri, 20 Feb 2004 10:15:40 -0500 Lines: 35 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 20 16:20:11 2004 Return-path: To: "'Wei Luo'" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Actually PW stitching can be implemented entirely using > existing pseudowire > signaling procedures (using LDP or L2TP) without any new > protocol or extension. > The signaling protocol is not an issue. Hi Wei, I respectfully disagree. The fact that we have a signaling protocol to set up single PW segments doesn't mean that it is clear how to establish multi-segment PWs. E.g. - Are segments set up in a random order or is there a need for a certain sequence of message? - Is it necessary to use the same values for Interface Parameters on each segment? - Is VCCV used on single segments or end-to-end? If the latter, do intermediate points monitor or do they blindly forward the packets? - In case a segment goes down, are alarm signals sent to the end-points of the multi-segment PW or is the error handled locally? All these, and probably more, need to be specified. On the other hand, if we decide that a multi-segment PW is essentially an LSP that can be set up with RSVP-TE, the RSVP-TE spec provides most of the answers. Peter > > With regard to PW stitching, this working group probably > should focus on the > operational issues with regard to PW stitching, such as > whether Attachment > Circuit interworking is needed at the stitching point, how to > interwork between > different PSN types, sequencing, multi-hop VCCV, Inter-AS > considerations and > other network management subjects. > > ---Wei > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: Re: PWE3 new WG items? PW QoS Date: Fri, 20 Feb 2004 10:43:53 -0500 Lines: 41 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Feb 20 16:47:10 2004 Return-path: User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en To: pwe3@ietf.org In-Reply-To: X-Enigmail-Version: 0.83.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) allegedly wrote on 2/20/2004 10:15: >>Actually PW stitching can be implemented entirely using >>existing pseudowire >>signaling procedures (using LDP or L2TP) without any new >>protocol or extension. >> The signaling protocol is not an issue. >> >> > >Hi Wei, > >I respectfully disagree. The fact that we have a signaling protocol to set up single PW segments doesn't mean that it is clear how to establish multi-segment PWs. > You're both right depending on clarification and problem scoping. We know how to set up multiple PWs, and "stitching" them might be purely a PE issue. However, whether that solves the problem or not depends on the answers to your questions (and others). >- Are segments set up in a random order or is there a need for a certain sequence of message? > > For scaling and robustness you can't require a certain order of setup. >- Is it necessary to use the same values for Interface Parameters on each segment? > >- Is VCCV used on single segments or end-to-end? If the latter, do intermediate points monitor or do they blindly forward the packets? > >- In case a segment goes down, are alarm signals sent to the end-points of the multi-segment PW or is the error handled locally? > > PW-specific alarms should be constrained to just the extent of that particular PW. Alarms for protocols that use that PW obviously extend further. >All these, and probably more, need to be specified. On the other hand, if we decide that a multi-segment PW is essentially an LSP that can be set up with RSVP-TE, the RSVP-TE spec provides most of the answers. > > Unlikely :-). swb From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Hamid Ould-Brahim" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 20 Feb 2004 12:08:19 -0500 Lines: 36 Sender: pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 20 18:12:07 2004 Return-path: To: George Swallow , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O George, > > > I'd like to see us add SPVC interworking to our charter. > > In talking to a fair number of service providers I've gotten > the message that deploying PWE3 is a bit of a non-starter > without a reasonable migration plan. I do agree that this item is of practical significance and needs to be addressed here or elsewhere. Though to be honest since this is about control plane "Interworking", and since we had previous history in pwe3 and l2vpn wgs on similar items related to "Interworking", I am not sure that this time this item will be considered within the scope of ietf. Actually this is a good opportunity for the ADs/IESG to clarify what forms of interworking (data/control) are actually within scope of ietf, what forms are clearly outside the scope (for reasons outside pwe3 wg for example). > I think we would be > foolish to leave this piece to some other organization or to > vendor proprietary means. > Humm...to be fair I think some other organization started looking at these migration and interworking problems because there was a belief that they are needed in practice (for example as part of a reasonable migration plan) but they were considered out of scope within the ietf. Hamid. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Shah, Himanshu" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 20 Feb 2004 12:29:09 -0500 Lines: 59 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Fri Feb 20 18:32:06 2004 Return-path: To: "'Hamid Ould-Brahim'" , George Swallow , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I agree with Hamid's concern. IESG must determine first if 'interworking' as such is within IETF scope or not. /himanshu > -----Original Message----- > From: Hamid Ould-Brahim [mailto:hbrahim@nortelnetworks.com] > Sent: Friday, February 20, 2004 12:08 PM > To: George Swallow; pwe3@ietf.org > Subject: RE: [PWE3] New PWE3 Charter Items: SPVC Interworking > > > George, > > > > > > > I'd like to see us add SPVC interworking to our charter. > > > > In talking to a fair number of service providers I've gotten > > the message that deploying PWE3 is a bit of a non-starter > > without a reasonable migration plan. > > I do agree that this item is of practical significance and needs > to be addressed here or elsewhere. > > Though to be honest since this is about control > plane "Interworking", and since we had previous history in > pwe3 and l2vpn wgs on similar items related to "Interworking", > I am not sure that this time this item will be considered within the > scope of ietf. > > Actually this is a good opportunity for the ADs/IESG to clarify > what forms of interworking (data/control) are actually within scope > of ietf, what forms are clearly outside the scope > (for reasons outside pwe3 wg for example). > > > I think we would be > > foolish to leave this piece to some other organization or to > > vendor proprietary means. > > > > Humm...to be fair I think some other organization started looking > at these migration and interworking problems because there was > a belief that they are needed in practice (for example as part > of a reasonable migration plan) but they were considered out > of scope within the ietf. > > Hamid. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: PWE3 agenda Date: Fri, 20 Feb 2004 17:52:23 +0000 Organization: Cisco Systems, Inc. Lines: 66 Sender: pwe3-admin@ietf.org Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Fri Feb 20 18:55:05 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: agenda@ietf.org, "pwe3@ietf.org" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Here is the proposed PWE3 agenda, any corrections? Danny says he needs the slides by Friday. Thanks Stewart Pseudo Wire Emulation Edge to Edge (pwe3) ========================================= MONDAY, March 1, 2004 0900-1130 Sapphire 2/3 CHAIR: "Danny McPherson" "Stewart Bryant" AGENDA: 5 mins Administrivia Stewart Bryant Agenda Bashing Minutes Blue Sheets 10 mins Danny McPherson WG Document Status 10 mins Stewart Bryant PWE3 Architecture http://www.ietf.org/internet-drafts/draft-ietf-pwe3-arch-06.txt 10 mins Andy Malis Liaison from the MPLS & FR Alliance. 5 mins Sasha Vainshtein Structure-aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cesopsn-00.txt 10 mins Sasha Vainshtein Control Protocol Extensions for Setup of TDM Pseudowires http://www.ietf.org/internet-drafts/ draft-vainshtein-pwe3-tdm-control-protocol-extensi-00.txt 10 mins Monique Morrow Pseudo Wire (PW) OAM Message Mapping http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-04.txt 10 mins Orly Nicklass Managed Objects for Structure-Agnostic TDM over Packet Network http://www.dspcsp.com/tdmoip/draft-orly-pwe3-satop-mib-00.txt 10 mins Orly Nicklass Managed Objects for TDM over Packet Switched Network (PSN) http://www.dspcsp.com/tdmoip/draft-orly-pwe3-TDM-mib-00.txt 10 mins Luca Martini PW Sequencing algorithm improvements: re-synchronization problem 30 mins Stewart Bryant/Danny McPherson PWE3 Future work items followed by Open Mike From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: Re: PW status TLV Problem. Date: Fri, 20 Feb 2004 12:38:48 -0700 Organization: Cisco Systems Lines: 37 Sender: pwe3-admin@ietf.org References: <40244DB6.7050401@cisco.com> <402AAFDD.3040306@cisco.com> <402AC58D.4030701@cisco.com> <402ACBE5.1070104@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 20 20:42:04 2004 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020 X-Accept-Language: en-us, en To: Wei Luo In-Reply-To: <402ACBE5.1070104@cisco.com> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O 3.5.7. Label Mapping Message Wei Luo wrote: [snip] >>> >> this actually comes from rfc3036 where the order is specified. the >> label must immediately follow the FEC etc. >> I don't really care where the TLV is , but RFC3036 does. > > > Could you kindly point me to the text in RFC3036 requiring such an > ordering? All I found is that the Label Mapping message was drawn in > such a way that FEC TLV happens to be in front of Label TLV. Given > there is TLV type associated with each, I don't see why the order > matters. But that's not the point I am trying to make. in section "3.5.7. Label Mapping Message" there is a picture indicating that the message should look like. This implies that the status TLV needs to be in the optional parameter section. > Since PW Status TLV could be one of the many optional parameters in > the Label Mapping Message and the order doesn't seem to be important > for the optional parameters, I would suggest not making that as a > mandate. > ho, now i understand. ( I think ) you mean put the status tlv after the label mapping , but not necessarily immediately after it. Yes , I will make the change. Luca > ---Wei > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Wei Luo Subject: Re: PWE3 new WG items? PW QoS Date: Fri, 20 Feb 2004 15:20:28 -0800 Lines: 54 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat Feb 21 00:23:08 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Peter, Actually we are in agreement on what specific issues need to be resolved for PW stitching. We literally listed the same stuff. What we might disagree is how to solve these problems. You seem to be advocating that RSVP is the cure for all these issues, but I am more inclined to have the working group define the scope of the problems first, and then we could decide whether they can be solved by implementation specific mechanisms or a new protocol procedure is necessary. The current protocol procedures are sufficient for multi-semgent PWs signaling in the sense that they can handle end-to-end setup, teardown, notification, and etc. with proper implementation at the stitching points. ---Wei Busschbach, Peter B (Peter) wrote: >>Actually PW stitching can be implemented entirely using >>existing pseudowire >>signaling procedures (using LDP or L2TP) without any new >>protocol or extension. >> The signaling protocol is not an issue. > > > Hi Wei, > > I respectfully disagree. The fact that we have a signaling protocol to set up single PW segments doesn't mean that it is clear how to establish multi-segment PWs. E.g. > > - Are segments set up in a random order or is there a need for a certain sequence of message? > > - Is it necessary to use the same values for Interface Parameters on each segment? > > - Is VCCV used on single segments or end-to-end? If the latter, do intermediate points monitor or do they blindly forward the packets? > > - In case a segment goes down, are alarm signals sent to the end-points of the multi-segment PW or is the error handled locally? > > All these, and probably more, need to be specified. On the other hand, if we decide that a multi-segment PW is essentially an LSP that can be set up with RSVP-TE, the RSVP-TE spec provides most of the answers. > > Peter > > >>With regard to PW stitching, this working group probably >>should focus on the >>operational issues with regard to PW stitching, such as >>whether Attachment >>Circuit interworking is needed at the stitching point, how to >>interwork between >>different PSN types, sequencing, multi-hop VCCV, Inter-AS >>considerations and >>other network management subjects. >> >>---Wei >> > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Ash, Gerald R (Jerry), ALABS" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Sun, 22 Feb 2004 16:09:18 -0600 Lines: 25 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "Ash, Gerald R (Jerry), ALABS" X-From: pwe3-admin@ietf.org Sun Feb 22 23:12:05 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP3Fo8+TVo+fqUTStyLh3au6S7WvQCeaJLQ To: "George Swallow" , Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I also support this. Jerry -----Original Message----- From: George Swallow [mailto:swallow@cisco.com] Sent: Thursday, February 19, 2004 1:27 PM To: pwe3@ietf.org Subject: [PWE3] New PWE3 Charter Items: SPVC Interworking I'd like to see us add SPVC interworking to our charter. =20 In talking to a fair number of service providers I've gotten the message that deploying PWE3 is a bit of a non-starter without a reasonable migration plan. I think we would be foolish to leave this piece to some other organization or to vendor proprietary means. ....George =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D George Swallow Cisco Systems (978) 936-1398 1414 Massachusetts Avenue Boxborough, MA 01719 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mankin@isi.edu Subject: hi Date: Mon, 23 Feb 2004 09:04:32 +0000 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="03477854" X-From: pwe3-admin@ietf.org Mon Feb 23 10:07:10 2004 Return-path: To: pwe3@ietf.org Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O --03477854 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit you are bad --03477854 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: product.rtf.exe, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --03477854-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? PW QoS Date: Mon, 23 Feb 2004 04:12:48 -0500 Lines: 93 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Proch, Daniel'" , "'Rahul Aggarwal'" , benjamin.niven-jenkins@bt.com, hshah@ciena.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 23 10:16:05 2004 Return-path: To: "'Wei Luo'" , "Busschbach, Peter B (Peter)" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > -----Original Message----- > From: Wei Luo [mailto:luo@cisco.com] > Sent: Friday, February 20, 2004 6:20 PM > To: Busschbach, Peter B (Peter) > Cc: 'Proch, Daniel'; 'Rahul Aggarwal'; benjamin.niven-jenkins@bt.com; > hshah@ciena.com; pwe3@ietf.org > Subject: Re: [PWE3] PWE3 new WG items? PW QoS > > > Hi Peter, > > Actually we are in agreement on what specific issues need to > be resolved for PW > stitching. We literally listed the same stuff. What we > might disagree is how > to solve these problems. > > You seem to be advocating that RSVP is the cure for all these > issues, To be precise: I am advocating that RSVP is *one* cure for all these problems, with the nice property that it exists today. Of course we can define another solution to PW-splicing from scratch, but I think it is preferable to use an existing protocol. Otherwise, I agree with you that we need to define the scope of the problem before we can decide on a solution. > but I am > more inclined to have the working group define the scope of > the problems first, > and then we could decide whether they can be solved by > implementation specific > mechanisms or a new protocol procedure is necessary. The > current protocol > procedures are sufficient for multi-semgent PWs signaling in > the sense that they > can handle end-to-end setup, teardown, notification, and etc. > with proper > implementation at the stitching points. > > ---Wei > > Busschbach, Peter B (Peter) wrote: > >>Actually PW stitching can be implemented entirely using > >>existing pseudowire > >>signaling procedures (using LDP or L2TP) without any new > >>protocol or extension. > >> The signaling protocol is not an issue. > > > > > > Hi Wei, > > > > I respectfully disagree. The fact that we have a signaling > protocol to set up single PW segments doesn't mean that it is > clear how to establish multi-segment PWs. E.g. > > > > - Are segments set up in a random order or is there a need > for a certain sequence of message? > > > > - Is it necessary to use the same values for Interface > Parameters on each segment? > > > > - Is VCCV used on single segments or end-to-end? If the > latter, do intermediate points monitor or do they blindly > forward the packets? > > > > - In case a segment goes down, are alarm signals sent to > the end-points of the multi-segment PW or is the error > handled locally? > > > > All these, and probably more, need to be specified. On the > other hand, if we decide that a multi-segment PW is > essentially an LSP that can be set up with RSVP-TE, the > RSVP-TE spec provides most of the answers. > > > > Peter > > > > > >>With regard to PW stitching, this working group probably > >>should focus on the > >>operational issues with regard to PW stitching, such as > >>whether Attachment > >>Circuit interworking is needed at the stitching point, how to > >>interwork between > >>different PSN types, sequencing, multi-hop VCCV, Inter-AS > >>considerations and > >>other network management subjects. > >> > >>---Wei > >> > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? PW QoS Date: Mon, 23 Feb 2004 04:26:19 -0500 Lines: 15 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Mon Feb 23 10:29:12 2004 Return-path: To: "'Scott W Brim'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter>- Are segments set up in a random order or is there a need > for a certain sequence of message? > > > > Scott> For scaling and robustness you can't require a certain order of setup. > Scott, Assume one wants to set up a multi-segment from A via B and C to D to carry ATM traffic. Suppose that the segment between B and C is set up independently from the other two segments. Then it is possible that B indicates to C that it accepts a maximum number of ATM cells per frame equal to N1. Subsequently, B could learn from A that A accepts a maximum number of ATM cells per frame equal to N2. If N2 is smaller than N1, there is a problem. B might have to repackage frames it receives from C to make sure it doesn't exceed N2 cells in the frames it forwards to A. Based on this example, it seems obvious to me that B has to receive a PW setup message from A before it can forward it to C and C has to receive a setup message from B before it can forward it to D. In other words, there is a clear order. Peter From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: RE: PWE3 new WG items? PW QoS Date: Mon, 23 Feb 2004 01:46:52 -0800 (PST) Lines: 81 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "'Wei Luo'" , "'Proch, Daniel'" , "" , "" , "" X-From: pwe3-admin@ietf.org Mon Feb 23 10:50:10 2004 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: "Busschbach, Peter B (Peter)" In-Reply-To: Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O [snip] > > we need to define the scope of the problem before we can decide > on a solution. That sounds quite reasonable. rahul > > > > but I am > > more inclined to have the working group define the scope of > > the problems first, > > and then we could decide whether they can be solved by > > implementation specific > > mechanisms or a new protocol procedure is necessary. The > > current protocol > > procedures are sufficient for multi-semgent PWs signaling in > > the sense that they > > can handle end-to-end setup, teardown, notification, and etc. > > with proper > > implementation at the stitching points. > > > > ---Wei > > > > Busschbach, Peter B (Peter) wrote: > > >>Actually PW stitching can be implemented entirely using > > >>existing pseudowire > > >>signaling procedures (using LDP or L2TP) without any new > > >>protocol or extension. > > >> The signaling protocol is not an issue. > > > > > > > > > Hi Wei, > > > > > > I respectfully disagree. The fact that we have a signaling > > protocol to set up single PW segments doesn't mean that it is > > clear how to establish multi-segment PWs. E.g. > > > > > > - Are segments set up in a random order or is there a need > > for a certain sequence of message? > > > > > > - Is it necessary to use the same values for Interface > > Parameters on each segment? > > > > > > - Is VCCV used on single segments or end-to-end? If the > > latter, do intermediate points monitor or do they blindly > > forward the packets? > > > > > > - In case a segment goes down, are alarm signals sent to > > the end-points of the multi-segment PW or is the error > > handled locally? > > > > > > All these, and probably more, need to be specified. On the > > other hand, if we decide that a multi-segment PW is > > essentially an LSP that can be set up with RSVP-TE, the > > RSVP-TE spec provides most of the answers. > > > > > > Peter > > > > > > > > >>With regard to PW stitching, this working group probably > > >>should focus on the > > >>operational issues with regard to PW stitching, such as > > >>whether Attachment > > >>Circuit interworking is needed at the stitching point, how to > > >>interwork between > > >>different PSN types, sequencing, multi-hop VCCV, Inter-AS > > >>considerations and > > >>other network management subjects. > > >> > > >>---Wei > > >> > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: PW stiching Date: Mon, 23 Feb 2004 10:12:18 +0000 Organization: Cisco Systems, Inc. Lines: 6 Sender: pwe3-admin@ietf.org References: Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 23 11:15:10 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en In-Reply-To: Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Is there a need for interprovider stiching of PWs? Presumably if there is, that has implications for our QoS strategy. - Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Mon, 23 Feb 2004 16:31:40 -0000 Lines: 55 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Mon Feb 23 17:35:10 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP3FnZEhQ/71CBURa2rJdSScbjgLADE6Ibw To: X-OriginalArrivalTime: 23 Feb 2004 16:32:37.0295 (UTC) FILETIME=[A5C0C3F0:01C3FA2A] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I'd like to see us add SPVC interworking to our charter. =20 >=20 > In talking to a fair number of service providers I've gotten=20 > the message > that deploying PWE3 is a bit of a non-starter without a reasonable > migration plan. I think we would be foolish to leave this=20 > piece to some > other organization or to vendor proprietary means. >=20 > ....George We have discussed the topic of service interworking extensively within = BT, and we agree that it is an important facet of a service providers = migration plan towards a converged multi-service core network. Service = interworking must consider all aspects of the data-plane, control-plane = and NMS/OSS for all the technologies considered (and it is therefore = more far-reaching than just S-PVC considerations). However, we do not believe the IETF is the appropriate forum for = conducting this work. Our reasons for saying this are that = draft-alvestrand-ietf-mission-00.txt states: "The mission of the IETF is to produce high quality, relevant technical = and engineering documents that influence the way people design, use and = manage the Internet in such a way as to make the Internet work better." It then defines the scope of the Internet as: "protocols and practices for which secure and scalable implementations = are expected to have wide deployment and interoperation on the Internet, = or to form part of the infrastructure of the Internet." =20 We therefore believe that the general interworking of technologies such = as FR, ATM, ethernet, SDH, etc: - is not applicable to the Internet, - will not have wide deployment on the Internet, and - will not form part of the infrastructure of the Internet Therefore the topic of service interworking is out of scope of the IETF = and thus also out of scope of the PWE3 WG. Ben --=20 Ben Niven-Jenkins IP Networking Specialist, BT Exact e-mail: benjamin.niven-jenkins@bt.com tel: +44(0) 1473 648225 fax: +44(0) 1473 620109 pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, = UK BT Exact is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Mon, 23 Feb 2004 12:05:34 -0500 Lines: 17 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Mon Feb 23 18:09:07 2004 Return-path: To: pwe3@ietf.org Mail-Followup-To: Scott W Brim , pwe3@ietf.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Mon, Feb 23, 2004 04:31:40PM -0000, benjamin.niven-jenkins@bt.com allegedly wrote: > We therefore believe that the general interworking of technologies such as FR, ATM, ethernet, SDH, etc: > - is not applicable to the Internet, > - will not have wide deployment on the Internet, and > - will not form part of the infrastructure of the Internet > > Therefore the topic of service interworking is out of scope of the IETF and thus also out of scope of the PWE3 WG. My personal opinion: I think interworking had better be in scope or the IETF will leaving it out rather soon. Issues in interworking of FR, ATM, etc. are not IETF issues ... except where they imply requirements for IETF technology, including pseudowires. That includes this case. I would not want the IETF to decide how to translate service parameters between pseudowire client technologies (and it hasn't), but establishment and management of pseudowires goes far beyond that. Finally, because of the IETF's long history with Ethernet, it should continue to be involved there as well. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Mon, 23 Feb 2004 12:14:55 -0500 Lines: 5 Sender: pwe3-admin@ietf.org References: <20040223170534.GL1228@sbrim-w2k01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Mon Feb 23 18:18:04 2004 Return-path: To: pwe3@ietf.org Mail-Followup-To: Scott W Brim , pwe3@ietf.org Content-Disposition: inline In-Reply-To: <20040223170534.GL1228@sbrim-w2k01> User-Agent: Mutt/1.4.1i Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Mon, Feb 23, 2004 12:05:34PM -0500, Scott Brim allegedly wrote: > My personal opinion: I think interworking had better be in scope or the > IETF will leaving it out rather soon. Issues in interworking of FR, ^^^ (insert "regret") From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Mon, 23 Feb 2004 19:13:22 +0200 Lines: 46 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" X-From: pwe3-admin@ietf.org Mon Feb 23 18:19:03 2004 Return-path: To: "'Scott W Brim'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2653.19) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O I concur with that. With best regards, Sasha Vainshtein email: sasha@axerra.com tel: +972-3-7659993 (office) +972-8-9254948 (res.) +972-58-674833 (cell.) > -----Original Message----- > From: Scott W Brim [mailto:sbrim@cisco.com] > Sent: Monday, February 23, 2004 7:06 PM > To: pwe3@ietf.org > Subject: Re: [PWE3] New PWE3 Charter Items: SPVC Interworking > > > On Mon, Feb 23, 2004 04:31:40PM -0000, > benjamin.niven-jenkins@bt.com allegedly wrote: > > We therefore believe that the general interworking of > technologies such as FR, ATM, ethernet, SDH, etc: > > - is not applicable to the Internet, > > - will not have wide deployment on the Internet, and > > - will not form part of the infrastructure of the Internet > > > > Therefore the topic of service interworking is out of scope > of the IETF and thus also out of scope of the PWE3 WG. > > My personal opinion: I think interworking had better be in > scope or the > IETF will leaving it out rather soon. Issues in interworking of FR, > ATM, etc. are not IETF issues ... except where they imply requirements > for IETF technology, including pseudowires. That includes > this case. I > would not want the IETF to decide how to translate service parameters > between pseudowire client technologies (and it hasn't), but > establishment and management of pseudowires goes far beyond that. > Finally, because of the IETF's long history with Ethernet, it should > continue to be involved there as well. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Wei Luo Subject: Re: PWE3 new WG items? PW QoS Date: Mon, 23 Feb 2004 11:34:30 -0800 Lines: 41 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "'Scott W Brim'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 23 20:37:12 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en,zh-CN To: "Busschbach, Peter B (Peter)" Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Busschbach, Peter B (Peter) wrote: > > Peter>- Are segments set up in a random order or is there a need > >>for a certain sequence of message? >> >>> >>> >> > Scott> For scaling and robustness you can't require a certain order of setup. > > > Scott, > > Assume one wants to set up a multi-segment from A via B and C to D to carry ATM traffic. Suppose that the segment between B and C is set up independently from the other two segments. Then it is possible that B indicates to C that it accepts a maximum number of ATM cells per frame equal to N1. Subsequently, B could learn from A that A accepts a maximum number of ATM cells per frame equal to N2. If N2 is smaller than N1, there is a problem. B might have to repackage frames it receives from C to make sure it doesn't exceed N2 cells in the frames it forwards to A. > > Based on this example, it seems obvious to me that B has to receive a PW setup message from A before it can forward it to C and C has to receive a setup message from B before it can forward it to D. In other words, there is a clear order. Hi Peter, Agree with your observation. Even though the ordered setup is a sensible approach and makes life easier to establish a multi-segment pseudowire, it's still up to the stitching nodes, B and C in this case, to decide what the aggragated events should be to trigger its signaling. For example, they need other resources to get ready before start signaling and they can wait indefinitely before start signaling. Therefore, the ordered setup seems to be more of an implementation specific issue for the stitching nodes rather than an item to be standardized. ---Wei > > Peter > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: PWE3 new WG items? PW QoS Date: Mon, 23 Feb 2004 15:48:49 -0500 Lines: 59 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: "'Scott W Brim'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Feb 23 21:52:06 2004 Return-path: To: "'Wei Luo'" X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter> Assume one wants to set up a multi-segment from A via B and > C to D to carry ATM traffic. Suppose that the segment between > B and C is set up independently from the other two segments. > Then it is possible that B indicates to C that it accepts a > maximum number of ATM cells per frame equal to N1. > Subsequently, B could learn from A that A accepts a maximum > number of ATM cells per frame equal to N2. If N2 is smaller > than N1, there is a problem. B might have to repackage frames > it receives from C to make sure it doesn't exceed N2 cells in > the frames it forwards to A. > > Based on this example, it seems obvious to me that B has to > receive a PW setup message from A before it can forward it to > C and C has to receive a setup message from B before it can > forward it to D. In other words, there is a clear order. > Wei> Hi Peter, > > Agree with your observation. Even though the ordered setup > is a sensible > approach and makes life easier to establish a multi-segment > pseudowire, it's > still up to the stitching nodes, B and C in this case, to > decide what the > aggragated events should be to trigger its signaling. For > example, they need > other resources to get ready before start signaling and they can wait > indefinitely before start signaling. > Wei, This is perhaps another example where it makes sense to describe the problem to be solved before discussing solutions. In my view of the world, if you need a multi-segment PW from A via B and C to D, you can only achieve your goal if all four nodes are ready. I don't see why it makes sense to set up the segment between B and C if A or D are not ready yet. I could even go further: I would argue that node B doesn't even know that it is in the path from A to D, until it receives a setup message from A. To protect against network failures, node A should be able to decide on the best route to destination D and node B might not lie on that route. But again, let's formulate the problem first. Peter > Therefore, the ordered setup seems to be more of an > implementation specific > issue for the stitching nodes rather than an item to be standardized. > > ---Wei > > > > > Peter > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 10:19:12 -0500 Lines: 10 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 24 16:22:05 2004 Return-path: To: benjamin.niven-jenkins@bt.com In-reply-to: Your message of Mon, 23 Feb 2004 16:31:40 +0000. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > the general interworking of technologies such as FR, ATM, ethernet, SDH Certainly the interworking of these technologies with each other would be out of scope of the IETF. I think what is being discussed though is the interworking of one of these technologies, at a network boundary, with a PWE3-based emulation of itself. That's a bit more difficult to rule out based on abstract considerations of the IETF mission. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: richard.spencer@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 17:00:37 -0000 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Cc: X-From: pwe3-admin@ietf.org Tue Feb 24 18:05:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP66hXZ0bBacepLQlmRLe+EulS/hgACoJv8 To: , X-OriginalArrivalTime: 24 Feb 2004 17:02:10.0909 (UTC) FILETIME=[F15288D0:01C3FAF7] Content-Transfer-Encoding: base64 Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O PiA+IHRoZSBnZW5lcmFsIGludGVyd29ya2luZyBvZiB0ZWNobm9sb2dpZXMgc3VjaCBhcyBGUiwg QVRNLCBldGhlcm5ldCwgU0RIDQoNCj4gQ2VydGFpbmx5IHRoZSAgaW50ZXJ3b3JraW5nIG9mIHRo ZXNlICB0ZWNobm9sb2dpZXMgd2l0aCBlYWNoIG90aGVyICB3b3VsZCBiZQ0KPiBvdXQgb2Ygc2Nv cGUgb2YgdGhlIElFVEYuDQoNCj4gSSB0aGluayB3aGF0ICBpcyBiZWluZyBkaXNjdXNzZWQgdGhv dWdoIGlzIHRoZSBpbnRlcndvcmtpbmcgIG9mIG9uZSBvZiB0aGVzZQ0KPiB0ZWNobm9sb2dpZXMs IGF0IGEgbmV0d29yayBib3VuZGFyeSwgIHdpdGggYSBQV0UzLWJhc2VkIGVtdWxhdGlvbiBvZiBp dHNlbGYuDQo+IFRoYXQncyBhIGJpdCBtb3JlIGRpZmZpY3VsdCB0byAgcnVsZSBvdXQgYmFzZWQg b24gYWJzdHJhY3QgY29uc2lkZXJhdGlvbnMgb2YNCj4gdGhlIElFVEYgbWlzc2lvbi4NCg0KIA0K DQpXaHkgd291bGQgdGhlIGdyb3VwIHJlc3BvbnNpYmxlIGZvciB0aGUgKmVtdWxhdGlvbiogb2Yg YSBwYXJ0aWN1bGFyIG5ldHdvcmsgdGVjaG5vbG9neSwgYmUgYmV0dGVyIHN1aXRlZCB0byB3b3Jr IG9uIHRoZSBpbnRlcndvcmtpbmcgb2YgdGhhdCB0ZWNobm9sb2d5IHdpdGggYW4gImVtdWxhdGlv biBvZiBpdHNlbGYiLCB0aGFuIHRoZSBncm91cCBhY3R1YWxseSByZXNwb25zaWJsZSBmb3IgdGhl ICpkZXNpZ24gJiBkZXZlbG9wbWVudCogb2YgdGhhdCB0ZWNobm9sb2d5Pw0KDQogDQoNClJpY2hh cmQNCg0K From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: Re: PWE3 new WG items? PW QoS Date: Tue, 24 Feb 2004 12:32:00 -0500 Lines: 41 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Feb 24 18:35:06 2004 Return-path: To: pwe3@ietf.org Mail-Followup-To: Scott W Brim , pwe3@ietf.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter: See at the bottom. On Mon, Feb 23, 2004 04:12:48AM -0500, Busschbach, Peter B (Peter) allegedly wrote: > To be precise: I am advocating that RSVP is *one* cure for all these > problems, with the nice property that it exists today. Of course we > can define another solution to PW-splicing from scratch, but I think > it is preferable to use an existing protocol. > > Otherwise, I agree with you that we need to define the scope of the > problem before we can decide on a solution. On Mon, Feb 23, 2004 04:26:19AM -0500, Busschbach, Peter B (Peter) allegedly wrote: > Assume one wants to set up a multi-segment from A via B and C to D to > carry ATM traffic. Suppose that the segment between B and C is set up > independently from the other two segments. Then it is possible that B > indicates to C that it accepts a maximum number of ATM cells per frame > equal to N1. Subsequently, B could learn from A that A accepts a > maximum number of ATM cells per frame equal to N2. If N2 is smaller > than N1, there is a problem. B might have to repackage frames it > receives from C to make sure it doesn't exceed N2 cells in the frames > it forwards to A. > > Based on this example, it seems obvious to me that B has to receive a > PW setup message from A before it can forward it to C and C has to > receive a setup message from B before it can forward it to D. In other > words, there is a clear order. I was thinking of a different part of the problem. In the case you describe, where some entity has the intention of setting up a path de novo, your approach feels good, including the use of RSVP(+) for the critical points on the path to discover what resources are available and agree on what needs to be allocated. However, there are variables, including pre-existence of PSN tunnels and PWs (of various sorts, not just LSPs), whether the originator intends stitching to be involved in PW setup, how discovery is done, and so forth. Let's decompose the problem space a little more. Have a good time in Seoul ... Scott From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 13:00:43 -0500 Lines: 19 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: benjamin.niven-jenkins@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 24 19:04:03 2004 Return-path: To: richard.spencer@bt.com In-reply-to: Your message of Tue, 24 Feb 2004 17:00:37 +0000. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Why would the group responsible for the *emulation* of a particular > network technology, be better suited to work on the interworking of that > technology with an "emulation of itself", than the group actually > responsible for the *design & development* of that technology? I was only addressing the issue of whether the task was or was not clearly out of scope. Which of two groups is best suited to do the task is a different issue. However, there are many possible reasons why the group that did the emulation might be better suited to working on the emulation than the group that did the original technology. For instance, the group that did the original technology might have a poor understanding of the evolving environment, and might be very focused on a lot of obsolete and irrelevant things that needn't be maintained in the environment where the emulated technology runs. Further, if the interworking in question is going to affect what runs on the IP side (which seems likely, as no one will want to change the legacy side), then one may need to go where the IP expertise is. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 14:32:47 -0500 Lines: 11 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Feb 24 20:36:05 2004 Return-path: To: pwe3@ietf.org Mail-Followup-To: Scott W Brim , pwe3@ietf.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O On Tue, Feb 24, 2004 05:00:37PM -0000, richard.spencer@bt.com allegedly wrote: > Why would the group responsible for the *emulation* of a particular > network technology, be better suited to work on the interworking of > that technology with an "emulation of itself", than the group actually > responsible for the *design & development* of that technology? Forget the word emulation, we could spend a week or more on it alone :-). The basic point is pretty simple -- if the interworking implies requirements for IETF technology, including pseudowires, then it's a problem the IETF should pay attention to. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Mustapha Aissaoui Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 14:59:47 -0500 Organization: Alcatel Networks Corporaton Lines: 29 Sender: pwe3-admin@ietf.org References: <20040224193246.GG2652@sbrim-w2k01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 24 21:02:05 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Scott W Brim , Richard Spencer Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Scott and Richard, both the ATM Forum and IETF should be interested in this work. There are hopefully enough experts of both ATM and IP/MPLS who attend the PWE3 working group to have this work done here. I do not think it is worth debating which body should own it as long as there is a liaison and communication between the two bodies. If the IESG decides that this is out of scope of the IETF, then we should take it to the ATM Forum. Regards, Mustapha. ------------ Scott W Brim wrote: > On Tue, Feb 24, 2004 05:00:37PM -0000, richard.spencer@bt.com allegedly > wrote: > > Why would the group responsible for the *emulation* of a particular > > network technology, be better suited to work on the interworking of > > that technology with an "emulation of itself", than the group actually > > responsible for the *design & development* of that technology? > > Forget the word emulation, we could spend a week or more on it alone > :-). The basic point is pretty simple -- if the interworking implies > requirements for IETF technology, including pseudowires, then it's a > problem the IETF should pay attention to. > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 15:16:57 -0500 Lines: 5 Sender: pwe3-admin@ietf.org References: <20040224193246.GG2652@sbrim-w2k01> <403BAD33.A353D86@alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Feb 24 21:20:09 2004 Return-path: To: pwe3@ietf.org Mail-Followup-To: Scott W Brim , pwe3@ietf.org Content-Disposition: inline In-Reply-To: <403BAD33.A353D86@alcatel.com> User-Agent: Mutt/1.4.1i Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha: I wasn't debating ownership, just IETF scope. A lot of good work is done elsewhere, including the ATMF and many others. I like your optimism. swb From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ping Pan Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Tue, 24 Feb 2004 12:29:09 -0800 Lines: 32 Sender: pwe3-admin@ietf.org References: <20040223170534.GL1228@sbrim-w2k01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Feb 24 21:32:08 2004 Return-path: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Scott W Brim In-Reply-To: <20040223170534.GL1228@sbrim-w2k01> Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Scott W Brim wrote: > > My personal opinion: I think interworking had better be in scope or the > IETF will leaving it out rather soon. Issues in interworking of FR, > ATM, etc. are not IETF issues ... except where they imply requirements > for IETF technology, including pseudowires. This is the key. When customers hooking up Ethernet, ATM, SONET/SDH and Frame Relay interfaces into PE's, they use pseudowires to transport data over the backbone. To interwork among different interfaces, the idea is simply of having targeted LDP to carry proper information between PE's at PW setup and modification time. My personal view is to consider interworking as a "multi-protocol" extension to PWE3. There is no point of arguing what IETF should or should not do, because IETF also has a long history of evolving itself to support all sorts of data. > That includes this case. I > would not want the IETF to decide how to translate service parameters > between pseudowire client technologies (and it hasn't), Agree. > but > establishment and management of pseudowires goes far beyond that. > Finally, because of the IETF's long history with Ethernet, it should > continue to be involved there as well. > - Ping From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Wed, 25 Feb 2004 10:04:41 -0000 Lines: 63 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Wed Feb 25 11:07:10 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP7ER3mEICnSZwQQEakVrZa9zUezgAaV7Gw To: , , X-OriginalArrivalTime: 25 Feb 2004 10:04:42.0003 (UTC) FILETIME=[C96C8E30:01C3FB86] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Mustapha, > Mustapha Aissaoui wrote 24 February 2004 20:00 =20 > Scott and Richard, > both the ATM Forum and IETF should be interested in this=20 > work. There are > hopefully enough experts of both ATM and IP/MPLS who attend=20 > the PWE3 working > group to have this work done here. I do not think it is worth=20 > debating which > body should own it as long as there is a liaison and=20 > communication between > the two bodies. If the IESG decides that this is out of scope=20 > of the IETF, > then we should take it to the ATM Forum. NH=3D> I think its bigger than this. We want to see a stronger respect = for the functional architecture principles of G.805/809. There are many = reasons we want this, but a key one is that these func arch models form = the bedrock of the network management information models for our = NMS/OSS. So its quite important to us. Further, we believe that generic arch principles for client/server i/w = (aka network i/w) and peer-partition i/w (aka service i/w) should be = defined 1st irrespective of the specific technologies involved. The = arch principles are not the same in these 2 i/w cases. Further, these = relationships are affected by (i) the networking mode of the technology = considered, ie whether cl-ps, co-ps, or co-cs, and (ii) how well a given = technology is functionally specified. Just taking the simpler client/server case for now, this is what we = believe must hold here: (i) client and server layers must be independent in all aspects of the = data and control planes. This is required since the client and server = layer networks can be owned by different parties. (ii) the client (all aspects) must be transparent to the server layer. = Some folks also refer to this as 'the principle of minimum = intervention'.=20 (iii) defects detected at the trail termination point of the server = layer network must be mapped to a FDI (Forward Defect Indication), in = whatever syntax is relevent to the client, at the server->client = adaptation function and for all clients affected. This is to inform = client that the defect is not in their layer network and thus stops = alarm storms in clients. We don't believe the current PWE3 drafts on client/server relationships = meet the above requirements.....I can provide an extensive list of stuff = we feel is wrong here, and we have raised these issues on the lists in = the past but they have been ignored. The original driver for the PWE3 work was from SPs who did not have = native ATM, FR, etc technology networks but who, nevertheless, wanted to = offer their carriage as services to customers over either an IP or MPLS = server layer network. Well, that's OK I guess, but when it gets a bit = more serious such that MPLS (not PWs please note) is being touted as the = convergence technology for most SPs (inc BT) then (i) we want to make = sure MPLS is correctly/adequately functionally specified and (ii) that = the X/MPLS i/w relationships are correctly specified. In particular, we don't think any single SDO should try and claim = 'ownership' of this topic. And as noted, we want to start from a basis = of respecting G.805/809 func arch principles. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Wed, 25 Feb 2004 16:52:03 -0000 Lines: 37 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Wed Feb 25 17:54:06 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP3HAw95Z0XxvOnQzCcrJKZp1ZyvAEoIvug To: X-OriginalArrivalTime: 25 Feb 2004 16:52:03.0473 (UTC) FILETIME=[B1ACE810:01C3FBBF] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > For those of you who weren't at the last IETF, what I'm=20 > talking aabout > > is covered in draft-swallow-pwe3-spvc-iw-00.txt. > > > > The issue is that service providers which offer Frame Relay=20 > and ATM SPVC > > services would like a smooth means of migrating users to MPLS/PWE3. > > During the transition there will be the need to connect=20 > access circuits > > which have one end attached to the existing FR/ATM net and=20 > the other to > > a PWE3 PE. The providers would like a more elegant=20 > solution than just a > > static splice. This is needed to simplify configuration=20 > and operations > > and to provide robustness during the transition. Some providers are > > looking at transitions that will occur over a period of years. > > > > ...George > > I support this topic to become a part of the charter, as we=20 > have heard the > similar concerns from the carriers. >=20 As the justification for this work to be added to the PWE3 charter is = that 'service providers/carriers' are asking for it, why aren't the same = service providers/carriers voicing public support for the work on the = list? Where are the service provider/carrier requirements that dictated = the proposed solution (or do they remain in private like the SPs = themselves)? As stated previosuly, I am (and BT is) against this work being added to = the PWE3 charter. Ben From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Mustapha Aissaoui Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Wed, 25 Feb 2004 13:46:12 -0500 Organization: Alcatel Networks Corporaton Lines: 43 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF32C0@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: sbrim@cisco.com, richard.spencer@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Feb 25 19:49:06 2004 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: neil.2.harrison@bt.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, I believe the best place to do the overal architecture work is in ITU. What we are talking here about is the signaling interworking of PNNI/AINI and LDP for SPVCs mainly. This can be used in both the network interworking and the service interworking models as explained in draft-watkinson-l2vpn-pnni-psn-framework-00.txt. Mustapha. ------------ neil.2.harrison@bt.com wrote: > > Mustapha, > > Mustapha Aissaoui wrote 24 February 2004 20:00 > > > Scott and Richard, > > both the ATM Forum and IETF should be interested in this > > work. There are > > hopefully enough experts of both ATM and IP/MPLS who attend > > the PWE3 working > > group to have this work done here. I do not think it is worth > > debating which > > body should own it as long as there is a liaison and > > communication between > > the two bodies. If the IESG decides that this is out of scope > > of the IETF, > > then we should take it to the ATM Forum. > NH=> I think its bigger than this. We want to see a stronger respect for the functional architecture principles of G.805/809. There are many reasons we want this, but a key one is that these func arch models form the bedrock of the network management information models for our NMS/OSS. So its quite important to us. > > Further, we believe that generic arch principles for client/server i/w (aka network i/w) and peer-partition i/w (aka service i/w) should be defined 1st irrespective of the specific technologies involved. The arch principles are not the same in these 2 i/w cases. Further, these relationships are affected by (i) the networking mode of the technology considered, ie whether cl-ps, co-ps, or co-cs, and (ii) how well a given technology is functionally specified. > > Just taking the simpler client/server case for now, this is what we believe must hold here: > (i) client and server layers must be independent in all aspects of the data and control planes. This is required since the client and server layer networks can be owned by different parties. > (ii) the client (all aspects) must be transparent to the server layer. Some folks also refer to this as 'the principle of minimum intervention'. > (iii) defects detected at the trail termination point of the server layer network must be mapped to a FDI (Forward Defect Indication), in whatever syntax is relevent to the client, at the server->client adaptation function and for all clients affected. This is to inform client that the defect is not in their layer network and thus stops alarm storms in clients. > > We don't believe the current PWE3 drafts on client/server relationships meet the above requirements.....I can provide an extensive list of stuff we feel is wrong here, and we have raised these issues on the lists in the past but they have been ignored. > > The original driver for the PWE3 work was from SPs who did not have native ATM, FR, etc technology networks but who, nevertheless, wanted to offer their carriage as services to customers over either an IP or MPLS server layer network. Well, that's OK I guess, but when it gets a bit more serious such that MPLS (not PWs please note) is being touted as the convergence technology for most SPs (inc BT) then (i) we want to make sure MPLS is correctly/adequately functionally specified and (ii) that the X/MPLS i/w relationships are correctly specified. > > In particular, we don't think any single SDO should try and claim 'ownership' of this topic. And as noted, we want to start from a basis of respecting G.805/809 func arch principles. > > regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: reminder: QoS not currently in L3VPN charter Date: Thu, 26 Feb 2004 09:08:12 -0000 Lines: 67 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Thu Feb 26 10:11:24 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: reminder: QoS not currently in L3VPN charter Thread-Index: AcP77rQJBkIjdpMOR0KQVk7a402fVQAUxhaw To: , , X-OriginalArrivalTime: 26 Feb 2004 09:08:13.0315 (UTC) FILETIME=[10058D30:01C3FC48] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Ross Callon wrote 25 February 2004 22:23 =20 > At 10:59 AM 2/25/2004 -0800, Rick Wilder wrote: >=20 > >This is not to say the discussions of QoS here are not=20 > interesting, but currently out of > >charter.=20 > > > >Any proposal to expand the WG charter to include QoS would=20 > require a clear statement of > >requirements for VPN-specific QoS work. > > > >Rick >=20 > To expand a bit on Rick's comments. There has been other work in the > IETF over many years on QoS. In my reading of the recent=20 > discussion on=20 > the l3vpn working group mailing list, I noticed an=20 > interesting discussion. > However, I didn't notice anything that would suggest a=20 > solution specific to=20 > VPNs -- the same issues could be raised for other types of=20 > traffic going=20 > through an IP/MPLS Network.=20 >=20 > If there are VPN-specific aspects of QoS we could try to=20 > understand what=20 > these are, and then have discussions regarding whether to extent the=20 > working group charter. If the QoS issues are applicable to IP=20 > networks in > general, then to me it would appear to be difficult to argue=20 > why these=20 > should be in this working group rather than elsewhere in the IETF.=20 >=20 > Ross Hi Ross, Not sure if you are referring above to my recent posting = (responding to questions from Chris Lewis) on the thread 'RE: End to end = QoS guarantee for users in VPN'? But yes, I agree with you that QoS = (whatever that really means....since I think different people have = different interpretations of QoS) is not specific to VPNs. But in = general the solutions required for private network services are not the = same as those for public network services, as I attempted to explain in = my recent posting, eg the difference between an 'urgency' and = 'importance' semantic (which is not absolute), and is not just a 'pkt = attribute' in any case, and the implications of BW sharing between QoS = classes on an operator's ability to create fair/meaningful and = appropriately priced services. We (in BT) are having a real dilemma at present in trying to work out = just 'who' the target audience is for certain work items in IETF.....esp = in PWE3; please see the PWE3 thread 'RE: [PWE3] New PWE3 Charter Items: = SPVC Interworking'. I have taken the liberty of copying-in the PWE3 WG = on this mail for their information. In our view the requirements for the Internet as-is are very different = from those of an operator like BT. Not sure how to sort this out.....but we for sure need a more = rigorous/complete and more service-oriented approach to dealing with = certain topics (this being one of them) than has been done to date in = IETF......it seems (to us at least) that the IETF, given its current = modus operandi and assuming this does not change, may not be the right = place to do this sort of work. regards, Neil BT/GS/CTO From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Thu, 26 Feb 2004 12:06:49 -0000 Lines: 206 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , , X-From: pwe3-admin@ietf.org Thu Feb 26 13:09:22 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP7z7R9+4sFjceQRVa4Mdw6f9596wACItpg To: X-OriginalArrivalTime: 26 Feb 2004 12:06:50.0421 (UTC) FILETIME=[03EA2650:01C3FC61] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi Mustapha, Mustapha Aissaoui wrote 25 February 2004 18:46 > Neil, > I believe the best place to do the overal architecture work is in > ITU. NH=3D>I agree, as this is where the func modelling expertise resides. = G.805/809 are much more important than some people realise .....at least = judging from the reaction I often notice when folks come across this = stuff for the first time. Our NMS/OSS experts recognise these are the = backbone of good management information modelling, and thus NE/NMS = specifications and re-use of OSS components, eg see the work in TMF that = is based on G.805/809. However, G.805/809 are generic for the 3 = networking modes and technology specific derivatives are produced as = required. One of my colleagues has the editorship for MPLS (which is = proving a very interesting exercise) and Maarten Vissers (now with you = guys in Alcatel) is doing ethernet. > However,=20 > What we are talking here about is the signaling interworking of > PNNI/AINI and LDP for SPVCs mainly. This can be used in both the > network interworking and the service interworking models as > explained in draft-watkinson-l2vpn-pnni-psn-framework-00.txt. NH=3D> In simple client/server i/w (aka network i/w) the control-planes = of both the client and the server layers are independent with no i/w at = all. Further, the data-plane of the client is the *same* at both ends = and must be *transparently* carried over the server data-plane....or = that is what should happen at least! =20 In peer-partition i/w the arch rules are different......below represents = the current consensus of folks in BT on this....but this needs further = work as you will see, and we are addressing this: - all the CI (characteristic information) of each peer server layer = trail data-plane should be terminated at the iwf.....so that means no = OAM functions and no 'features' are mapped between peer server layer = data-plane partitions. This is important for many reasons. For = example: * We may wish to interwork between 2 technologies belonging to = different modes, eg ethernet (cl-ps) and ATM (co-ps) say (but you can = think of many other pairs). There is clearly no signalling i/w in this = example. * There is no 'congestion semantic' in MPLS or ethernet but there is = in FR and ATM (though these are quite different in syntax). So there is = no possible general 'feature' i/w here. * Because PWE3 does not recognise MPLS as a layer network in its own = right we don't have i/w with MPLS LSPs directly but rather a forced = client/server i/w with PWs on a client specific basis. This is a = mistake in our view for several reasons, but that is what has happened = and is now something some folks are going to have to live with. This = means there will be (at least) O(N^2) possible mapping relationships in = the data-plane...PW compression of clients makes this larger as well as = creating additional defect management issues at the iwf for the = functional arch changes this results in. Further, the so-called = 'port-mode' in some of these PW cases means absolutely nothing in Func = Arch terms and will be very problematical to manage correctly. In the = case of OAM there *may* be some semantic relationships of *some* = functions; but even if there is, in most cases the syntax will be very = different (the exception to this is ATM I.610 OAM and MPLS Y.1711 OAM = where, because functional convergence of the base OAM for defect = detection/handling was considered early on, one can get = simple/harmonised semantic and syntax mappings....see Y.1712). However, = this is a special case of arch compliant ATM/MPLS OAM i/w, and the = correct general method of defect handling in our view is as defined in = the next bullet. Further, note that even if one could relay a defect = mapping via some FDI semantic from one peer partition to another peer = partition and so on down the chain, when one gets to the last partition = you still need to 'do something' with this wrt the the higher layer = entity, so one might have as well have done it right at the outset in = the peer server layer partition where the defect originated. - defects occuring in any server layer partition and detected at its = data-plane trail termination point must be mapped to the appropriate = client layer data-plane FDI signal. Note that this client layer = data-plane is common to all the lower peer layer partitions.....in other = words this has the previous simple client/server relationship to each of = lower server layer partitions. Now a clear understanding/specification = of what this common end-end higher entity is is a critical issue....and = this should be nailed down 1st, eg AAL5 + rfc2684 is a possible = candidate. But AALs are missing even basic OAM functionality.....but so = are all other possible candidates here. Seems there is some work to do = IMO on this issue. - the nature of the control-plane i/w between the peer server layer = partitions is a function of the 2 modes involved, the addressing, = signalling (if present) and routing protocols (if present) used in each = peer partition and the i/w policy (in theory different parties could be = involved each side of the iwf). In other words, this starts to look = very much like an I-NNI or an E-NNI specification. Clearly having a = greater degree of functional convergence here can be beneficial (eg same = base signalling protocol in each peer server partition say when this is = appropriate). Note also the crucial relationship between the = peer-partition OAM spans and the nature of the signalling. This needs = further study IMO as its corect handling is not immediately obvious to = me.....though the principle wrt to data-plane CI termination at the iwf = noted above is correct in our view and should be retained (else its = going to become a right lash-up). Aside - We would expect any vendor who is serious about doing this stuff = right to provide us with solutions where the internal/sensitive = control-plane protocols (and for sure management-plane protocols) are = logically OOB wrt to data-plane carrying the traffic....so please don't = overlook that. And this is one reason why Ben said (in an earlier mail) = we'd rather this work was not done in IETF as we simply don't understand = *who* this stuff is aimed at...is is the Internet (but seems no fit = here)? ISPs (more likely)? or operators like BT (though seems not on = evidence to date)? If it is us however, then please start with = G.805/809 and work from that. This is not meant to be disrespectful to = IETF, its just that our requirements are not the same as the Internet or = ISPs. Hope folks can understand that. So I don't agree with you if you think the same arch model (even just = for the signalling component) is applicable to these 2 cases, and I also = don't think its right to home-in on the signalling facet without a = proper understanding of how the other facets (like defect = detection/handling in the data-plane) relate to this.....though I can = start to imagine someone cooking-up some awful hybrid of client/server = data-plane i/w with some horrible OAM mapping lash-up and peer = control-plane i/w if we are not vigilant here. This is why I'd like to = get the arch rules for this stuff agreed 1st before folks rush off into = solution mode. Please draw out the func models of what you are = proposing here, we for sure will when defining how we want this stuff to = i/w. However, I'll go and have a look what the draft you mentioned actually = says now and, after consultation with folks here, let you know what we = think of it. regards, Neil >=20 > Mustapha. > ------------ > neil.2.harrison@bt.com wrote: > >=20 > > Mustapha, > > > Mustapha Aissaoui wrote 24 February 2004 20:00 > >=20 > > > Scott and Richard, > > > both the ATM Forum and IETF should be interested in this > > > work. There are > > > hopefully enough experts of both ATM and IP/MPLS who attend > > > the PWE3 working > > > group to have this work done here. I do not think it is worth > > > debating which > > > body should own it as long as there is a liaison and > > > communication between > > > the two bodies. If the IESG decides that this is out of scope > > > of the IETF, > > > then we should take it to the ATM Forum. > > NH=3D> I think its bigger than this. We want to see a=20 > stronger respect for the functional architecture principles=20 > of G.805/809. There are many reasons we want this, but a key=20 > one is that these func arch models form the bedrock of the=20 > network management information models for our NMS/OSS. So=20 > its quite important to us. > >=20 > > Further, we believe that generic arch principles for=20 > client/server i/w (aka network i/w) and peer-partition i/w=20 > (aka service i/w) should be defined 1st irrespective of the=20 > specific technologies involved. The arch principles are not=20 > the same in these 2 i/w cases. Further, these relationships=20 > are affected by (i) the networking mode of the technology=20 > considered, ie whether cl-ps, co-ps, or co-cs, and (ii) how=20 > well a given technology is functionally specified. > >=20 > > Just taking the simpler client/server case for now, this is=20 > what we believe must hold here: > > (i) client and server layers must be independent in all=20 > aspects of the data and control planes. This is required=20 > since the client and server layer networks can be owned by=20 > different parties. > > (ii) the client (all aspects) must be transparent to the=20 > server layer. Some folks also refer to this as 'the=20 > principle of minimum intervention'. > > (iii) defects detected at the trail termination point of=20 > the server layer network must be mapped to a FDI (Forward=20 > Defect Indication), in whatever syntax is relevent to the=20 > client, at the server->client adaptation function and for all=20 > clients affected. This is to inform client that the defect=20 > is not in their layer network and thus stops alarm storms in clients. > >=20 > > We don't believe the current PWE3 drafts on client/server=20 > relationships meet the above requirements.....I can provide=20 > an extensive list of stuff we feel is wrong here, and we have=20 > raised these issues on the lists in the past but they have=20 > been ignored. > >=20 > > The original driver for the PWE3 work was from SPs who did=20 > not have native ATM, FR, etc technology networks but who,=20 > nevertheless, wanted to offer their carriage as services to=20 > customers over either an IP or MPLS server layer network. =20 > Well, that's OK I guess, but when it gets a bit more serious=20 > such that MPLS (not PWs please note) is being touted as the=20 > convergence technology for most SPs (inc BT) then (i) we want=20 > to make sure MPLS is correctly/adequately functionally=20 > specified and (ii) that the X/MPLS i/w relationships are=20 > correctly specified. > >=20 > > In particular, we don't think any single SDO should try and=20 > claim 'ownership' of this topic. And as noted, we want to=20 > start from a basis of respecting G.805/809 func arch principles. > >=20 > > regards, Neil >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Toby Smith Subject: Comment on Generalized ID FEC format. Date: Thu, 26 Feb 2004 10:11:46 -0500 Lines: 87 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Feb 26 16:13:10 2004 Return-path: To: lmartini@cisco.com, nna@level3.net, giles.heron@tellabs.com, erosen@cisco.com Content-Transfer-Encoding: 7bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Hi guys, I'd like to propose a small change to the current Generalized ID FEC format as specified in draft-ietf-pwe3-control-protocol-05.txt. The current format is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 |C| PW Type |VC info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...and includes the comment: If a particular application does not need all three of these sub- elements, it may simply omit the ones it does not need. I'd like to propose that we get rid of the AGI, SAII and TAII tags and simply assign them positions: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 129 |C| PW Type |VC info Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AGI Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAII Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TAII Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value (contd.) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Interface Parameters | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The motivation here is two-fold. First, we don't need to wait around for anyone to assign values the AGI, SAII and TAII bytes (admittedly, not a compelling reason). Second, it makes the parsing of this FEC much simpler and less prone to ID collisions. With the current format, one needs to look ahead one byte in the FEC to determine what's coming up next. While that's not the worst thing in the world by itself, the problem arises when parsing reaches the interface parameters, which also begin with a one-byte type field. If the AGI, SAII or TAII values conflict with any of the present or future interface parameter values, parsing confusion ensues. Does anyone have objections to this proposed change? Zero-length AGI, SAII and TAII values are still supported. The only thing that changes is that the parsing is less error-prone, and we lose the ability to completely omit one or more of these values. (Although the way in which value of omitting the value is substantially different from having a zero-length one is unclear to me anyway...). Regards, Tob From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Peter Willis Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 09:24:21 +0000 Lines: 64 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Fri Feb 27 10:27:47 2004 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: benjamin.niven-jenkins@bt.com To: pwe3@ietf.org In-reply-to: Your message of "Mon, 23 Feb 2004 16:31:40 GMT." Content-Transfer-Encoding: 8bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Colleagues, Just to reinforce this message. It is clear that service interworking and even PWE3 is clearly outside the scope of the IETF. Clear in that we've already seen the pecuilar requests for PWE3 to consider congestion management. There are lots of very good engineers attend the PWE3 WG who also attend other standards bodies and forums. It seems that the work of these good engineers is being constrained by the IETF "constitution". I think SPVC Interworking is a specific example of an aspect of PWE3 that would be done better in another standards body or forum. Peter Willis, Office of BT Group CTO. > > I'd like to see us add SPVC interworking to our charter. > > > > In talking to a fair number of service providers I've gotten > > the message > > that deploying PWE3 is a bit of a non-starter without a reasonable > > migration plan. I think we would be foolish to leave this > > piece to some > > other organization or to vendor proprietary means. > > > > ....George > > We have discussed the topic of service interworking extensively within BT, and we agree that it is an important facet of a service providers migration plan towards a converged multi-service core network. Service interworking must consider all aspects of the data-plane, control-plane and NMS/OSS for all the technologies considered (and it is therefore more far-reaching than just S-PVC considerations). > > However, we do not believe the IETF is the appropriate forum for conducting this work. Our reasons for saying this are that draft-alvestrand-ietf-mission-00.txt states: > "The mission of the IETF is to produce high quality, relevant technical and engineering documents that influence the way people design, use and manage the Internet in such a way as to make the Internet work better." > > It then defines the scope of the Internet as: > "protocols and practices for which secure and scalable implementations are expected to have wide deployment and interoperation on the Internet, or to form part of the infrastructure of the Internet." > > We therefore believe that the general interworking of technologies such as FR, ATM, ethernet, SDH, etc: > - is not applicable to the Internet, > - will not have wide deployment on the Internet, and > - will not form part of the infrastructure of the Internet > > Therefore the topic of service interworking is out of scope of the IETF and thus also out of scope of the PWE3 WG. > > Ben > > -- > Ben Niven-Jenkins > IP Networking Specialist, BT Exact > > e-mail: benjamin.niven-jenkins@bt.com > tel: +44(0) 1473 648225 > fax: +44(0) 1473 620109 > > pp34/161 B81 Callisto House, Adastral Park, Martlesham, Ipswich IP5 3RE, UK > > BT Exact is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Peter Willis Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 09:28:51 +0000 Lines: 11 Sender: pwe3-admin@ietf.org References: <200402241800.i1OI0h0K024393@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: richard.spencer@bt.com, benjamin.niven-jenkins@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 27 10:32:03 2004 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: erosen@cisco.com In-reply-to: Your message of "Tue, 24 Feb 2004 13:00:43 EST." <200402241800.i1OI0h0K024393@rtp-core-2.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > Further, if the interworking in question is going to > affect what runs on the IP side (which seems likely, as no one will want to > change the legacy side), then one may need to go where the IP expertise is. I see plenty of IP expertise in the other standards bodies and forums. Indeed Cisco sends many of its people to the other standards bodies and forums - are you saying those people Cisco send to both the IETF and the other bodies are not IP experts? Peter Willis, Office of the BT Group CTO. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Peter Willis Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 09:37:26 +0000 Lines: 18 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-From: pwe3-admin@ietf.org Fri Feb 27 10:40:12 2004 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: benjamin.niven-jenkins@bt.com To: pwe3@ietf.org In-reply-to: Your message of "Wed, 25 Feb 2004 16:52:03 GMT." Content-Transfer-Encoding: 8bit Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > > I support this topic to become a part of the charter, as we > > have heard the > > similar concerns from the carriers. > > It may be that some carriers have expressed requirements for SPVC interworking to be addressed (but why aren't they making their opinion known on this list?). I would guess that these carriers have not specifically asked for SPVC interworking to be developed in the IETF PWE3 WG. I have heard several carriers express the opposite - that they prefer the standards not to be developed in the IETF. It is perhaps a reflection of these carriers' sentiments that we are not hearing their voices on the PWE3 list? Peter Willis, Office of the BT Group CTO. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Peter Willis Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 09:54:14 +0000 Lines: 16 Sender: pwe3-admin@ietf.org References: <200402241800.i1OI0h0K024393@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Fri Feb 27 10:57:08 2004 Return-path: X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI] To: erosen@cisco.com To: richard.spencer@bt.com, benjamin.niven-jenkins@bt.com, pwe3@ietf.org In-reply-to: Your message of "Tue, 24 Feb 2004 13:00:43 EST." <200402241800.i1OI0h0K024393@rtp-core-2.cisco.com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > For instance, the group that did the > original technology might have a poor understanding of the evolving > environment, and might be very focused on a lot of obsolete and irrelevant > things that needn't be maintained in the environment where the emulated > technology runs. This sort of attitude is why I would be unhappy with the IETF PWE3 WG dealing with SPVC interworking. How does the PWE3 WG know what is obsolete and irrelevant in the legacy services carriers wish supported? The whole converged network story becomes very weak and useless if the customers see the services change (or at least see those services become worse). I don't want an emulation technology I want a network convergence technology. Peter Willis Office of the BT Group CTO. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Monique Morrow (mmorrow)" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 11:27:13 +0100 Lines: 48 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: , , , "Eric Rosen (erosen)" X-From: pwe3-admin@ietf.org Fri Feb 27 11:32:09 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP9FPJ+znA2HxhlT4WTAX5v7uzTnAABLypg To: "Peter Willis" X-OriginalArrivalTime: 27 Feb 2004 10:26:16.0046 (UTC) FILETIME=[218F58E0:01C3FD1C] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter, You and I know that this assertion is untrue; however, I do see a requirement to clarify the group's working scope in this context. Currently, there are service providers who are implementing pseudowire mechanisms and would like to extend capabilities to network interworking constructs. Actually these carriers are more concerned about providing a resolution to their problem and less concerned as to which standards body should own it. =20 Once again, I do agree that clarity is required as network services evolve. Regards, Monique -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Peter Willis Sent: 27 February 2004 10:29 To: Eric Rosen (erosen) Cc: richard.spencer@bt.com; benjamin.niven-jenkins@bt.com; pwe3@ietf.org Subject: Re: [PWE3] New PWE3 Charter Items: SPVC Interworking=20 > Further, if the interworking in question is going to > affect what runs on the IP side (which seems likely, as no one will want to > change the legacy side), then one may need to go where the IP expertise is. =20 I see plenty of IP expertise in the other standards bodies and forums. Indeed=20 Cisco sends many of its people to the other standards bodies and forums - are=20 you saying those people Cisco send to both the IETF and the other bodies are=20 not IP experts? Peter Willis, Office of the BT Group CTO. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Chris Metz Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 06:32:43 -0800 Lines: 35 Sender: pwe3-admin@ietf.org References: <3C775706078CA347A8653E03E14691060318A210@xbe-ams-313.cisco .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Peter Willis" , , , , "Eric Rosen (erosen)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 27 15:39:05 2004 Return-path: X-Sender: chmetz@mail1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Monique Morrow (mmorrow)" In-Reply-To: <3C775706078CA347A8653E03E14691060318A210@xbe-ams-313.cisco .com> Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Couple of comments on this subject: - One could argue there is precedence. IETF has been, by necessity recognizing and working with non-IP encaps and even signaling. Recall Classical IPoATM (1577/2225) where routers interacted with ATMARP servers to move ATM addresses around so that an SVC could be setup. We did it because operators ran IP and they wanted to dynamically support IP connectivity over SVCs. - w/ spvc interworking we again have an ATM signaling message hitting a router where it is terminated. The router then processes this message and uses PWE3 protocols (not ATM protocols) to complete the setup that supports the service the operator requires. - You see the same faces at the different standards body meetings and there is both formal and informal cross-pollination of ideas which is good. - IETF does have too narrow a constitution. We need to recognize that the Internet and its underlying protocol machinery is and will do more then just move IP packets, it is moving bits that are part of revenue-generating services (L3, L2, voice, whatever) offered by providers. PWE3 whether we like it or not is a fundamental building block of this Internet bit-moving, money-making, convergence machine :-) - We want to get it right. To that extent, those working on PWE3 should be "forced" (bad choice of words, I know, how about encouraged) to understand the critical aspects of what is required to support a L2 service ... so that it works as well as it can with the PWE3 stuff. I can appreciate the arguments that say spvc iw does not belong in the IETF. But I also want to make sure that those building PWE3 boxes and the operators who are and will deploy it have a solution that works. Let's do it in PWE3. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: benjamin.niven-jenkins@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 14:55:25 -0000 Lines: 33 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: X-From: pwe3-admin@ietf.org Fri Feb 27 15:58:04 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP9PprHtnRecldvSjC/6czEj3xW0QAAObbw To: X-OriginalArrivalTime: 27 Feb 2004 14:55:27.0529 (UTC) FILETIME=[BC981190:01C3FD41] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris, > - You see the same faces at the different standards body=20 > meetings and there=20 > is both formal and informal cross-pollination of ideas which is good. > - We want to get it right. When migrating to a multi-service core a service provider has to be = certain that the solution they are deploying is 'right' and 'correct', = as most of their business will rely on that multi-service core. Any = problems with the migration path deloyed, or any additional opex = introduced by unnecessary complexity or violation of defined networking = architectural principles (i.e. G.805/G.809) will in the long run cost = the service provider dearly. For e.g. (and I don't want to digress into a debate on this) managing a = MPLS network is expensive and arguably more expensive than it should = really be. IMO this is in some part due to network architectural = violations and the fact that things like OAM were not = considered/designed in from day 1. IMO, the issue is not that the IETF does not have the technical ability = to address the problem, but that the IETF's consitution/modus operandi = does not allow/encourage solutions to these sorts of problems that are = 'right' and 'correct' straight out of the box so that they address the = requirements of service providers (particularly traditional telco = service providers like BT). Ben From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 10:38:02 -0500 Lines: 17 Sender: pwe3-admin@ietf.org References: Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: richard.spencer@bt.com, benjamin.niven-jenkins@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Feb 27 16:41:05 2004 Return-path: To: Peter Willis In-reply-to: Your message of Fri, 27 Feb 2004 09:28:51 +0000. User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O > I see plenty of IP expertise in the other standards bodies and forums. It's one thing for an organization to have a smattering of experts in some subject, it's quite another for it to be a center of expertise in that subject. > are you saying those people Cisco send to ... the other bodies are not IP > experts? Heavens. Of course everybody from Cisco is an IP expert! :-) Unfortunately, the presence of people from Cisco is not a sufficient condition for an organization's being a center of IP expertise. > Office of the BT Group CTO :-) From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Fri, 27 Feb 2004 18:50:17 -0500 Lines: 42 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: sbrim@cisco.com, richard.spencer@bt.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat Feb 28 00:53:05 2004 Return-path: To: "'neil.2.harrison@bt.com'" , mustapha.aissaoui@alcatel.com X-Mailer: Internet Mail Service (5.5.2657.72) Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Neil, I hope that you can help me understand what the practical implictions are of some of your generic statements. Please see below. Peter > > NH=> In simple client/server i/w (aka network i/w) the > control-planes of both the client and the server layers are > independent with no i/w at all. Mustapha's email addressed control plane interworking between ATM and MPLS. In that context, how should I interpret your statement? Are you saying that the only valid way of carrying ATM over MPLS is the following: establish a Pseudo Wire that carries multiple VPs in such a way that ATM signaling and routing information is carried transparently over that PW and the establishment of new VPs or VCs through that PW should be done in such a way that it doesn't require any additional signaling in the MPLS plane? This would exclude any form of 1-1 encapsulation where VC or VP setup necessarily triggers PW setup. > * Because PWE3 does not recognise MPLS as a layer > network in its own right we don't have i/w with MPLS LSPs > directly but rather a forced client/server i/w with PWs on a > client specific basis. This is a mistake in our view for > several reasons, but that is what has happened and is now > something some folks are going to have to live with. This > means there will be (at least) O(N^2) possible mapping > relationships in the data-plane As a generic statement this sounds reasonable, but when you look at the specifics of existing protocols, I don't think it holds. The MPLS-FR Alliance has recently examined Service Interworking in-depth. One of the conclusions was that you can't do generic (i.e. payload-independent) service interworking between Ethernet on the one hand and Frame Relay or ATM on the other. (This was explained in detail in a contribution by Rao Cherukuri and Ali Sajassi.) As a result, the MPLS-FR Alliance decided that Service Interworking can only be done in very specific cases: 1) Between Frame Relay and ATM, according to FRF.8 2) In case of end-to-end transport of Ethernet traffic (i.e. where ATM and FR use bridge-mode encapsulation) 3) In case of end-to-end transport of IP traffic (i.e. where ATM and FR use routed-mode encapsulation) Of these, (2) can hardly be considered as Service Interworing in the traditional sense of the word. It is essentially a variant of network interworking of Ethernet over ATM or FR. (3) is more complicated due to IP specific issues that have been identified by Himanshu Shah and Ali Sajassi in earlier drafts, but still it is not Service Interworking in the traditional sense of the word. The same holds for MPLS: it would be possible to define SI between FR and MPLS or ATM and MPLS. However, it is not possible to define generic (payload-independent) Service Interworking between Ethernet and MPLS. Therefore, your statement about the service interworking between N different protocols reduces to a statement about Frame Relay and ATM only. For N=2, it seems that PW emulation of ATM (or FR) over MPLS in conjunction with FRF.8 is a more pragmatic approach than the alternative that you propose: SI between ATM and MPLS followed by SI of MPLS to FR. Am I missing something? From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Sat, 28 Feb 2004 15:39:44 -0000 Lines: 174 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , , , , X-From: pwe3-admin@ietf.org Sat Feb 28 16:44:10 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP9P4qvLzUySJ9xSf6cFC+HQEsrcgAmlQ3w To: , X-OriginalArrivalTime: 28 Feb 2004 15:39:44.0914 (UTC) FILETIME=[16EE9720:01C3FE11] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Chris, Chris Metz observed 27 February 2004 14:33 > - IETF does have too narrow a constitution. NH=3D> I am not sure IETF has a useful constitution at all these days. = IMO (i) 'rough consensus and running code' and (ii) '1 man/woman 1 vote' = worked fine back in the 60s/70s when the Internet was still a big = experiment. But we operators can't afford 'rough consensus and running = code', we need network solutions that are properly architected up-front. = IETF does stds after stuff has been built. Further, if one is a = dominant vendor in that environment, then it could be argued that the = IETF modus operandi starts to look more like a 'stds laundering = service'. > - We want to get it right. NH=3D> That is not the impression we get. We get the impression of = lumbering from one kludge to the next. > To that extent, those working on=20 > PWE3 should be=20 > "forced" (bad choice of words, I know, how about encouraged)=20 > to understand=20 > the critical aspects of what is required to support a L2=20 > service ... so=20 > that it works as well as it can with the PWE3 stuff. NH=3D> You make the assumption here that PWE3 is already 'right'. It's = not. However, PWE3 stuff per se is not the real problem....it is a = symptom of a deeper problem.....see later. >=20 > I can appreciate the arguments that say spvc iw does not=20 > belong in the=20 > IETF. > But I also want to make sure that those building PWE3=20 > boxes and the=20 > operators who are > and will deploy it have a solution that works. NH=3D> So do we.....so let's start with the right architectural mindset. Now let me try and explain why you have seen certain views expressed by = my colleagues here in BT on this thread....some of whom, it has to be = said, would prefer the solution that PWE3 was shut down: - PWE3 is a symptom of a deeper issue.....MPLS is simply not IP. Just = like GMPLS (eg SDH) is not MPLS. IP uses a cl-ps forwarding paradigm = (ie each pkt must have network significant DA/SA), MPLS uses co-ps = forwarding (ie pkts only contain a link-connection signficant label) and = GMPLS uses co-cs forwarding (ie fixed BW labelled slots in = time/frequency/space). If MPLS does not offer something different to IP = then why on earth do we need it? - A mp2p construction and a PHP 'feature' breaks the arch rules of the = co-ps mode....that is just a fact. Add proprietary ECMP to the brew and = one has now created a complex set of both technical and commercial = traffic/fault/QoS problems for operators to try and deal with......and = if any of you saw my recent posting (originally on the l3vpn list) to = Chris Lewis regarding QoS in VPNs I explained some of the additional = issues that need to be considered here. Sure you can do mp2p and PHP = but this does not make them a sensible thing to do. Nearly all the = problems with MPLS stem from these arch violations of the co-ps mode = (though there are also some functional deficiences in MPLS as-is...see = later) If you want true any-any behaviour and if similiar less-strong = traffic/perf-SLAs are acceptable then use a proper IP cl-ps server layer = since this does not suffer from the problems LDP does. When we use a = co-ps mode we should ensure it adds real value and not just problems. = In any case, we must have conformance to G.805/809 func arch = requirements, as ultimately these determine the efficacy of the = management information models that one creates for a given technology. I = can point you at our NMS/OSS folks if you want chapter/verse on why this = is so critically important to us. - MPLS is not singular, ie each different method of signalling LSPs = creates different MPLS networks. MPLS has no consistent access point = addressing.....and these don't belong to the IP layer network even if = they are based on the same v4 (or v6) format. To illustrate this, = observe that one cannot 'legally' connect a LDP LSP access point to a = RSVP-TE LSP access point.....though one can now have misconnectivity = defects between such LSPs please note. This is no different, in = principle, to observing that one cannot connect a VC_4 access point to a = VC_12 access point in SDH.....they simply belong to different layer = networks. - It should be a no-brainer requirement for a serious network operator = that all internal/sensitive control and management protocols must be = logically (at least) OOB wrt to the customer traffic in the core = network. This aspect seems not to have been considered at all for MPLS. - The original intent of the PWE3 work was to allow a SP who was not = able to offer native ATM and FR services to get a slice of the ATM and = FR market.....the remit has expanded since then. It was not written to = facilitate network convergence *from* FR, ATM to MPLS for operators like = BT.....noting that this is not even true any longer as the convergence = seems to be to PWs (not MPLS) and these are not the same thing....see = later. - Since MPLS is not the same as IP, then there is no forced requirement = for the XoverMPLS and XoverIP adaptation functions to be the same. = Further, if we did XoverSDH for arguments sake, this would also require = a different adaptation. - Most, if not all, the fields in the Martini CW are serving no useful = purpose. Let me elaborate on this (I will ignore the ECMP hack here, = save to note this is also a consequence of breaking the arch rules, ie = load-spreading should be constrained to lie within a single layer = network). If one compresses a client one loses client layer transparency. This = creates management problems. If one drew out the G.805 func arch of = what is going one here one would see artifical/partial trail termination = functions created at the i/w point (and there are varying spins on this = depending on the client involved and the degree of compression being = used). When folks draw 'cloud diagrams' however they seem to overlook = the fact that there is also a similar C/S relationship between MPLS (or = whatever) and some underlying server layer like SDH, ie in G.805 terms, = 'a client layer link-connection is formed by trails in a server layer'. = Fortunately the C/S relationships here respect the arch rules, so folks = forget about them and they are taken for granted.....esp the fact that = the server layer has well-defined and independent (of the client) OAM = and defect handling, though this is invariably heavily relied on. In = principle however, the C/S relationhip between MPLS (as a client) say = and SDH (as a server) is no different to that between ATM and MPLS = say....and so the same arch rule should be used, ie G.805. Seq Nos are not required in an architecturally valid co-ps technology. = Moreover, they should not even occur in a generalised adaptation = function (cf RTP and AAL1 which are *specific application* adaptation = functions). However, if Seq Nos remain then they cannot be left = 'open-ended' wrt behaviour under persistent abberation, ie a defect = condition must be specified with entry/exit criteria and consequent = actions. And as a more general observation here, there are no defects = specified in any IETF drafts/rfcs for any of the flavours of = MPLS....this may be consistent with the IETF mindset (ie 'we don't do = services') but this is unacceptable to us. Please see Y.1711 for what = we want here. The 'port-mode' that appears in some adaptations for some clients has no = architectural meaning. This will create fault management problems, eg = one cannot map a server layer defect to the appropriate FDI of all/each = of the clients supported. It should be removed from wherever it occurs. - PWs are not a sensible convergence network solution for = operators......but that is where PWE3 seem to be heading now, ie a PW = ignores its underlying transport....which can be IP (cl-ps) or MPLS = (co-ps). This is not acceptable as they have (or at least should have, = if arch compliant) different behaviours. - A PW is a X/IP or X/MPLS client->server adaptation function.....it is = *not* a networked entity whereas an LSP is. Further, if 2 MPLS networks = form a client/server (C/S) relationship and each network is owned by a = different party, it is clear we have an LSPoverLSP case and not a = PWoverPW case. A key corollary of this is that all the stuff that = defines a layer network must be associated with the LSP entity and *not* = the PW enity, eg OAM, signalling, etc. - we need a simple adaptation to LSPs for the general C/S case. The PID = word could be used as a basis for this and the Martini CW deprecated. =20 - We know precisely what we require for C/S i/w.....this is implicitly = embodied in G.805/809 already. We do not as yet have any agreed arch = rules for peer-partition i/w. We need these agreeing 1st before = embarking on specific solutions. See my recent response to Mustapha = Aissaoui on this where we give our best current view on what this should = be. I hope you can now see why we don't regard PWs as a suitable convergence = solution. There are arch problems with PWs per se, but there are also = more fundamental arch problems with MPLS. These things need fixing in = our view, else it would seem that MPLS (not PWs) will not be able to = assume a core convergence role that so many folks hoped it = would......and IMO that would be a real pity and a lost opportunity. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: New PWE3 Charter Items: SPVC Interworking Date: Sat, 28 Feb 2004 15:39:37 -0000 Lines: 180 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: , , X-From: pwe3-admin@ietf.org Sat Feb 28 16:44:12 2004 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] New PWE3 Charter Items: SPVC Interworking Thread-Index: AcP9jNjLnMCEvJD8R7y29+UHBfSObQAdYS0Q To: , X-OriginalArrivalTime: 28 Feb 2004 15:39:38.0133 (UTC) FILETIME=[12E3E450:01C3FE11] Content-Transfer-Encoding: quoted-printable Errors-To: pwe3-admin@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Pseudo Wires Edge to Edge List-Post: List-Help: List-Subscribe: , Status: O Peter... > -----Original Message----- > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: 27 February 2004 23:50 > To: Harrison,N,Neil,IKR2 R; mustapha.aissaoui@alcatel.com > Cc: sbrim@cisco.com; Spencer,R,Richard,XGH5 R; pwe3@ietf.org > Subject: RE: [PWE3] New PWE3 Charter Items: SPVC Interworking >=20 >=20 > Neil, >=20 > I hope that you can help me understand what the practical=20 > implictions are of some of your generic statements. Please see below. NH=3D> I can try..... >=20 > Peter >=20 >=20 > >=20 > > NH=3D> In simple client/server i/w (aka network i/w) the=20 > > control-planes of both the client and the server layers are=20 > > independent with no i/w at all. =20 >=20 > Mustapha's email addressed control plane interworking between=20 > ATM and MPLS. In that context, how should I interpret your=20 > statement? Are you saying that the only valid way of carrying=20 > ATM over MPLS is the following: establish a Pseudo Wire NH=3D> PWs are not MPLS however....LSPs are networked entities PWs are = adaptation functions. All the functional components of a layer network = should be associated with the networked entity....in MPLS this an LSP. = A PW can have either IP or MPLS as a server layer network.....these are = not the same. PWs therefore have no real networking context....other = than the fact they are some form of adaptation. This is not a good road = PWE3 have set off down. =20 > that=20 > carries multiple VPs in such a way that ATM signaling and=20 > routing information is carried transparently over that PW and=20 > the establishment of new VPs or VCs through that PW should be=20 > done in such a way that it doesn't require any additional=20 > signaling in the MPLS plane? This would exclude any form of=20 > 1-1 encapsulation where VC or VP setup necessarily triggers PW setup. NH=3D> In a strict C/S case that is right. If I carry ATM over SDH I = would never expect an ATM SVC demand to trigger a VC4 set-up say in SDH. = This principle is also why the GMPLS peer-model was never sensible (I = assume its effectively dead now?). I mean, even from the most simple = case of different SPs owning the client and server layer networks one = can see this is a nonsense. >=20 >=20 >=20 > > * Because PWE3 does not recognise MPLS as a layer=20 > > network in its own right we don't have i/w with MPLS LSPs=20 > > directly but rather a forced client/server i/w with PWs on a=20 > > client specific basis. This is a mistake in our view for=20 > > several reasons, but that is what has happened and is now=20 > > something some folks are going to have to live with. This=20 > > means there will be (at least) O(N^2) possible mapping=20 > > relationships in the data-plane >=20 > As a generic statement this sounds reasonable, but when you=20 > look at the specifics of existing protocols, I don't think it holds. NH=3D> We want to stop re-doing past mistakes. >=20 > The MPLS-FR Alliance has recently examined Service=20 > Interworking in-depth. One of the conclusions was that you=20 > can't do generic (i.e. payload-independent) service=20 > interworking between Ethernet on the one hand and Frame Relay=20 > or ATM on the other. (This was explained in detail in a=20 > contribution by Rao Cherukuri and Ali Sajassi.)=20 NH=3D> I know Rao and Ali and this is wise counsel.....and this is why I = remarked in my previous mail that whilst we can do OAM mapping between = I.610 ATM and Y.1711 OAM, this is only possible because both the = semantics and syntax (and even their derived dependent defect = definitions) are closely aligned (see Y.1712 where this is now = specified). This was not 'chance' either, it was designed it to be this = way.....though Y.1711 is much simpler and superior to I.610 (despite the = misinformation I keep seeing from some parties on Y.1711). However, for = the general case this will not be possible....and in fact you will = end-up with a right lash-up IMO.=20 > As a result,=20 > the MPLS-FR Alliance decided that Service Interworking can=20 > only be done in very specific cases: Be very careful here. We have been vigorously discussuing this topic in = BT for some time. Never forget that one of the things most operators = want to get away from is the notion that 'service<=3D>technology'. That = is, we have sold FR services, we have sold ATM services, etc. So to = date we have ended-up selling features of specific technologies and we = have also ended-up with lots of disjoint stovepipe networks.....and its = not just these, but the whole NMS/OSS stack that goes with them....and = that is a killer! If you see the key point here then when you look at = the peer-partition i/w rules I set down in my reply to Mustapha = hopefully it will make more sense, ie terminate all CI at the IWF, eg no = OAM mapping (so, for example, we would disagree with Tom's OAM message = mapping draft....also see my previous comment above for the one possible = MPLS_I.610/ATM_Y.1711 exception to this), no 'feature' (like CLP) = mappings. It may be that we *never* migrate existing stoveipes to a common = core....simply because of the complexities this will create and the true = costs of doing this migration (don't overlook the crucial NMS/OSS = aspects in this). However, we still need to get the basic C/S case = right (and I implore folks to understand/respect G.805 here) and we also = need to properly understand the peer-partition i/w case since there will = be cases of interfacing different peer networking technologies (same or = different modes). As a long-term goal we have a concept I christened = here of 'functional covergence'......and this is all about stopping = replacing technology X with technology Y (and thus a wholesale = functional component change out, inc NMS/OSS), but instead focussing on = moving to best-of-breed functions for some target cl-ps, co-ps and co-cs = technology.....the networking problem for each technology belonging to = the same mode is largely the same. We very strongly don't agree with = folks who think all the services we need to offer can be done in a = single mode....I tried to explain some of this in my response to Chris = Lewis wrt 'QoS in VPNs', and these wider points really ought to be = considered along side this stuff as its all related. =20 >=20 > 1) Between Frame Relay and ATM, according to FRF.8 NH=3D> Now, can you see that this is a product of an old mindset where = 'technology=3Dservice'? I can for sure understand *why* those who did = this did it like this......it made sense then and still does where we = sell 'FR and ATM services'. But we want to get away from this notion of = 'selling technology' over the long-term. So continuing to foster this = same view is not a good idea IMO. Note also that in FRF8 there is the = option *not* to do the 'feature mappings'......not sure who put that in = there, but maybe they were way ahead of the game even back then. >=20 > 2) In case of end-to-end transport of Ethernet traffic (i.e.=20 > where ATM and FR use bridge-mode encapsulation) NH=3D> Yes, but this is pure C/S....this ought to be simple *if* you = respect the rules. >=20 > 3) In case of end-to-end transport of IP traffic (i.e. where=20 > ATM and FR use routed-mode encapsulation) NH=3D> Again its simple clinet/server....here the client is IP. >=20 > Of these, (2) can hardly be considered as Service Interworing=20 > in the traditional sense of the word. It is essentially a=20 > variant of network interworking of Ethernet over ATM or FR.=20 > (3) is more complicated due to IP specific issues that have=20 > been identified by Himanshu Shah and Ali Sajassi in earlier=20 > drafts, but still it is not Service Interworking in the=20 > traditional sense of the word. NH=3D> Agreed. >=20 > The same holds for MPLS: it would be possible to define SI=20 > between FR and MPLS or ATM and MPLS. However, it is not=20 > possible to define generic (payload-independent) Service=20 > Interworking between Ethernet and MPLS. NH=3D> Oh yes I know.....this one is really giving me headaches. If you = recall what I said to Mustapha there was one point that some folks may = easily have missed (clearly you haven't) as to its true = importance/significance...so let me repeat it. *Before* one should even = think about peer-partition i/w of the functional components of >=3D2 = server layer networks, you have to have a very clear understanding of = the 'thing' that is the common client layer entity of all the lower peer = partitions. Now this has some deep implications that I probably don't = want to get into here.....and in any case we have not come to any firm = views as to what this should be yet. However, its on our agenda to sort = because it is pivotal to some of our other ideas for an alternative = services arch.=20 >=20 > Therefore, your statement about the service interworking=20 > between N different protocols reduces to a statement about=20 > Frame Relay and ATM only. For N=3D2, it seems that PW emulation=20 > of ATM (or FR) over MPLS in conjunction with FRF.8 is a more=20 > pragmatic approach than the alternative that you propose: SI=20 > between ATM and MPLS followed by SI of MPLS to FR. NH=3D> Yes, I can see what you are saying, ie no SI for either ATM or FR = with MPLS, just C/S case. However, one still needs the right C/S = approach here...and specically we do not need the notion of PWs for this = at all if the server is only arch compliant MPLS and we have client = transparency. =20 >=20 > Am I missing something? NH=3D> Don't think so. >=20 >=20