From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: Re: last call on control and ethernet drafts Date: Fri, 07 Nov 2003 14:19:43 -0700 Organization: Cisco Systems Lines: 76 Sender: pwe3-admin@ietf.org References: <70040932-08DF-11D8-B9BE-000393D54EA6@tcb.net> <3F9E3688.4090006@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, Danny McPherson X-From: pwe3-admin@ietf.org Fri Nov 07 22:21:08 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721 X-Accept-Language: en-us, en To: pwe3@ietf.org In-Reply-To: <3F9E3688.4090006@cisco.com> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 yes, i was on vacation as well. I have to support the omission of the FCS from the PWE3 encapsulation as that fit quite well with operations that IP routers have to perform. ( to route IP the FCS of layer2 is always stripped and regenerated ). Because of this many implementations have the FCS function in hardware at the port level,which makes it quite easy to implement the current PWE3 design. This why we went down this path in the first place. Today there are many implementations of the PWE3 encapsulation ( draft-martini version ) that are deployed and generating revenue for service providers. I have not heard of any issues that could have been prevented by including an FCS. Luca Stewart Bryant wrote: > > I have been out of town for a few days, and so have only just got > to this thread. > > The FCS topic was always planned for the Minneapolis agenda, so > I propose that we (the chairs) follow Danny's plan and put together > a summary of the consensus at the end of LC, post to the list, and > the WG discuss/ratify when we meet on 10th. I will post the summary > of the outcome to the list on the 11th. > > As stated below, the decision (either way) must be based on the > TECHNICAL merits of the proposal, and be based on the behavior > of the PW as a system. > > Stewart > > > > > Danny McPherson wrote: > >> >> Folks, >> I don't care if you work for an equipment manufacturer, service >> provider or at a fast food drive-thru, please state your positions >> based technical merit (I assure you that's all they'll be weighted >> on). Where someone has (or currently!) works is completely >> irrelevant! >> >> At this point the closest thing to consensus I've seen (yes, after >> re-reviewing ALL of the April and September discussions on this >> topic [again]) is that a separate draft seems to be the preferred >> option. >> >> Even that option has pitfalls, most of which have been expressed >> here (in this or the previous two threads on this subject), though >> it's still seems to be the most widely supported. >> >> Please continue discussing the issue and either Stewart or I will >> summarize what we believe to be consensus by the end of LC on the >> concerned WG documents. >> >> -danny >> >> >> _______________________________________________ >> 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: Stewart Bryant Subject: PWE3 WG meeting monday 10th Nov 2003 Date: Fri, 07 Nov 2003 22:37:14 +0000 Organization: Cisco Systems, Inc. Lines: 12 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 Nov 07 23:39:04 2003 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 Presentors: As always we would like to post the meeting slides to the PWE3 web site before the meeting starts. Looking back I see that I mistakenly asked for them by next Friday. Please could Danny and I have them ASAP so that we can make them available before the meeting? Thanks Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ali Sajassi Subject: Re: last call on control and ethernet drafts Date: Fri, 07 Nov 2003 19:32:56 -0800 Lines: 100 Sender: pwe3-admin@ietf.org References: <3F9E3688.4090006@cisco.com> <70040932-08DF-11D8-B9BE-000393D54EA6@tcb.net> <3F9E3688.4090006@cisco.com> <3FAC0C6F.30507@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stbryant@cisco.com, Danny McPherson X-From: pwe3-admin@ietf.org Sat Nov 08 04:34:08 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Luca Martini , pwe3@ietf.org In-Reply-To: <3FAC0C6F.30507@cisco.com> References: <3F9E3688.4090006@cisco.com> <70040932-08DF-11D8-B9BE-000393D54EA6@tcb.net> <3F9E3688.4090006@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 Given that I won't be able to attend the IETF meeting this time because of scheduling conflict, I would like to restate my position in favor of FCS omission. The main point of passing customer FCS is to be able to detect errors/corruptions that may occur inside the PE/P nodes - e.g., to resemble a characteristic similar to a wire. FCS pass-through is one way to achieve this. However, it only works for EPL service and does NOT work for EVPL, EPLAN, and EVPLAN. A better way of addressing this issue is to ensure that the packets are properly protected every step of the way (both inside the wire between the nodes as well as through the PE/P nodes). This way, we ensure that we have a reliable transport mechanism that not only works for EPL, but also it works for other Ethernet services such as EVPL, EPLAN, and EVPLAN. Therefore, I am in favor of addressing this issue fundamentally for all Ethernet services and not just a patch work for EPL. -Ali At 02:19 PM 11/7/2003 -0700, Luca Martini wrote: >yes, i was on vacation as well. > >I have to support the omission of the FCS from the PWE3 encapsulation as >that fit quite well with operations that IP routers have to perform. ( to >route IP the FCS of layer2 is always stripped and regenerated ). Because >of this many implementations have the FCS function in hardware at the port >level,which makes it quite easy to implement the current PWE3 >design. This why we went down this path in the first place. Today there >are many implementations of the PWE3 encapsulation ( draft-martini version >) that are deployed and generating revenue for service providers. I have >not heard of any issues that could have been prevented by including an FCS. > >Luca > >Stewart Bryant wrote: > >> >>I have been out of town for a few days, and so have only just got >>to this thread. >> >>The FCS topic was always planned for the Minneapolis agenda, so >>I propose that we (the chairs) follow Danny's plan and put together >>a summary of the consensus at the end of LC, post to the list, and >>the WG discuss/ratify when we meet on 10th. I will post the summary >>of the outcome to the list on the 11th. >> >>As stated below, the decision (either way) must be based on the >>TECHNICAL merits of the proposal, and be based on the behavior >>of the PW as a system. >> >>Stewart >> >> >> >> >>Danny McPherson wrote: >> >>> >>>Folks, >>>I don't care if you work for an equipment manufacturer, service >>>provider or at a fast food drive-thru, please state your positions >>>based technical merit (I assure you that's all they'll be weighted >>>on). Where someone has (or currently!) works is completely >>>irrelevant! >>> >>>At this point the closest thing to consensus I've seen (yes, after >>>re-reviewing ALL of the April and September discussions on this >>>topic [again]) is that a separate draft seems to be the preferred >>>option. >>> >>>Even that option has pitfalls, most of which have been expressed >>>here (in this or the previous two threads on this subject), though >>>it's still seems to be the most widely supported. >>> >>>Please continue discussing the issue and either Stewart or I will >>>summarize what we believe to be consensus by the end of LC on the >>>concerned WG documents. >>> >>>-danny >>> >>> >>>_______________________________________________ >>>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: Scott Kotrla Subject: RE: last call on control and ethernet drafts Date: Sun, 09 Nov 2003 22:42:36 -0600 Lines: 152 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031107191442.02786a68@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Mon Nov 10 05:48:10 2003 Return-path: In-reply-to: <4.3.2.7.2.20031107191442.02786a68@airborne.cisco.com> To: "'Ali Sajassi'" , "'Luca Martini'" , pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Given that I won't be able to attend the IETF meeting because of scheduling conflict, I would like to restate my position in favor of FCS retention in the main drafts. The main point of passing the customer FCS is to be able to detect errors/corruptions that may occur inside the PE/P nodes for ANY service that does not change customer VLAN IDs, which could include all of the services previously mentioned in an end-to-end Pseudowire architecture. Trying to address this by making sure that packets are no corrupted inside P/PE boxes is next to impossible. It depends heavily on the internal architecture of the PE/P nodes and varies in each implementation. FCS retention is the only known was of making an MPLS network look like a wire to the customer. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Ali Sajassi Sent: Friday, November 07, 2003 9:33 PM To: Luca Martini; pwe3@ietf.org Cc: stbryant@cisco.com; Danny McPherson Subject: Re: [PWE3] last call on control and ethernet drafts Given that I won't be able to attend the IETF meeting this time because of scheduling conflict, I would like to restate my position in favor of FCS omission. The main point of passing customer FCS is to be able to detect errors/corruptions that may occur inside the PE/P nodes - e.g., to resemble a characteristic similar to a wire. FCS pass-through is one way to achieve this. However, it only works for EPL service and does NOT work for EVPL, EPLAN, and EVPLAN. A better way of addressing this issue is to ensure that the packets are properly protected every step of the way (both inside the wire between the nodes as well as through the PE/P nodes). This way, we ensure that we have a reliable transport mechanism that not only works for EPL, but also it works for other Ethernet services such as EVPL, EPLAN, and EVPLAN. Therefore, I am in favor of addressing this issue fundamentally for all Ethernet services and not just a patch work for EPL. -Ali At 02:19 PM 11/7/2003 -0700, Luca Martini wrote: >yes, i was on vacation as well. > >I have to support the omission of the FCS from the PWE3 encapsulation as >that fit quite well with operations that IP routers have to perform. ( to >route IP the FCS of layer2 is always stripped and regenerated ). Because >of this many implementations have the FCS function in hardware at the port >level,which makes it quite easy to implement the current PWE3 >design. This why we went down this path in the first place. Today there >are many implementations of the PWE3 encapsulation ( draft-martini version >) that are deployed and generating revenue for service providers. I have >not heard of any issues that could have been prevented by including an FCS. > >Luca > >Stewart Bryant wrote: > >> >>I have been out of town for a few days, and so have only just got >>to this thread. >> >>The FCS topic was always planned for the Minneapolis agenda, so >>I propose that we (the chairs) follow Danny's plan and put together >>a summary of the consensus at the end of LC, post to the list, and >>the WG discuss/ratify when we meet on 10th. I will post the summary >>of the outcome to the list on the 11th. >> >>As stated below, the decision (either way) must be based on the >>TECHNICAL merits of the proposal, and be based on the behavior >>of the PW as a system. >> >>Stewart >> >> >> >> >>Danny McPherson wrote: >> >>> >>>Folks, >>>I don't care if you work for an equipment manufacturer, service >>>provider or at a fast food drive-thru, please state your positions >>>based technical merit (I assure you that's all they'll be weighted >>>on). Where someone has (or currently!) works is completely >>>irrelevant! >>> >>>At this point the closest thing to consensus I've seen (yes, after >>>re-reviewing ALL of the April and September discussions on this >>>topic [again]) is that a separate draft seems to be the preferred >>>option. >>> >>>Even that option has pitfalls, most of which have been expressed >>>here (in this or the previous two threads on this subject), though >>>it's still seems to be the most widely supported. >>> >>>Please continue discussing the issue and either Stewart or I will >>>summarize what we believe to be consensus by the end of LC on the >>>concerned WG documents. >>> >>>-danny >>> >>> >>>_______________________________________________ >>>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 _______________________________________________ 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: neil.2.harrison@bt.com Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 07:54:27 -0000 Lines: 143 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 Mon Nov 10 08:56:04 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] last call on control and ethernet drafts thread-index: AcOlqUpxB5rXuA7ZS+u9p7Y5wkXHbABbUJ+g To: , , X-OriginalArrivalTime: 10 Nov 2003 07:54:27.0686 (UTC) FILETIME=[DD872860:01C3A75F] 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 have checked with my colleagures here and BT do not agree with this = view as a general architectural principle. When dealing with simple = client/server encapsulation (between any arbitrary pair of technologies) = the general maxim should be to leave the client layer PDU structure = alone to ensure layer independence.....so this is *any* change of the = client layer, which of course also includes any compression behaviour.=20 regards, Neil=20 > -----Original Message----- > From: Ali Sajassi [mailto:sajassi@cisco.com] > Sent: 08 November 2003 03:33 > To: Luca Martini; pwe3@ietf.org > Cc: stbryant@cisco.com; Danny McPherson > Subject: Re: [PWE3] last call on control and ethernet drafts >=20 >=20 >=20 > Given that I won't be able to attend the IETF meeting this=20 > time because of=20 > scheduling conflict, I would like to restate my position in=20 > favor of FCS=20 > omission. >=20 > The main point of passing customer FCS is to be able to detect=20 > errors/corruptions that may occur inside the PE/P nodes -=20 > e.g., to resemble=20 > a characteristic similar to a wire. FCS pass-through is one=20 > way to achieve=20 > this. However, it only works for EPL service and does NOT=20 > work for EVPL,=20 > EPLAN, and EVPLAN. A better way of addressing this issue is=20 > to ensure that=20 > the packets are properly protected every step of the way=20 > (both inside the=20 > wire between the nodes as well as through the PE/P nodes).=20 > This way, we=20 > ensure that we have a reliable transport mechanism that not=20 > only works for=20 > EPL, but also it works for other Ethernet services such as=20 > EVPL, EPLAN, and=20 > EVPLAN. Therefore, I am in favor of addressing this issue=20 > fundamentally for=20 > all Ethernet services and not just a patch work for EPL. >=20 > -Ali >=20 > At 02:19 PM 11/7/2003 -0700, Luca Martini wrote: > >yes, i was on vacation as well. > > > >I have to support the omission of the FCS from the PWE3=20 > encapsulation as=20 > >that fit quite well with operations that IP routers have to=20 > perform. ( to=20 > >route IP the FCS of layer2 is always stripped and=20 > regenerated ). Because=20 > >of this many implementations have the FCS function in=20 > hardware at the port=20 > >level,which makes it quite easy to implement the current PWE3=20 > >design. This why we went down this path in the first place.=20 > Today there=20 > >are many implementations of the PWE3 encapsulation (=20 > draft-martini version=20 > >) that are deployed and generating revenue for service=20 > providers. I have=20 > >not heard of any issues that could have been prevented by=20 > including an FCS. > > > >Luca > > > >Stewart Bryant wrote: > > > >> > >>I have been out of town for a few days, and so have only just got > >>to this thread. > >> > >>The FCS topic was always planned for the Minneapolis agenda, so > >>I propose that we (the chairs) follow Danny's plan and put together > >>a summary of the consensus at the end of LC, post to the list, and > >>the WG discuss/ratify when we meet on 10th. I will post the summary > >>of the outcome to the list on the 11th. > >> > >>As stated below, the decision (either way) must be based on the > >>TECHNICAL merits of the proposal, and be based on the behavior > >>of the PW as a system. > >> > >>Stewart > >> > >> > >> > >> > >>Danny McPherson wrote: > >> > >>> > >>>Folks, > >>>I don't care if you work for an equipment manufacturer, service > >>>provider or at a fast food drive-thru, please state your positions > >>>based technical merit (I assure you that's all they'll be weighted > >>>on). Where someone has (or currently!) works is completely > >>>irrelevant! > >>> > >>>At this point the closest thing to consensus I've seen (yes, after > >>>re-reviewing ALL of the April and September discussions on this > >>>topic [again]) is that a separate draft seems to be the preferred > >>>option. > >>> > >>>Even that option has pitfalls, most of which have been expressed > >>>here (in this or the previous two threads on this subject), though > >>>it's still seems to be the most widely supported. > >>> > >>>Please continue discussing the issue and either Stewart or I will > >>>summarize what we believe to be consensus by the end of LC on the > >>>concerned WG documents. > >>> > >>>-danny > >>> > >>> > >>>_______________________________________________ > >>>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 >=20 >=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: "David Allan" Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 03:30:54 -0500 Lines: 14 Sender: pwe3-admin@ietf.org Cc: stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Mon Nov 10 09:32:05 2003 Return-path: To: "'Scott Kotrla'" , "'Ali Sajassi'" , "'Luca Martini'" , 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 Add me to the list of non-attendees in Minneapolis. Eric put it quite well when he stated that what we really want is an e2e integrity check in all modes. At the same time providing this functionality is impossible without modifying the client layer, which is a non starter as a solution. So Ali's suggestion that we need a comprehensive solution for all modes is demonstratably unachievable and carriage of FCS e2e for some modes is the best we can do. As such we should not preclude it. Further I would prefer that this is in the base documents, Andy Nick and I have a draft that shows the required changes are minor. rgds Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Narendrakumar Limbani" Subject: Setup of PW extending multiple tunnels Date: Mon, 10 Nov 2003 15:17:07 +0530 Lines: 100 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8e96758d-d0c5-4a31-bb9f-1b329d3542dc" Cc: X-From: pwe3-admin@ietf.org Mon Nov 10 10:50:15 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: Setup of PW extending multiple tunnels Thread-Index: AcOnb5qITsHcDJNARTCxQiW+Nb08VA== To: X-OriginalArrivalTime: 10 Nov 2003 09:47:07.0702 (UTC) FILETIME=[9ACFBD60:01C3A76F] 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. ------=_NextPartTM-000-8e96758d-d0c5-4a31-bb9f-1b329d3542dc Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A76F.9A820D30" ------_=_NextPart_001_01C3A76F.9A820D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I want to know whether it is possible to setup a PW extending multiple tunnels. =20 for instance, I have setup like this =20 A ----p---------p-------- B ------p----------p----------- C =20 I have one tunnel between A & B. I have one more tunnel between B & C. =20 Now is it possible to setup PW between A & B ? I am referring draft-ietf-pwe3-control-protocol-04.txt. =20 =20 Regds, Narendrakumar Limbani =20 =20 =20 =20 ------_=_NextPart_001_01C3A76F.9A820D30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I want to know whether it is = possible to=20 setup a PW extending multiple tunnels.
 
for instance, I have setup like=20 this
 
  A  = ----p---------p-------- =20  B    ------p----------p----------- C
 
I have one tunnel between A &=20 B.
I have one more = tunnel between B=20 & C.
 
Now is it possible to setup PW = between A=20 & B ?
I am referring=20 draft-ietf-pwe3-control-protocol-04.txt.
 
 
Regds,
Narendrakumar Limbani
 
 
 

 

=00 ------_=_NextPart_001_01C3A76F.9A820D30-- ------=_NextPartTM-000-8e96758d-d0c5-4a31-bb9f-1b329d3542dc-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Heiles Juergen Subject: AW: I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.txt Date: Mon, 10 Nov 2003 12:12:33 +0100 Lines: 114 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 Nov 10 12:13:03 2003 Return-path: To: "'Rick Osteen'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 Rick, "VLAN stacking" is currently under definition by IEEE as part of the = 802.1ad "provider bridge" work. As Eric already mentioned such a = "stacked" frame should be transported via pwe3 Ethernet tunnel like any = other Ethernet frame. Regards Juergen > -----Urspr=FCngliche Nachricht----- > Von: Rick Osteen [mailto:rick.osteen@cox.net] > Gesendet: Samstag, 18. Oktober 2003 15:08 > An: pwe3@ietf.org > Betreff: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.txt >=20 >=20 > Eric & Luca, >=20 > I understand that there is no standard for "vlan stacking,"=20 > but this would > be helpful when a service provider's choice is to only send a local > enterprise's traffic through a single large pipe which is=20 > already running > 802.1q and stacking and for some reason does not have the=20 > port to bring that > customer's connection via a raw interface. >=20 > I know of Riverstone & Jedai who currently provide stacking thus far. >=20 > Thanks for any consideration, > Rick Osteen >=20 > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, October 13, 2003 3:56 PM > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.txt >=20 >=20 > > 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 : Encapsulation Methods for Transport of Ethernet > > Frames Over IP/MPLS Networks > > Author(s) : L. Martini, et. al. > > Filename : draft-ietf-pwe3-ethernet-encap-04.txt > > Pages : 19 > > Date : 2003-10-13 > > > > An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 = Protocol > > Data Units over an IP or MPLS network. This enables service=20 > providers > > to offer 'emulated' ethernet services over existing IP or MPLS > > networks. This document specifies the encapsulation of=20 > Ethernet/802.3 > > PDUs within a pseudowire. It also specifies the procedures for = using > > a PW to provide a 'point-to-point ethernet' service. > > > > A URL for this Internet-Draft is: > >=20 http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-04.tx= t > > 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-ethernet-encap-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-ethernet-encap-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. > _______________________________________________ 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: "Narendrakumar Limbani" Subject: RE: Setup of PW extending multiple tunnels Date: Mon, 10 Nov 2003 17:36:23 +0530 Lines: 148 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-15f03a6c-1231-41e7-880e-7e1d7e5b9b85" Cc: X-From: pwe3-admin@ietf.org Mon Nov 10 13:09:03 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] Setup of PW extending multiple tunnels Thread-Index: AcOnb5qITsHcDJNARTCxQiW+Nb08VAAEwt3g To: X-OriginalArrivalTime: 10 Nov 2003 12:07:55.0867 (UTC) FILETIME=[464F6AB0:01C3A783] 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. ------=_NextPartTM-000-15f03a6c-1231-41e7-880e-7e1d7e5b9b85 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A783.0F7D62D8" ------_=_NextPart_001_01C3A783.0F7D62D8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 By mistake I asked for between A & B. Actually I want to know whether it is possible setup PW beetween A & C. =20 --Narendra =20 -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Narendrakumar Limbani Sent: Monday, November 10, 2003 3:17 PM To: pwe3@ietf.org Cc: mpls@UU.NET Subject: [PWE3] Setup of PW extending multiple tunnels =09 =09 Hi, =20 I want to know whether it is possible to setup a PW extending multiple tunnels. =20 for instance, I have setup like this =20 A ----p---------p-------- B ------p----------p----------- C =20 I have one tunnel between A & B. I have one more tunnel between B & C. =20 Now is it possible to setup PW between A & B ? I am referring draft-ietf-pwe3-control-protocol-04.txt. =20 =20 Regds, Narendrakumar Limbani =20 =20 =20 =20 ------_=_NextPart_001_01C3A783.0F7D62D8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 All,
 
By mistake I=20 asked for between A & B.
Actually I=20 want to know whether it is possible setup PW beetween A &=20 C.
 
--Narendra
 
-----Original Message-----
From: = pwe3-admin@ietf.org=20 [mailto:pwe3-admin@ietf.org] On Behalf Of Narendrakumar=20 Limbani
Sent: Monday, November 10, 2003 3:17 = PM
To:=20 pwe3@ietf.org
Cc: mpls@UU.NET
Subject: [PWE3] = Setup of PW=20 extending multiple tunnels

Hi,
 
I want to know whether it is = possible to=20 setup a PW extending multiple tunnels.
 
for instance, I have setup like=20 this
 
  A =20 ----p---------p--------   B   =20 ------p----------p----------- C
 
I have one tunnel between A = &=20 B.
I have one more = tunnel between B=20 & C.
 
Now is it possible to setup PW = between A=20 & B ?
I am referring=20 draft-ietf-pwe3-control-protocol-04.txt.
 
 
Regds,
Narendrakumar = Limbani
 
 
 

 

=00 ------_=_NextPart_001_01C3A783.0F7D62D8-- ------=_NextPartTM-000-15f03a6c-1231-41e7-880e-7e1d7e5b9b85-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Shahram Davari Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 05:13:43 -0800 Lines: 49 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Mon Nov 10 14:15:05 2003 Return-path: To: "'David Allan'" , "'Scott Kotrla'" , "'Ali Sajassi'" , "'Luca Martini'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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, I would like to support having an option to transport Ethernet FCS. There are 2 cases: 1) The ingress PE does not modify the ingress Ethernet packet, such as the port-based raw mode. In this case keeping customer's FCS, provides the capability of checking the integrity of the access+transport networks. 2) The ingress PE does modify the ingress Ethernet packet, such as the raw mode with service delimiting tag, and the tagged mode (which may add a dummy tag). In these cases, if the ingress PE generates new FCS and transports the packet with that FCS, then at least the integrity of the transport network (excluding the ingress and egress PE) could be checked. -Shahram >-----Original Message----- >From: David Allan [mailto:dallan@nortelnetworks.com] >Sent: Monday, November 10, 2003 3:31 AM >To: 'Scott Kotrla'; 'Ali Sajassi'; 'Luca Martini'; pwe3@ietf.org >Cc: stbryant@cisco.com; 'Danny McPherson' >Subject: RE: [PWE3] last call on control and ethernet drafts > > >Add me to the list of non-attendees in Minneapolis. > >Eric put it quite well when he stated that what we really want >is an e2e >integrity check in all modes. At the same time providing this >functionality >is impossible without modifying the client layer, which is a >non starter as >a solution. So Ali's suggestion that we need a comprehensive >solution for >all modes is demonstratably unachievable and carriage of FCS >e2e for some >modes is the best we can do. As such we should not preclude it. > >Further I would prefer that this is in the base documents, >Andy Nick and I >have a draft that shows the required changes are minor. > >rgds >Dave > >_______________________________________________ >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: PWE3 Meeting @IETF 58 Date: Mon, 10 Nov 2003 08:57:49 -0700 Lines: 14 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Nov 10 16:59:05 2003 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.606) 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 Folks, The meeting information for this evening is located at the following URL: http://pwe3.tcb.net/meetings/ietf58/ If you're slides aren't available on this site and your name is you need to provide them to Stewart & I ASAP -- else your slot may be reallocated :-) Note that we are aware the PWE3 agenda link on the IETF web site is currently broken, we've asked that this be corrected. -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Nick DelRegno Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 10:33:27 -0600 Lines: 34 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Mon Nov 10 17:42:06 2003 Return-path: In-reply-to: To: "'David Allan'" , "'Scott Kotrla'" , "'Ali Sajassi'" , "'Luca Martini'" , pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Unfortunately I had to cancel my plans to attend as well. Once again, for the record, I also favor the option to retain the FCS on PW Ingress be added to the base drafts. Nick -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of David Allan Sent: Monday, November 10, 2003 2:31 AM To: 'Scott Kotrla'; 'Ali Sajassi'; 'Luca Martini'; pwe3@ietf.org Cc: stbryant@cisco.com; 'Danny McPherson' Subject: RE: [PWE3] last call on control and ethernet drafts Add me to the list of non-attendees in Minneapolis. Eric put it quite well when he stated that what we really want is an e2e integrity check in all modes. At the same time providing this functionality is impossible without modifying the client layer, which is a non starter as a solution. So Ali's suggestion that we need a comprehensive solution for all modes is demonstratably unachievable and carriage of FCS e2e for some modes is the best we can do. As such we should not preclude it. Further I would prefer that this is in the base documents, Andy Nick and I have a draft that shows the required changes are minor. rgds Dave _______________________________________________ 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: "Rick Osteen" Subject: Re: I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.txt Date: Mon, 10 Nov 2003 12:18:10 -0500 Lines: 133 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-From: pwe3-admin@ietf.org Mon Nov 10 18:21:05 2003 Return-path: To: "Heiles Juergen" , X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA01465 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 Juergen, This is good news. The other concern is regarding MTU's greater than 1500 when doing a "provider bridge" scenario. Will PW take of this as well? Thanks, Rick Osteen ----- Original Message ----- From: "Heiles Juergen" To: "'Rick Osteen'" ; Sent: Monday, November 10, 2003 6:12 AM Subject: AW: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.txt Rick, "VLAN stacking" is currently under definition by IEEE as part of the 802.= 1ad "provider bridge" work. As Eric already mentioned such a "stacked" frame should be transported via pwe3 Ethernet tunnel like any other Ethernet frame. Regards Juergen > -----Urspr=FCngliche Nachricht----- > Von: Rick Osteen [mailto:rick.osteen@cox.net] > Gesendet: Samstag, 18. Oktober 2003 15:08 > An: pwe3@ietf.org > Betreff: Re: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.txt > > > Eric & Luca, > > I understand that there is no standard for "vlan stacking," > but this would > be helpful when a service provider's choice is to only send a local > enterprise's traffic through a single large pipe which is > already running > 802.1q and stacking and for some reason does not have the > port to bring that > customer's connection via a raw interface. > > I know of Riverstone & Jedai who currently provide stacking thus far. > > Thanks for any consideration, > Rick Osteen > > ----- Original Message ----- > From: > To: > Cc: > Sent: Monday, October 13, 2003 3:56 PM > Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-ethernet-encap-04.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 : Encapsulation Methods for Transport of Ethernet > > Frames Over IP/MPLS Networks > > Author(s) : L. Martini, et. al. > > Filename : draft-ietf-pwe3-ethernet-encap-04.txt > > Pages : 19 > > Date : 2003-10-13 > > > > An Ethernet Pseudowire (PW) is used to carry Ethernet/802.3 Protocol > > Data Units over an IP or MPLS network. This enables service > providers > > to offer 'emulated' ethernet services over existing IP or MPLS > > networks. This document specifies the encapsulation of > Ethernet/802.3 > > PDUs within a pseudowire. It also specifies the procedures for using > > a PW to provide a 'point-to-point ethernet' service. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-ethernet-encap-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-ethernet-encap-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-ethernet-encap-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. > _______________________________________________ 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: Luca Martini Subject: Re: Setup of PW extending multiple tunnels Date: Mon, 10 Nov 2003 10:34:33 -0700 Organization: Cisco Systems Lines: 30 Sender: pwe3-admin@ietf.org References: <7F396B9772328640B7593FA817EEEDAD89E6A9@blr-m3-msg.wipro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, mpls@UU.NET X-From: pwe3-admin@ietf.org Mon Nov 10 18:35:08 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721 X-Accept-Language: en-us, en To: Narendrakumar Limbani In-Reply-To: <7F396B9772328640B7593FA817EEEDAD89E6A9@blr-m3-msg.wipro.com> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 The protocol does not preclude this situation. yes it is possible. Luca Narendrakumar Limbani wrote: > Hi, > > I want to know whether it is possible to setup a PW extending multiple > tunnels. > > for instance, I have setup like this > > A ----p---------p-------- B ------p----------p----------- C > > I have one tunnel between A & B. > I have one more tunnel between B & C. > > Now is it possible to setup PW between A & B ? > I am referring draft-ietf-pwe3-control-protocol-04.txt. > > > Regds, > Narendrakumar Limbani > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 13:52:14 -0500 Lines: 299 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Mon Nov 10 19:54:10 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Shahram Davari X-OriginalArrivalTime: 10 Nov 2003 18:52:21.0057 (UTC) FILETIME=[C57D9310:01C3A7BB] 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 I have previously stated, I am also in favor of the option to retain Ethernet FCS. David, Nick, and I have written a short draft that we'll submit when the draft site reopens that is 100% backwards compatible with the current signaling so you can implement it in only a subset of the PEs and they'll interoperate. It's so short that I've attached it here to give people a chance to look at it prior to this evening's meeting. Andy ---------- Internet Draft Andrew G. Malis Document: draft-malis-pwe3-fcs-retention-00.txt Tellabs Expires: May 2004 David Allen Nortel Networks Nick Del Regno MCI November 2003 PWE3 Frame Check Sequence Retention Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a mechanism for preserving frame FCS through Ethernet, Frame Relay, and HDLC pseudowires. Table of Contents 1. Specification of Requirements.................................2 2. Overview......................................................2 3. FCS Retention With MPLS-based Pseudowires.....................3 4. FCS Retention With L2TPv3-based Pseudowires...................4 5. Security Considerations.......................................4 6. IANA Considerations...........................................4 7. References....................................................4 8. Authors' Addresses............................................5 Malis et al Expires May 2004 [Page 1] PWE3 FCS Retention November 2003 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. 2. Overview The specifications for Ethernet, Frame Relay, HDLC, and PPP pseudowire encapsulation [1] [2] [3] include a mode of use where frames are transparently delivered across the pseudowire without any header or other alterations by the pseudowire ingress or egress Provider Edge (PE). [Note that this mode is inherent for HDLC and PPP Pseudowires.] However, these specifications all specify that the original Frame Check Sequence (FCS) be removed at ingress and regenerated at egress, which means that the frames may be subject to unintentional alteration during their traversal of the pseudowire from the ingress to the egress PE. Thus, the pseudowire cannot be absolutely guaranteed to be "transparent" in nature. To be more precise, pseudowires, as currently defined, leave the payload vulnerable to undetected errors caused by the encapsulating network. As defined for MPLS, not only can a PW-aware device internally corrupt an encapsulated payload, but ANY MPLS LSR in the path can corrupt the encapsulated payload. In the event of such corruption, there is no way to detect the corruption through the path of the pseudowire. Further, because the FCS is calculated upon network egress, any corruption will pass transparently through ALL Layer 2 switches(Ethernet and Frame Relay) through which the packets travel. Only at the endpoint, assuming the corrupted packet even reaches the correct endpoint, can the packet be discarded, and depending on the contents of the packet, the corruption may not ever be detected. Not only does the encapsulation technique leave the payload unprotected, it also subverts the error checking mechanisms already in place in SP and customer networks by calculating FCS on questionable data. In a perfect network comprising perfect equipment, this is not an issue. However, as there is no such thing, it is an issue. SPs should have the option of saving overhead by yielding the ability to detect faults. Equally, SPs should have the option to sacrifice the overhead of carrying the original FCS end-to-end to ensure the ability to detect faults in the encapsulating network. Malis et al Expires May 2004 [Page 2] PWE3 FCS Retention November 2003 This document defines such a mechanism to allow the ingress PE to retain the original frame FCS on ingress to the network, and relieves the egress PE of the task of regenerating the FCS. This in an OPTIONAL mechanism for pseudowire implementations. For interoperability with systems that do not implement this document, the default behavior is that the FCS is removed at the ingress PE and regenerated at the egress PE, as specified in [1], [2], and [3]. 3. FCS Retention With MPLS-based Pseudowires When using the signaling procedures in [4], there is a Virtual Circuit FEC element parameter ID used to signal the desire to retain the FCS when advertising a VC label: Parameter ID Length Description 0x?? 2 FCS Retention Indicator Note: The next currently available parameter number is 0x0A [5]. This parameter number will be added to [5] if the timing permits while it is still a draft, otherwise it will be assigned by IANA. This note is to be removed once the assignment has been made. The presence of this parameter ID in the VC FEC element indicates that the egress PE requests the ingress PE to retain the FCS for the VC label being advertised. It does not obligate the ingress PE to retain the FCS; it is simply an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter ID is not present in the VC FEC element. Since unknown parameter IDs are silently ignored [4], backwards compatibility with systems that do not implement this document is provided by requiring that the FCS is retained ONLY if the FCS Retention Indicator has been included in the advertisements for both directions on a pseudowire. If the ingress PE recognizes the FCS Retention Indicator parameter ID, but does not wish to retain the FCS, it need only issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. This will prevent FCS retention in either direction. If PWE3 signaling [4] is not in use for a pseudowire, then whether or not the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. Malis et al Expires May 2004 [Page 3] PWE3 FCS Retention November 2003 4. FCS Retention With L2TPv3-based Pseudowires This section will be added in a subsequent revision. 5. Security Considerations This mechanism enhances the security of transparent Ethernet, Frame Relay, and HDLC pseudowires, because the original FCS, as generated by the Customer Edge (CE), is included in the encapsulation. When the encapsulated payload passes FCS checking at the destination CE, it is clear that the payload was not altered in any way during its transmission through the network. Of course, nothing comes for free; this requires the additional overhead of carrying the original FCS (in general, either two or four octets per payload packet). This signaling was designed to be backwards compatible and interoperable with systems that do not implement this document. 6. IANA Considerations This document requires IANA to allocate a PWE3 Virtual Circuit FEC element parameter ID. 7. References [1] Martini, L. et al, "Encapsulation Methods for Transport of Ethernet Frames Over IP and MPLS Networks", draft-ietf-pwe3- ethernet-encap-04.txt, October 2003, work in progress [2] Martini, L. et al, "Frame Relay Encapsulation over Pseudo- Wires", draft-ietf-pwe3-frame-relay-01.txt, July 2003, work in progress [3] Martini, L. et al, "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-pwe3- hdlc-ppp-encap-mpls-00.txt, June 2003, work in progress [4] Martini, L. et al, "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3-control-protocol-04.txt, October 2003, work in progress [5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-02.txt, October 2003, work in progress [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Malis et al Expires May 2004 [Page 4] PWE3 FCS Retention November 2003 8. Authors' Addresses Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 Email: Andy.Malis@tellabs.com David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Email: dallan@nortelnetworks.com Nick Del Regno MCI 400 International Parkway Richardson, TX 75081 Email: nick.delregno@mci.com Malis et al Expires May 2004 [Page 5] From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Prayson Pate" Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 14:17:24 -0500 Lines: 26 Sender: pwe3-admin@ietf.org References: <6.0.0.22.2.20031110135139.02cae478@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: "PWE3 WG \(E-mail\)" X-From: pwe3-admin@ietf.org Mon Nov 10 20:16:05 2003 Return-path: To: "Andrew G. Malis" , "Shahram Davari" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6.0.0.22.2.20031110135139.02cae478@mail.comcast.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - wh3.wired-hub.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - overturenetworks.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 I would also like to add my support for having an option to preserve Ethernet FCS. Prayson -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Andrew G. Malis Sent: Monday, November 10, 2003 1:52 PM To: Shahram Davari Cc: PWE3 WG (E-mail) Subject: RE: [PWE3] last call on control and ethernet drafts As I have previously stated, I am also in favor of the option to retain Ethernet FCS. David, Nick, and I have written a short draft that we'll submit when the draft site reopens that is 100% backwards compatible with the current signaling so you can implement it in only a subset of the PEs and they'll interoperate. It's so short that I've attached it here to give people a chance to look at it prior to this evening's meeting. Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Keith Knightson Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 14:40:34 -0500 Lines: 25 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "PWE3 WG \(E-mail\)" X-From: pwe3-admin@ietf.org Mon Nov 10 20:37:08 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: To: "Prayson Pate" , "Andrew G. Malis" , "Shahram Davari" X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.103.75.37] using ID at Mon, 10 Nov 2003 14:35:36 -0500 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 2:17 PM -0500 10/11/03, Prayson Pate wrote: >I would also like to add my support for having an option to preserve >Ethernet FCS. > >Prayson > I have a few quick questions.. How would a user know or test whether the FCS has or has not been carried across the PW? Is this service verifiable? By sending a deliberately corrupted FCS and seeing what happens? Is this simply a question of trust? It would seem to imply that in the case where it is carried it is not looked at, at the ingress. I can't imagine seeing a false FCS and continuing as if it were correct. Does current hardware preserve the FCS for re-use? Regards Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Danny McPherson Subject: Re: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 12:46:49 -0700 Lines: 28 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <6.0.0.22.2.20031110090250.02aed300@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Nov 10 20:48:02 2003 Return-path: In-Reply-To: <6.0.0.22.2.20031110090250.02aed300@mail.comcast.net> To: pwe3@ietf.org X-Mailer: Apple Mail (2.606) 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 Andy, I've got a couple of comments on the draft. The draft needs to specify that "default" mode is to remove the FCS, not that both ends of the network need to be "manually provisioned the same". The security considerations are more of "data integrity" considerations. The draft should clarify this. If the FCS is carried where would checks be performed (e.g., after ingress PE NSP functions & before egress PE NSP functions, as mainline function or other?) -danny On Nov 10, 2003, at 7:25 AM, Andrew G. Malis wrote: > As I have previously stated, I am also in favor of the option to > retain Ethernet FCS. > > David, Nick, and I have written a short draft that we'll submit when > the draft site reopens that is 100% backwards compatible with the > current signaling so you can implement it in only a subset of the PEs > and they'll interoperate. It's so short that I've attached it here to > give people a chance to look at it prior to this evening's meeting. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 15:51:34 -0500 Lines: 32 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Prayson Pate" , "Shahram Davari" , "PWE3 WG \(E-mail\)" X-From: pwe3-admin@ietf.org Mon Nov 10 21:53:07 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Keith Knightson In-Reply-To: References: X-OriginalArrivalTime: 10 Nov 2003 20:51:37.0085 (UTC) FILETIME=[6ED0CAD0:01C3A7CC] 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 Keith, >How would a user know or test whether the FCS has or has not been carried >across the PW? It's part of the SLA with their service provider. >Is this service verifiable? By sending a deliberately corrupted FCS and >seeing what happens? That's one way ... or by putting a monitoring box between the service provider and the CE (many vendors sell these, BTW) that can report this and other perceived problems with the service. >Is this simply a question of trust? See above. >It would seem to imply that in the case where it is carried it is not >looked at, at the ingress. I can't imagine seeing a false FCS and >continuing as if it were correct. That's a good point to mention explicitly - I'll add to the draft that the FCS SHOULD (or MUST?) be examined at the ingress to prevent errored frames that would be discarded at the receiving CE anyway from wasting bandwidth. >Does current hardware preserve the FCS for re-use? Depends on the framer. But yes, there exists framers that can retain the FCS. Cheers, Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: Re: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 15:56:00 -0500 Lines: 25 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <6.0.0.22.2.20031110090250.02aed300@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 10 21:57:02 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Danny McPherson In-Reply-To: References: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <6.0.0.22.2.20031110090250.02aed300@mail.comcast.net> X-OriginalArrivalTime: 10 Nov 2003 20:56:03.0090 (UTC) FILETIME=[0D5DEF20:01C3A7CD] 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 Danny, >The draft needs to specify that "default" mode is to >remove the FCS, not that both ends of the network need >to be "manually provisioned the same". The default mode is to remove the FCS. It says that on page 3, second paragraph. Would you like it repeated elsewhere as well? >The security considerations are more of "data integrity" >considerations. The draft should clarify this. Will do. >If the FCS is carried where would checks be performed >(e.g., after ingress PE NSP functions & before egress PE >NSP functions, as mainline function or other?) Keith asked the same question (see my answer to him). I'll clarify that as well. Thanks for the comments! Cheers, Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Danny McPherson Subject: Re: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 14:26:59 -0700 Lines: 25 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <6.0.0.22.2.20031110090250.02aed300@mail.comcast.net> <6.0.0.22.2.20031110155203.02e68c48@mail.comcast.net> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Nov 10 22:28:04 2003 Return-path: In-Reply-To: <6.0.0.22.2.20031110155203.02e68c48@mail.comcast.net> To: pwe3@ietf.org X-Mailer: Apple Mail (2.606) 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 On Nov 10, 2003, at 1:56 PM, Andrew G. Malis wrote: > Danny, > >> The draft needs to specify that "default" mode is to >> remove the FCS, not that both ends of the network need >> to be "manually provisioned the same". > > The default mode is to remove the FCS. It says that on page 3, second > paragraph. Would you like it repeated elsewhere as well? I was referring to this text in the last paragraph of page 2: If PWE3 signaling [4] is not in use for a pseudowire, then whether or not the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. Although I [now] realize it was a different point you were intending to convey with this text (i.e., both ends must be configured the same if no signaling is employed), perhaps closing this paragraph with a "The default behavior is to remove the FCS" would make sense, else this might introduce confusion WRT manually provisioned PWs. -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 09:25:43 -0500 Lines: 299 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@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: "'David Allan'" , "'Scott Kotrla'" , "'Ali Sajassi'" , "'Luca Martini'" , pwe3@ietf.org, stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Mon Nov 10 22:43:17 2003 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: Shahram Davari In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@nt-exch-yow.pmc_n t.nt.pmc-sierra.bc.ca> References: <4B6D09F3B826D411A67300D0B706EFDE0115CCC3@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 As I have previously stated, I am also in favor of the option to retain Ethernet FCS. David, Nick, and I have written a short draft that we'll submit when the draft site reopens that is 100% backwards compatible with the current signaling so you can implement it in only a subset of the PEs and they'll interoperate. It's so short that I've attached it here to give people a chance to look at it prior to this evening's meeting. Andy ---------- Internet Draft Andrew G. Malis Document: draft-malis-pwe3-fcs-retention-00.txt Tellabs Expires: May 2004 David Allen Nortel Networks Nick Del Regno MCI November 2003 PWE3 Frame Check Sequence Retention Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document defines a mechanism for preserving frame FCS through Ethernet, Frame Relay, and HDLC pseudowires. Table of Contents 1. Specification of Requirements.................................2 2. Overview......................................................2 3. FCS Retention With MPLS-based Pseudowires.....................3 4. FCS Retention With L2TPv3-based Pseudowires...................4 5. Security Considerations.......................................4 6. IANA Considerations...........................................4 7. References....................................................4 8. Authors' Addresses............................................5 Malis et al Expires May 2004 [Page 1] PWE3 FCS Retention November 2003 1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. 2. Overview The specifications for Ethernet, Frame Relay, HDLC, and PPP pseudowire encapsulation [1] [2] [3] include a mode of use where frames are transparently delivered across the pseudowire without any header or other alterations by the pseudowire ingress or egress Provider Edge (PE). [Note that this mode is inherent for HDLC and PPP Pseudowires.] However, these specifications all specify that the original Frame Check Sequence (FCS) be removed at ingress and regenerated at egress, which means that the frames may be subject to unintentional alteration during their traversal of the pseudowire from the ingress to the egress PE. Thus, the pseudowire cannot be absolutely guaranteed to be "transparent" in nature. To be more precise, pseudowires, as currently defined, leave the payload vulnerable to undetected errors caused by the encapsulating network. As defined for MPLS, not only can a PW-aware device internally corrupt an encapsulated payload, but ANY MPLS LSR in the path can corrupt the encapsulated payload. In the event of such corruption, there is no way to detect the corruption through the path of the pseudowire. Further, because the FCS is calculated upon network egress, any corruption will pass transparently through ALL Layer 2 switches(Ethernet and Frame Relay) through which the packets travel. Only at the endpoint, assuming the corrupted packet even reaches the correct endpoint, can the packet be discarded, and depending on the contents of the packet, the corruption may not ever be detected. Not only does the encapsulation technique leave the payload unprotected, it also subverts the error checking mechanisms already in place in SP and customer networks by calculating FCS on questionable data. In a perfect network comprising perfect equipment, this is not an issue. However, as there is no such thing, it is an issue. SPs should have the option of saving overhead by yielding the ability to detect faults. Equally, SPs should have the option to sacrifice the overhead of carrying the original FCS end-to-end to ensure the ability to detect faults in the encapsulating network. Malis et al Expires May 2004 [Page 2] PWE3 FCS Retention November 2003 This document defines such a mechanism to allow the ingress PE to retain the original frame FCS on ingress to the network, and relieves the egress PE of the task of regenerating the FCS. This in an OPTIONAL mechanism for pseudowire implementations. For interoperability with systems that do not implement this document, the default behavior is that the FCS is removed at the ingress PE and regenerated at the egress PE, as specified in [1], [2], and [3]. 3. FCS Retention With MPLS-based Pseudowires When using the signaling procedures in [4], there is a Virtual Circuit FEC element parameter ID used to signal the desire to retain the FCS when advertising a VC label: Parameter ID Length Description 0x?? 2 FCS Retention Indicator Note: The next currently available parameter number is 0x0A [5]. This parameter number will be added to [5] if the timing permits while it is still a draft, otherwise it will be assigned by IANA. This note is to be removed once the assignment has been made. The presence of this parameter ID in the VC FEC element indicates that the egress PE requests the ingress PE to retain the FCS for the VC label being advertised. It does not obligate the ingress PE to retain the FCS; it is simply an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter ID is not present in the VC FEC element. Since unknown parameter IDs are silently ignored [4], backwards compatibility with systems that do not implement this document is provided by requiring that the FCS is retained ONLY if the FCS Retention Indicator has been included in the advertisements for both directions on a pseudowire. If the ingress PE recognizes the FCS Retention Indicator parameter ID, but does not wish to retain the FCS, it need only issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. This will prevent FCS retention in either direction. If PWE3 signaling [4] is not in use for a pseudowire, then whether or not the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. Malis et al Expires May 2004 [Page 3] PWE3 FCS Retention November 2003 4. FCS Retention With L2TPv3-based Pseudowires This section will be added in a subsequent revision. 5. Security Considerations This mechanism enhances the security of transparent Ethernet, Frame Relay, and HDLC pseudowires, because the original FCS, as generated by the Customer Edge (CE), is included in the encapsulation. When the encapsulated payload passes FCS checking at the destination CE, it is clear that the payload was not altered in any way during its transmission through the network. Of course, nothing comes for free; this requires the additional overhead of carrying the original FCS (in general, either two or four octets per payload packet). This signaling was designed to be backwards compatible and interoperable with systems that do not implement this document. 6. IANA Considerations This document requires IANA to allocate a PWE3 Virtual Circuit FEC element parameter ID. 7. References [1] Martini, L. et al, "Encapsulation Methods for Transport of Ethernet Frames Over IP and MPLS Networks", draft-ietf-pwe3- ethernet-encap-04.txt, October 2003, work in progress [2] Martini, L. et al, "Frame Relay Encapsulation over Pseudo- Wires", draft-ietf-pwe3-frame-relay-01.txt, July 2003, work in progress [3] Martini, L. et al, "Encapsulation Methods for Transport of PPP/HDLC Frames Over IP and MPLS Networks", draft-ietf-pwe3- hdlc-ppp-encap-mpls-00.txt, June 2003, work in progress [4] Martini, L. et al, "Transport of Layer 2 Frames Over MPLS", draft-ietf-pwe3-control-protocol-04.txt, October 2003, work in progress [5] Martini, L. et al, "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation-02.txt, October 2003, work in progress [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Malis et al Expires May 2004 [Page 4] PWE3 FCS Retention November 2003 8. Authors' Addresses Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 Email: Andy.Malis@tellabs.com David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA Email: dallan@nortelnetworks.com Nick Del Regno MCI 400 International Parkway Richardson, TX 75081 Email: nick.delregno@mci.com Malis et al Expires May 2004 [Page 5] From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: MPLS RC News Subject: MPLScon 2004 - Call for Presentations Date: Mon, 10 Nov 2003 15:25:29 -0500 Lines: 19 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Mon Nov 10 23:03:07 2003 Return-path: X-Sender: news/mplsrc.com@localhost (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: (Recipient list suppressed) 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 **Call for Presentations - MPLScon Spring 2004** MPLScon 2004 takes place on May 24-27 at the Marriott Financial Center in New York City, NY. Now in it's fourth year, MPLScon focuses on providing vendors, service providers, and enterprise customers with information on technologies, trends, and challenges surrounding Multiprotocol Label Switching and MPLS-based services. MPLScon provides network decision makers with the information they need to understand, evaluate, and deploy MPLS-based services. MPLScon seeks qualified individuals to present on a variety of topics of interest to vendor, service provider, and enterprise communities. A complete list of topics and themes can be found at http://www.mplscon.com/speaker/submit_pres.html Presentation submissions are due November 19, 2003. Questions should be addressed to Irwin Lazar, Conference Director, ilazar@mplscon.com, 703-742-9659. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: last call on control and ethernet drafts Date: Tue, 11 Nov 2003 02:52:09 +0200 Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: Prayson Pate , Shahram Davari , "PWE3 WG (E-mail)" , Keith Knightson X-From: pwe3-admin@ietf.org Tue Nov 11 01:54:06 2003 Return-path: To: "'Andrew G. Malis'" 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 Andy and all, Please see a brief comment inline. ---------------------------------------------------------------------------- -------- 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: Andrew G. Malis [mailto:andy.malis@tellabs.com] > Sent: Monday, November 10, 2003 10:52 PM > To: Keith Knightson > Cc: Prayson Pate; Shahram Davari; PWE3 WG (E-mail) > Subject: RE: [PWE3] last call on control and ethernet drafts > ... snipped... > > >It would seem to imply that in the case where it is carried > >it is not looked at, at the ingress. I can't imagine seeing a false FCS and > >continuing as if it were correct. > > That's a good point to mention explicitly - I'll add to the > draft that the FCS SHOULD (or MUST?) be examined at the ingress to prevent > errored frames that would be discarded at the receiving CE anyway from > wasting bandwidth. > IMO, it is a MUST. ... snipped to the end From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: MPLS over GRE and IPsec for PWE3s Date: Mon, 10 Nov 2003 19:06:24 -0700 Organization: Cisco Systems Lines: 24 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 Tue Nov 11 03:07:06 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721 X-Accept-Language: en-us, en To: pwe3@ietf.org, rahul@juniper.net X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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, from the current version of the draft-ietf-pwe3-control-protocol-04 .... "In the protocol specified herein, the pseudowire demultiplexor field is an MPLS label. Thus the packets which are transmitted from one end of the pseudowire to the other are MPLS packets. Unless the pseudowire endpoints are immediately adjacent, these MPLS packets must be transmitted through a PSN tunnel. Any sort of PSN tunnel can be used, as long as it is possible to transmit MPLS packets through it. The PSN tunnel can itself be an LSP, but it could equally well be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of tunnel which can carry MPLS packets. Procedures for setting up and maintaining the PSN tunnels are outside the scope of this document." As i said your proposal has good merit, it's just that when we included the above section we did not think it was necessary to repeat existing RFCs in this one. if you think that the above section need more clarification we can probably convince the PWE3 chairs to bend the last call rules and make some minor modifications to it. Thanks. Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: Re: MPLS over GRE and IPsec for PWE3s Date: Mon, 10 Nov 2003 18:54:46 -0800 (PST) Lines: 55 Sender: pwe3-admin@ietf.org References: <3FB04420.3000801@cisco.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: pwe3@ietf.org, Kireeti Kompella X-From: pwe3-admin@ietf.org Tue Nov 11 03:56:05 2003 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: Luca Martini In-Reply-To: <3FB04420.3000801@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, Thanks for the comment. Please see inline: On Mon, 10 Nov 2003, Luca Martini wrote: > Rahul, > > from the current version of the draft-ietf-pwe3-control-protocol-04 .... > > "In the protocol specified herein, the pseudowire demultiplexor field is an > MPLS label. Thus the packets which are transmitted from one end of the > pseudowire to the other are MPLS packets. Unless the pseudowire endpoints > are immediately adjacent, these MPLS packets must be transmitted through a > PSN tunnel. Any sort of PSN tunnel can be used, as long as it is possible > to transmit MPLS packets through it. The PSN tunnel can itself be an LSP, > but it could equally well be an IP tunnel, a GRE tunnel, an IPsec tunnel, or > any other sort of tunnel which can carry MPLS packets. Procedures for > setting up and maintaining the PSN tunnels are outside the scope of this > document." > > As i said your proposal has good merit, That's good to hear :) it's just that when we included > the above section we did not think it was necessary to repeat existing > RFCs in this one. True. I agree that the posted draft is a bit verbose. That said it does specify procedures that imho should be spelled out and are not captured in the above text. > if you think that the above section need more clarification we can > probably convince the PWE3 chairs to bend the last call rules and > make some minor modifications to it. Ideally a separate section on PW over IP in draft-ietf-pwe3-control-protocl-04.txt will suffice. I will get back to you soon with the text. Regards, rahul > > Thanks. > Luca > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: PWE3 and Congestion Date: Tue, 11 Nov 2003 05:31:55 +0200 Lines: 110 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-d5a9bcf1-f5a4-4b47-a418-4c54264622a4" Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Tue Nov 11 04:34:31 2003 Return-path: To: "Eric Rosen (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 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-d5a9bcf1-f5a4-4b47-a418-4c54264622a4 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A804.5B049B70" ------_=_NextPart_001_01C3A804.5B049B70 Content-Type: text/plain; charset="windows-1255" Eric and all, My gut feeling after re-reading the PWE3 congestion draft is that it clearly demonstrates one very important point: TCP-like responsiveness of the PWs to congestion is nearly impossible (or the price is too high to make it feasible). If this is correct, the important question,IMHO, is: Just how helpful is a PWE3 congestion detection/control mechanism that responds much slower that TCP? Forcing the PWE3 traffic to back off after the TCP traffic has been throttled already does not look nice. And it may just happen that early throttling of the TCP traffic combined with PWE3 mechanisms for avoiding false congestion detection would result in no PWE3 congestion ever being detected... My 2c. ---------------------------------------------------------------------------- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) ------_=_NextPart_001_01C3A804.5B049B70 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Eric = and=20 all,
My = gut feeling after=20 re-reading the PWE3 congestion draft is that it clearly demonstrates = one very=20 important point: TCP-like responsiveness of the PWs to congestion is=20 nearly=20 impossible (or the price is too high to make it = feasible).
 
If = this is correct,=20 the important question,IMHO, is: Just how helpful is a PWE3 congestion=20 detection/control mechanism that responds much slower that TCP?=20
 
Forcing the PWE3=20 traffic to back off after the TCP traffic has been throttled already = does not=20 look nice. And it may just happen that early throttling of the TCP = traffic=20 combined with PWE3 mechanisms for avoiding false congestion detection = would=20 result in no PWE3 congestion ever being detected...
My=20 2c.
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:   sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
 
------_=_NextPart_001_01C3A804.5B049B70-- ------=_NextPartTM-000-d5a9bcf1-f5a4-4b47-a418-4c54264622a4-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Mon, 10 Nov 2003 22:46:31 -0500 Organization: Cisco Systems, inc. Lines: 8 Sender: pwe3-admin@ietf.org Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 11 04:48:01 2003 Return-path: To: 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 Importance: Normal 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 The chairs requested that we take the matter of adoption of this draft to the list. Please comment. --Tom http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ali Sajassi Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 21:16:33 -0800 Lines: 166 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031107191442.02786a68@airborne.cisco.com> <001101c3a745$10b3b2a0$4d7032a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Tue Nov 11 06:18:10 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Scott Kotrla , "'Ali Sajassi'" , "'Luca Martini'" , pwe3@ietf.org In-Reply-To: <001101c3a745$10b3b2a0$4d7032a6@acer4wc5zk5t43> References: <4.3.2.7.2.20031107191442.02786a68@airborne.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 >The main point of passing the customer FCS is to be able to detect >errors/corruptions that may occur inside the PE/P nodes for ANY service >that does not change customer VLAN IDs, which could include all of the >services previously mentioned in an end-to-end Pseudowire architecture. > >Trying to address this by making sure that packets are no corrupted >inside P/PE boxes is next to impossible. It depends heavily on the >internal architecture of the PE/P nodes and varies in each >implementation. Not if the P/PE boxes are capable of doing CRC-protection of the packets when forwarding them from ingress to egress ports !! > FCS retention is the only known was of making an MPLS >network look like a wire to the customer. As I mentioned earlier even for some PtP services such as EVPL, FCS retention would not make sense because ingress VLAN and egress VLAN can be different ( just like FR/ATM VCs) !! -Ali >Thanks, > >Scott > >-----Original Message----- >From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Ali >Sajassi >Sent: Friday, November 07, 2003 9:33 PM >To: Luca Martini; pwe3@ietf.org >Cc: stbryant@cisco.com; Danny McPherson >Subject: Re: [PWE3] last call on control and ethernet drafts > > >Given that I won't be able to attend the IETF meeting this time because >of >scheduling conflict, I would like to restate my position in favor of FCS > >omission. > >The main point of passing customer FCS is to be able to detect >errors/corruptions that may occur inside the PE/P nodes - e.g., to >resemble >a characteristic similar to a wire. FCS pass-through is one way to >achieve >this. However, it only works for EPL service and does NOT work for EVPL, > >EPLAN, and EVPLAN. A better way of addressing this issue is to ensure >that >the packets are properly protected every step of the way (both inside >the >wire between the nodes as well as through the PE/P nodes). This way, we >ensure that we have a reliable transport mechanism that not only works >for >EPL, but also it works for other Ethernet services such as EVPL, EPLAN, >and >EVPLAN. Therefore, I am in favor of addressing this issue fundamentally >for >all Ethernet services and not just a patch work for EPL. > >-Ali > >At 02:19 PM 11/7/2003 -0700, Luca Martini wrote: > >yes, i was on vacation as well. > > > >I have to support the omission of the FCS from the PWE3 encapsulation >as > >that fit quite well with operations that IP routers have to perform. ( >to > >route IP the FCS of layer2 is always stripped and regenerated ). >Because > >of this many implementations have the FCS function in hardware at the >port > >level,which makes it quite easy to implement the current PWE3 > >design. This why we went down this path in the first place. Today >there > >are many implementations of the PWE3 encapsulation ( draft-martini >version > >) that are deployed and generating revenue for service providers. I >have > >not heard of any issues that could have been prevented by including an >FCS. > > > >Luca > > > >Stewart Bryant wrote: > > > >> > >>I have been out of town for a few days, and so have only just got > >>to this thread. > >> > >>The FCS topic was always planned for the Minneapolis agenda, so > >>I propose that we (the chairs) follow Danny's plan and put together > >>a summary of the consensus at the end of LC, post to the list, and > >>the WG discuss/ratify when we meet on 10th. I will post the summary > >>of the outcome to the list on the 11th. > >> > >>As stated below, the decision (either way) must be based on the > >>TECHNICAL merits of the proposal, and be based on the behavior > >>of the PW as a system. > >> > >>Stewart > >> > >> > >> > >> > >>Danny McPherson wrote: > >> > >>> > >>>Folks, > >>>I don't care if you work for an equipment manufacturer, service > >>>provider or at a fast food drive-thru, please state your positions > >>>based technical merit (I assure you that's all they'll be weighted > >>>on). Where someone has (or currently!) works is completely > >>>irrelevant! > >>> > >>>At this point the closest thing to consensus I've seen (yes, after > >>>re-reviewing ALL of the April and September discussions on this > >>>topic [again]) is that a separate draft seems to be the preferred > >>>option. > >>> > >>>Even that option has pitfalls, most of which have been expressed > >>>here (in this or the previous two threads on this subject), though > >>>it's still seems to be the most widely supported. > >>> > >>>Please continue discussing the issue and either Stewart or I will > >>>summarize what we believe to be consensus by the end of LC on the > >>>concerned WG documents. > >>> > >>>-danny > >>> > >>> > >>>_______________________________________________ > >>>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 > > >_______________________________________________ >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: Ali Sajassi Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 21:22:40 -0800 Lines: 155 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2DD9@i2km07-ukbr.domai n1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: , X-From: pwe3-admin@ietf.org Tue Nov 11 06:42:05 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: neil.2.harrison@bt.com, , , In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2DD9@i2km07-ukbr.domai n1.systemhost.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 At 07:54 AM 11/10/2003 +0000, neil.2.harrison@bt.com wrote: >I have checked with my colleagures here and BT do not agree with this view >as a general architectural principle. When dealing with simple >client/server encapsulation (between any arbitrary pair of technologies) >the general maxim should be to leave the client layer PDU structure alone >to ensure layer independence.....so this is *any* change of the client >layer, which of course also includes any compression behaviour. Do you and your colleagues have the same view for other services that I mentioned (EVPL, EPLAN, and EVPLAN) or do you have this view for EPL ? -Ali >regards, Neil > > > -----Original Message----- > > From: Ali Sajassi [mailto:sajassi@cisco.com] > > Sent: 08 November 2003 03:33 > > To: Luca Martini; pwe3@ietf.org > > Cc: stbryant@cisco.com; Danny McPherson > > Subject: Re: [PWE3] last call on control and ethernet drafts > > > > > > > > Given that I won't be able to attend the IETF meeting this > > time because of > > scheduling conflict, I would like to restate my position in > > favor of FCS > > omission. > > > > The main point of passing customer FCS is to be able to detect > > errors/corruptions that may occur inside the PE/P nodes - > > e.g., to resemble > > a characteristic similar to a wire. FCS pass-through is one > > way to achieve > > this. However, it only works for EPL service and does NOT > > work for EVPL, > > EPLAN, and EVPLAN. A better way of addressing this issue is > > to ensure that > > the packets are properly protected every step of the way > > (both inside the > > wire between the nodes as well as through the PE/P nodes). > > This way, we > > ensure that we have a reliable transport mechanism that not > > only works for > > EPL, but also it works for other Ethernet services such as > > EVPL, EPLAN, and > > EVPLAN. Therefore, I am in favor of addressing this issue > > fundamentally for > > all Ethernet services and not just a patch work for EPL. > > > > -Ali > > > > At 02:19 PM 11/7/2003 -0700, Luca Martini wrote: > > >yes, i was on vacation as well. > > > > > >I have to support the omission of the FCS from the PWE3 > > encapsulation as > > >that fit quite well with operations that IP routers have to > > perform. ( to > > >route IP the FCS of layer2 is always stripped and > > regenerated ). Because > > >of this many implementations have the FCS function in > > hardware at the port > > >level,which makes it quite easy to implement the current PWE3 > > >design. This why we went down this path in the first place. > > Today there > > >are many implementations of the PWE3 encapsulation ( > > draft-martini version > > >) that are deployed and generating revenue for service > > providers. I have > > >not heard of any issues that could have been prevented by > > including an FCS. > > > > > >Luca > > > > > >Stewart Bryant wrote: > > > > > >> > > >>I have been out of town for a few days, and so have only just got > > >>to this thread. > > >> > > >>The FCS topic was always planned for the Minneapolis agenda, so > > >>I propose that we (the chairs) follow Danny's plan and put together > > >>a summary of the consensus at the end of LC, post to the list, and > > >>the WG discuss/ratify when we meet on 10th. I will post the summary > > >>of the outcome to the list on the 11th. > > >> > > >>As stated below, the decision (either way) must be based on the > > >>TECHNICAL merits of the proposal, and be based on the behavior > > >>of the PW as a system. > > >> > > >>Stewart > > >> > > >> > > >> > > >> > > >>Danny McPherson wrote: > > >> > > >>> > > >>>Folks, > > >>>I don't care if you work for an equipment manufacturer, service > > >>>provider or at a fast food drive-thru, please state your positions > > >>>based technical merit (I assure you that's all they'll be weighted > > >>>on). Where someone has (or currently!) works is completely > > >>>irrelevant! > > >>> > > >>>At this point the closest thing to consensus I've seen (yes, after > > >>>re-reviewing ALL of the April and September discussions on this > > >>>topic [again]) is that a separate draft seems to be the preferred > > >>>option. > > >>> > > >>>Even that option has pitfalls, most of which have been expressed > > >>>here (in this or the previous two threads on this subject), though > > >>>it's still seems to be the most widely supported. > > >>> > > >>>Please continue discussing the issue and either Stewart or I will > > >>>summarize what we believe to be consensus by the end of LC on the > > >>>concerned WG documents. > > >>> > > >>>-danny > > >>> > > >>> > > >>>_______________________________________________ > > >>>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 > > > > > > _______________________________________________ > > 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: Ali Sajassi Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 21:53:52 -0800 Lines: 27 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stbryant@cisco.com, "'Danny McPherson'" X-From: pwe3-admin@ietf.org Tue Nov 11 06:55:04 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "David Allan" , "'Scott Kotrla'" , "'Ali Sajassi'" , "'Luca Martini'" , 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 >Eric put it quite well when he stated that what we really want is an e2e >integrity check in all modes. At the same time providing this functionality >is impossible without modifying the client layer, which is a non starter as >a solution. So Ali's suggestion that we need a comprehensive solution for >all modes is demonstratably unachievable and carriage of FCS e2e for some >modes is the best we can do. As such we should not preclude it. What I meant was instead of fixing this problem for one mode, we should try to fix it for all modes. And as you said if modifying the client layer is not an option, then the only option we are left with is to ensure that the forwarding of packets within the P/PE nodes are CRC protected. This way, we have a reliable transport for all modes. -Ali >Further I would prefer that this is in the base documents, Andy Nick and I >have a draft that shows the required changes are minor. > >rgds >Dave > >_______________________________________________ >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: Ali Sajassi Subject: RE: last call on control and ethernet drafts Date: Mon, 10 Nov 2003 22:29:01 -0800 Lines: 17 Sender: pwe3-admin@ietf.org References: <6.0.0.22.2.20031110154610.02e45990@mail.comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Prayson Pate" , "Shahram Davari" , "PWE3 WG \(E-mail\)" X-From: pwe3-admin@ietf.org Tue Nov 11 07:30:07 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Andrew G. Malis" , Keith Knightson In-Reply-To: <6.0.0.22.2.20031110154610.02e45990@mail.comcast.net> References: 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 >That's a good point to mention explicitly - I'll add to the draft that the >FCS SHOULD (or MUST?) be examined at the ingress to prevent errored frames >that would be discarded at the receiving CE anyway from wasting bandwidth. Same error detection logic applies to within a P/PE nodes such that while forwarding packets from ingress to egress ports of a PE/P node and error is detected, then the packet should be discarded. If the platform cannot do that and the error can only be detected by the CE (via FCS retention), then isolating the location of the error would be an interesting task !! If the P/PE nodes have such capability and FCS retention is still needed, then I would question the value added of it ? Have we run any test to see the probability of an undetected error via platforms capable of CRC-protection ? If the probability of it is negligible (e.g., 10**-12), does it still make sense to do it ? -Ali From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: last call on control and ethernet drafts Date: Tue, 11 Nov 2003 01:30:33 -0700 Lines: 70 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031110221051.025fa688@airborne.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "'Prayson Pate'" , "'Shahram Davari'" , "'PWE3 WG (E-mail)'" X-From: pwe3-admin@ietf.org Tue Nov 11 09:38:09 2003 Return-path: In-reply-to: <4.3.2.7.2.20031110221051.025fa688@airborne.cisco.com> To: "'Ali Sajassi'" , "'Andrew G. Malis'" , "'Keith Knightson'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 a service provider writing RFPs for equipment vendors, I can very easily require the FCS to be kept and I can do packet captures to validate compliance in a lab setting. Asking an equipment provider to prove that their box is incapable of corrupting packets is a much more daunting task, especially given that PWs may be riding across an installed base of P routers that may not meet these "packet corruption requirements." Other than the minimal effect of 4 extra bytes, FCS retention affects the endpoints only and not every P router in between. As far as isolating the problem, a service providers can do fault isolation using tools like loopbacks once it is know there is a problem. If it is not known that the network is broken, there's no chance of ever fixing it. If equipment providers have done their jobs right, internal corruptions of packets should never leave the equipment. However, if equipment gets into the network that is not performing correctly, it is an absolute service provider requirement that it be possible to determine that this unfortunate event has transpired. As I have previously stated, it is possible to architect a network where VLANs are never swapped in any service. In such a network, service providers shouldn't be forced to toss customer data away just because other service providers might be doing VLAN swapping. The option to make a service look like a Pseudowire should be there for any service provider that has compliant PEs in the network and wants to turn it on. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Ali Sajassi Sent: Monday, November 10, 2003 11:29 PM To: Andrew G. Malis; Keith Knightson Cc: Prayson Pate; Shahram Davari; PWE3 WG (E-mail) Subject: RE: [PWE3] last call on control and ethernet drafts >That's a good point to mention explicitly - I'll add to the draft that the >FCS SHOULD (or MUST?) be examined at the ingress to prevent errored frames >that would be discarded at the receiving CE anyway from wasting bandwidth. Same error detection logic applies to within a P/PE nodes such that while forwarding packets from ingress to egress ports of a PE/P node and error is detected, then the packet should be discarded. If the platform cannot do that and the error can only be detected by the CE (via FCS retention), then isolating the location of the error would be an interesting task !! If the P/PE nodes have such capability and FCS retention is still needed, then I would question the value added of it ? Have we run any test to see the probability of an undetected error via platforms capable of CRC-protection ? If the probability of it is negligible (e.g., 10**-12), does it still make sense to do it ? -Ali _______________________________________________ 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: Mark Seery Subject: RE: last call on control and ethernet drafts Date: Tue, 11 Nov 2003 01:29:47 -0800 (PST) Lines: 38 Sender: pwe3-admin@ietf.org References: <000001c3a82e$189732f0$089832a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1527651669-1068542987=:47319" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 11 10:30:06 2003 Return-path: To: Scott Kotrla In-Reply-To: <000001c3a82e$189732f0$089832a6@acer4wc5zk5t43> 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 --0-1527651669-1068542987=:47319 Content-Type: text/plain; charset=us-ascii Scott Kotrla wrote: As a service provider writing RFPs for equipment vendors, I can very easily require the FCS to be kept..... Scott, please do not take my following comments as a rebuttal to your points, because I think enough people have expressed interest in this, for all types of logical transport/separation of layer arguments etc in addition to what you have said. However, I would like to make the following observation for your consideration, in what ever present or future context the observation might apply: At some point here we are establishing an architectural house of cards. If we can not trust the integrity of a PW, then it begs the question how will you trust any other service you offer based on IP or MPLS, and can you even trust the integrity of the PW control plane, making use of a PW data plane, and if you can't....... --0-1527651669-1068542987=:47319 Content-Type: text/html; charset=us-ascii
 
Scott Kotrla <scott.kotrla@mci.com> wrote:

As a service provider writing RFPs for equipment vendors, I can very
easily require the FCS to be kept.....

<snipped to the end>

Scott, please do not take my following comments as a rebuttal to your points, because I think enough people have expressed interest in this, for all types of logical transport/separation of layer arguments etc in addition to what you have said.
 
However, I would like to make the following observation for your consideration, in what ever present or future context the observation might apply:
 
At some point here we are establishing an architectural house of cards. If we can not trust the integrity of a PW, then it begs the question how will you trust any other service you offer based on IP or MPLS, and can you even trust the integrity of the PW control plane, making use of a PW data plane, and if you can't.......
 
 
 
 
--0-1527651669-1068542987=:47319-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: last call on control and ethernet drafts Date: Tue, 11 Nov 2003 11:07:09 -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 Cc: , X-From: pwe3-admin@ietf.org Tue Nov 11 12:08:04 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] last call on control and ethernet drafts thread-index: AcOoFmXyWrqfz6n+S/G3fyrbdCQbQgAIKgvg To: , , X-OriginalArrivalTime: 11 Nov 2003 11:07:10.0110 (UTC) FILETIME=[F3AECBE0:01C3A843] 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 Ali Sajassi wrote 11 November 2003 05:23 > > At 07:54 AM 11/10/2003 +0000, neil.2.harrison@bt.com wrote: > >I have checked with my colleagures here and BT do not agree=20 > with this view=20 > >as a general architectural principle. When dealing with simple=20 > >client/server encapsulation (between any arbitrary pair of=20 > technologies)=20 > >the general maxim should be to leave the client layer PDU=20 > structure alone=20 > >to ensure layer independence.....so this is *any* change of=20 > the client=20 > >layer, which of course also includes any compression behaviour. >=20 > Do you and your colleagues have the same view for other=20 > services that I=20 > mentioned (EVPL, EPLAN, and EVPLAN) or do you have this view for EPL ? >=20 > -Ali Hi Ali, I understand your point. Yes EPL constrains a normally cnls = client to behave in a form of p2p co-ps mode, so this is an exception = rather than the rule here. However (and I checked this with my func = arch expert colleagues working on ethernet yesterday), although the FCS = definitely belongs to the ethernet client, in a G.805/809 func arch = sense the FCS resides in the adaptation function rather than the trail = term function. Now since a client layer's link-connections are provided = server layer trails, this means that if any client PDU overhead is = changed (during client->server adaptation) then any FCS present will = need a linear update here. This is no different in principle to = modifying the HEC in ATM cells say to the VPI/VCI changes on different = link-connections. However, the general maxim of 'don't touch the client layer signal if it = can be avoided' still always holds. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott W Brim Subject: draft-ietf-pwe3-satop-00.txt and EF Date: Mon, 10 Nov 2003 20:11:30 -0600 Lines: 9 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-From: pwe3-admin@ietf.org Tue Nov 11 16:18:05 2003 Return-path: To: "pwe3@ietf.org" Mail-Followup-To: Scott W Brim , "pwe3@ietf.org" Content-Disposition: inline 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 I think the diffserv chairs were right and the text in the draft as it stands is fine. You don't want to specify a particular PHB because PHBs can be superceded. Also consider the long argument over the definition of the EF PHB. Also what you're really interested in is a PDB, not just a PHB. There is a simple way to deal with this, which is that instead of invoking someone's current definition of the solution ("EF"), just state the requirements. An extra benefit is that the requirements are well-documented. The draft already does just this. Leave it, it's okay as it is. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Date: Tue, 11 Nov 2003 23:02:00 +0200 Lines: 106 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" X-From: pwe3-admin@ietf.org Tue Nov 11 22:26:09 2003 Return-path: To: "Yaakov Stein (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 Yaakov and all, I'd like to present the technical problem I have with the current text of draft-stein-pwe3-pwce2e-00.txt and options for solving this problem. My problem is with the following para in Section 3: The ideal way of handling a PWCE2E packet is to have the CE perform the service specific encapsulation and to prepend the (inner) PW label, but no (outer) MPLS transport labels. The PE, which participates in the provider network signaling, then adds the appropriate MPLS labels as required. IMO, it is easy to see why this will not work as written. Please consider the following use case: 1. There are three CEs (CE-1, CE-2 and CE-3) attached to 3 PEs (PE-1, PE-2 and PE3 respectively). 2. In each case the link between CE-i and PE-i is a "single-hop" link (i.e., there are no LSRs in the path, but there may be L2 switches - Ethernet, FR/ATM etc). 3. You want to run two PWs: a) PW-12 runs between CE-1 and CE-2 b)PW-13 runs between CE-1 and CE-3. How can PE-1 (which both these PWs have to cross on their ways to their peer CEs) know which transport labels to add to packets received from CE-1? This decision CANNOT be based on the PW labels in these packets, because these labels are independently allocated by CE-2 and CE-3 respectively, so that nothing prevents them from being equal (accidentally or else). And inspection of the encapsulated data will not help either. (BTW, this is exactly the difference between MPLS and, say, FR or ATM: in the latter cases, DLCI or VCI/VPI values are unique on the attachment link and known to the PE, in the former case they are not.) How can this be fixed? I see three ways to do so. 1. Limit this case to one PW per CE. IMO, this is a very problematic limitation (one could say, that it is ultimately non-scalable!) and does not justify any action wrt the existing documents. 2. Allow the CE to push both the PW and transport labels on top of the payload and PWE3 control info. This would make it equivalent to the "normal" PW,and no technical changes in the architecture doc are required. The transport label can be obtained in many different ways, including usage of the MPLS UNI (as suggested by David Sinicrope). 3. Use PW stitching. This would introduce a new element in the PWE3 architecture - the Pseudo-Wire Stitching Function (PSF) - located in the PEs. The PSF would operate like following: a) Terminate a "usual" PW running between two PEs adjacent to the CEs in question. Note that the PEs must exchange their incoming PW labels for this PW just as in the "normal" case b) Terminate the "spoke" PW between the CE and its adjacent PE. This PW would not require transport labels because the CE<-->PE transport LSPs are just one hop, and PHP can be applied to them. The PW labels for the spoke PWs would be exchanged between the CE and its adjacent PE in the usual way. c) Stitch the spoke PW with the PE-PE PW. Such a stitching would: * Leave the PW packet payload and control info (if any) intact * Swap the inner label * In one direction (CE-->PE), push the transport label(s) required for the PE-PE PW. Opposite to the PW IWFs, one and only one PSF type is required. The resulting architecture resembles the Hierarchical VPLS defined in draft-ietf-l2vln-vpls-ldp-01.txt (hence the term "Spoke PW"). Its advantage stems from moving the service-specific IWF functionality towards the CE (and hence may be of special importance for TDM PWs), while possibility of misconfiguration (e.g., connection of IWFs with different service types) should be considered as a disadvantage. Another disadvantage, of course, is introduction of a new (albeit simple) architectural element in the high-speed data plane. IMO, any technical changes in the architecture document should be considered only if we reach a conclusion that advantages of the PW stitching option outweigh its disadvantages. Hope these notes would be helpful. ---------------------------------------------------------------------------- -------- 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: Ali Sajassi Subject: Re: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 13:50:17 -0800 Lines: 84 Sender: pwe3-admin@ietf.org References: <5.1.0.14.2.20031111182048.01fef850@mail.expressoweb.co.uk> <000001c3a885$b212a930$f48032a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org, ali Sajassi X-From: pwe3-admin@ietf.org Tue Nov 11 22:51:05 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Scott Kotrla , stds-802-1@ieee.org In-Reply-To: <000001c3a885$b212a930$f48032a6@acer4wc5zk5t43> References: <5.1.0.14.2.20031111182048.01fef850@mail.expressoweb.co.uk> 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, I tried to explain the issue and the possible solution in the PWE3 mailing list; however, since you have brought this discussion to 802.1 group, it is a good place to reference IEEE standards regarding this issue. This requirement is nothing new to IEEE and has already been captured in 802.1 standards. IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC bridges) talks about exactly what you want and it suggests a solution for it without passing original FCS transparently. If you think about it, you see the situation of passing an Ethernet frames over bunch of bridges while keeping the integrity of FCS is the same issue as the one discussed for EoPW (over PtP PW). Either the scheme that is discussed in Annex F or a derivative of it can be implemented to satisfy the requirement without passing the client FCS transparently. So instead of the solution to the requirement, it would be good if the requirement for this issue be clearly stated in your RFP. Regards, Ali At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: >I am new to the 802 standards development effort, so please bear with me >if I break protocol. > >I'd like to open up the floodgate on the issue of Customer FCS >Retention. I am very interested in what other service providers have to >say. We have recently beat this to death in PWE3, and we haven't seen >any service providers against it. It has been agreed that the Ethernet >PWE3 draft will be updated to make stripping the Ethernet FCS the >default action rather than the mandatory action. > >Since 802.1ad is specifically for service providers, I think this is a >logical place to put this. However, I don't really care where it goes, >but as a service provider, I can definitively say that it is a >requirement. MCI is already requiring dual FCS in RFP requirements, and >it is preferred although not required that there be a standard behind >this at some point in the future. > >I am a firm believer that this functionality is required to make 802.1ad >useful to service providers. Service providers require as much >transparency as is possible. Keeping the customer FCS allows a service >provider to validate end-to-end that a packet was not corrupted. > >As a service provider writing RFP requirements for equipment vendors, I >can very easily require the FCS to be kept and I can do packet captures >to validate compliance in a lab setting. Asking an equipment provider >to prove that their box is incapable of corrupting packets is a much >more daunting task, especially given that service VLANs may be riding >across an installed base of switches that may not meet these "packet >corruption requirements." Other than the minimal effect of 4 extra >bytes, FCS retention affects the endpoints only and not every switch in >between. > >As far as isolating the problem, a service providers can do fault >isolation using tools like loopbacks once it is know there is a problem. >If it is not known that the network is broken, there's no chance of ever >fixing it. If equipment providers have done their jobs right, internal >corruptions of packets should never leave the equipment. However, if >equipment gets into the network that is not performing correctly, it is >an absolute service provider requirement that it be possible to >determine that this unfortunate event has transpired. > >My recommendation is that stacking a Service FCS along with a Service >VLAN tag be an optional feature, with the default behavior being not to >do so. This will not affect equipment that does not support it, but it >will allow service providers who are willing to give up 4 bytes the >capabilities to build more resilient and transparent networks. I >understand that 802.3 would have to sign off on this as well, but would >like to get agreement in 802.1 first. > >I'd like to focus on whether or not this should be worked on and not >specifically where it should go at this point. > >I'd like to understand concerns that anyone may have. > >Thanks, > >Scott From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Shahram Davari Subject: RE: Re: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 14:22:25 -0800 Lines: 135 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 11 23:24:02 2003 Return-path: To: "'Ali Sajassi'" , Scott Kotrla , stds-802-1@ieee.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 Ali, I think when folks talk about passing the customer FCS transparently, they mean reuse it if it is valid. This is what 802.1D says: "If both a) and c) are true, then the FCS carried in the received frame is still valid, and the ideal approach would be to reuse this value as the FCS for the transmitted frame." Yours, -Shahram >-----Original Message----- >From: Ali Sajassi [mailto:sajassi@cisco.com] >Sent: Tuesday, November 11, 2003 4:50 PM >To: Scott Kotrla; stds-802-1@ieee.org >Cc: pwe3@ietf.org; ali Sajassi >Subject: [PWE3] Re: [802.1] 802.1ad Customer FCS Retention > > >Scott, > >I tried to explain the issue and the possible solution in the >PWE3 mailing >list; however, since you have brought this discussion to 802.1 >group, it is >a good place to reference IEEE standards regarding this issue. This >requirement is nothing new to IEEE and has already been >captured in 802.1 >standards. > >IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC >bridges) >talks about exactly what you want and it suggests a solution >for it without >passing original FCS transparently. If you think about it, you see the >situation of passing an Ethernet frames over bunch of bridges >while keeping >the integrity of FCS is the same issue as the one discussed >for EoPW (over >PtP PW). > >Either the scheme that is discussed in Annex F or a derivative >of it can be >implemented to satisfy the requirement without passing the client FCS >transparently. > >So instead of the solution to the requirement, it would be good if the >requirement for this issue be clearly stated in your RFP. > >Regards, >Ali > >At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: > >>I am new to the 802 standards development effort, so please >bear with me >>if I break protocol. >> >>I'd like to open up the floodgate on the issue of Customer FCS >>Retention. I am very interested in what other service >providers have to >>say. We have recently beat this to death in PWE3, and we haven't seen >>any service providers against it. It has been agreed that >the Ethernet >>PWE3 draft will be updated to make stripping the Ethernet FCS the >>default action rather than the mandatory action. >> >>Since 802.1ad is specifically for service providers, I think this is a >>logical place to put this. However, I don't really care >where it goes, >>but as a service provider, I can definitively say that it is a >>requirement. MCI is already requiring dual FCS in RFP >requirements, and >>it is preferred although not required that there be a standard behind >>this at some point in the future. >> >>I am a firm believer that this functionality is required to >make 802.1ad >>useful to service providers. Service providers require as much >>transparency as is possible. Keeping the customer FCS allows >a service >>provider to validate end-to-end that a packet was not corrupted. >> >>As a service provider writing RFP requirements for equipment >vendors, I >>can very easily require the FCS to be kept and I can do >packet captures >>to validate compliance in a lab setting. Asking an equipment provider >>to prove that their box is incapable of corrupting packets is a much >>more daunting task, especially given that service VLANs may be riding >>across an installed base of switches that may not meet these "packet >>corruption requirements." Other than the minimal effect of 4 extra >>bytes, FCS retention affects the endpoints only and not every >switch in >>between. >> >>As far as isolating the problem, a service providers can do fault >>isolation using tools like loopbacks once it is know there is >a problem. >>If it is not known that the network is broken, there's no >chance of ever >>fixing it. If equipment providers have done their jobs >right, internal >>corruptions of packets should never leave the equipment. However, if >>equipment gets into the network that is not performing >correctly, it is >>an absolute service provider requirement that it be possible to >>determine that this unfortunate event has transpired. >> >>My recommendation is that stacking a Service FCS along with a Service >>VLAN tag be an optional feature, with the default behavior >being not to >>do so. This will not affect equipment that does not support >it, but it >>will allow service providers who are willing to give up 4 bytes the >>capabilities to build more resilient and transparent networks. I >>understand that 802.3 would have to sign off on this as well, >but would >>like to get agreement in 802.1 first. >> >>I'd like to focus on whether or not this should be worked on and not >>specifically where it should go at this point. >> >>I'd like to understand concerns that anyone may have. >> >>Thanks, >> >>Scott > > >_______________________________________________ >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: draft-ietf-pwe3-satop-00.txt and EF Date: Wed, 12 Nov 2003 00:28:32 +0200 Lines: 39 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 11 23:31:02 2003 Return-path: To: "'Scott W Brim'" 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 Scott, Thank you for a prompt anc clear-cut response. ---------------------------------------------------------------------------- -------- 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: Scott W Brim [mailto:swb@employees.org] > Sent: Tuesday, November 11, 2003 4:12 AM > To: pwe3@ietf.org > Subject: [PWE3] draft-ietf-pwe3-satop-00.txt and EF > > > I think the diffserv chairs were right and the text in the draft as it > stands is fine. You don't want to specify a particular PHB > because PHBs > can be superceded. Also consider the long argument over the > definition > of the EF PHB. Also what you're really interested in is a > PDB, not just > a PHB. There is a simple way to deal with this, which is that instead > of invoking someone's current definition of the solution ("EF"), just > state the requirements. An extra benefit is that the requirements are > well-documented. The draft already does just this. Leave > it, it's okay > as it is. > > _______________________________________________ > 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 Kotrla Subject: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 15:28:29 -0700 Lines: 141 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031111133156.0265e600@airborne.cisco.com> 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 Nov 11 23:32:20 2003 Return-path: In-reply-to: <4.3.2.7.2.20031111133156.0265e600@airborne.cisco.com> To: "'Ali Sajassi'" , stds-802-1@ieee.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 a service provider, my two issues with this approach are as follows: 1. Every box end-to-end has to do this. Some of the boxes in the middle may already be deployed and may not support this functionality. My assumption is that the extra FCS could be added in such a way that intermediate switches wouldn't have to know about it or act on it. 2. I have no way of proving one way or the other whether equipment complies. If I add an FCS I can very easily validate whether or not a vendor complies. Neither solution is implemented today, so an FCS seems a lot simpler way to do things. Providers build scalable networks by adding layers. While this has been addressed previously in 802.1, it has been discussed in regards to enterprise applications and not provider applications. Providers have different requirements than enterprises do, namely in the requirement to add layers and separation. MAC-in-MAC would meet my needs, but I'd rather not go that route since it adds overhead, and I wouldn't be using the extra MAC address overhead. Service providers are not looking to turn Ethernet completely into SONET. However, we are looking to port the small amount of SONET functionality that is regularly implemented into Ethernet so that carrier class Ethernet implementations are possible. Line and Path level error checking are a key part of these requirements. I believe it was agreed in PWE3 that this functionality should be supported for those carriers who want to implement it. I would agree that the 802.1ad and PWE3 applications are very similar and would encourage the same agreement to be reached. I'm not asking for mandatory FCS retention. I am asking for optional FCS retention. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Ali Sajassi Sent: Tuesday, November 11, 2003 2:50 PM To: Scott Kotrla; stds-802-1@ieee.org Cc: pwe3@ietf.org; ali Sajassi Subject: Re: [802.1] 802.1ad Customer FCS Retention Scott, I tried to explain the issue and the possible solution in the PWE3 mailing list; however, since you have brought this discussion to 802.1 group, it is a good place to reference IEEE standards regarding this issue. This requirement is nothing new to IEEE and has already been captured in 802.1 standards. IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC bridges) talks about exactly what you want and it suggests a solution for it without passing original FCS transparently. If you think about it, you see the situation of passing an Ethernet frames over bunch of bridges while keeping the integrity of FCS is the same issue as the one discussed for EoPW (over PtP PW). Either the scheme that is discussed in Annex F or a derivative of it can be implemented to satisfy the requirement without passing the client FCS transparently. So instead of the solution to the requirement, it would be good if the requirement for this issue be clearly stated in your RFP. Regards, Ali At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: >I am new to the 802 standards development effort, so please bear with me >if I break protocol. > >I'd like to open up the floodgate on the issue of Customer FCS >Retention. I am very interested in what other service providers have to >say. We have recently beat this to death in PWE3, and we haven't seen >any service providers against it. It has been agreed that the Ethernet >PWE3 draft will be updated to make stripping the Ethernet FCS the >default action rather than the mandatory action. > >Since 802.1ad is specifically for service providers, I think this is a >logical place to put this. However, I don't really care where it goes, >but as a service provider, I can definitively say that it is a >requirement. MCI is already requiring dual FCS in RFP requirements, and >it is preferred although not required that there be a standard behind >this at some point in the future. > >I am a firm believer that this functionality is required to make 802.1ad >useful to service providers. Service providers require as much >transparency as is possible. Keeping the customer FCS allows a service >provider to validate end-to-end that a packet was not corrupted. > >As a service provider writing RFP requirements for equipment vendors, I >can very easily require the FCS to be kept and I can do packet captures >to validate compliance in a lab setting. Asking an equipment provider >to prove that their box is incapable of corrupting packets is a much >more daunting task, especially given that service VLANs may be riding >across an installed base of switches that may not meet these "packet >corruption requirements." Other than the minimal effect of 4 extra >bytes, FCS retention affects the endpoints only and not every switch in >between. > >As far as isolating the problem, a service providers can do fault >isolation using tools like loopbacks once it is know there is a problem. >If it is not known that the network is broken, there's no chance of ever >fixing it. If equipment providers have done their jobs right, internal >corruptions of packets should never leave the equipment. However, if >equipment gets into the network that is not performing correctly, it is >an absolute service provider requirement that it be possible to >determine that this unfortunate event has transpired. > >My recommendation is that stacking a Service FCS along with a Service >VLAN tag be an optional feature, with the default behavior being not to >do so. This will not affect equipment that does not support it, but it >will allow service providers who are willing to give up 4 bytes the >capabilities to build more resilient and transparent networks. I >understand that 802.3 would have to sign off on this as well, but would >like to get agreement in 802.1 first. > >I'd like to focus on whether or not this should be worked on and not >specifically where it should go at this point. > >I'd like to understand concerns that anyone may have. > >Thanks, > >Scott From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: Re: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 15:32:52 -0700 Lines: 163 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCE3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> 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 Nov 11 23:40:06 2003 Return-path: In-reply-to: <4B6D09F3B826D411A67300D0B706EFDE0115CCE3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> To: "'Shahram Davari'" , "'Ali Sajassi'" , stds-802-1@ieee.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 The problem is that when I add or swap a Service VLAN tag I change the frame and the FCS is no longer valid. Most switches today toss the FCS after confirming that no corruption occurred on the wire. I'd like to keep that functionality the same everywhere except for the new Provider Edge interface, where a new FCS can be added, facilitating no changes in the intermediate P switches. It is much easier to add new functionality on two new PE interfaces that are not yet fully defined than it is to add new functionality on all PE and P interfaces in the network. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Shahram Davari Sent: Tuesday, November 11, 2003 3:22 PM To: 'Ali Sajassi'; Scott Kotrla; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] Re: [802.1] 802.1ad Customer FCS Retention Ali, I think when folks talk about passing the customer FCS transparently, they mean reuse it if it is valid. This is what 802.1D says: "If both a) and c) are true, then the FCS carried in the received frame is still valid, and the ideal approach would be to reuse this value as the FCS for the transmitted frame." Yours, -Shahram >-----Original Message----- >From: Ali Sajassi [mailto:sajassi@cisco.com] >Sent: Tuesday, November 11, 2003 4:50 PM >To: Scott Kotrla; stds-802-1@ieee.org >Cc: pwe3@ietf.org; ali Sajassi >Subject: [PWE3] Re: [802.1] 802.1ad Customer FCS Retention > > >Scott, > >I tried to explain the issue and the possible solution in the >PWE3 mailing >list; however, since you have brought this discussion to 802.1 >group, it is >a good place to reference IEEE standards regarding this issue. This >requirement is nothing new to IEEE and has already been >captured in 802.1 >standards. > >IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC >bridges) >talks about exactly what you want and it suggests a solution >for it without >passing original FCS transparently. If you think about it, you see the >situation of passing an Ethernet frames over bunch of bridges >while keeping >the integrity of FCS is the same issue as the one discussed >for EoPW (over >PtP PW). > >Either the scheme that is discussed in Annex F or a derivative >of it can be >implemented to satisfy the requirement without passing the client FCS >transparently. > >So instead of the solution to the requirement, it would be good if the >requirement for this issue be clearly stated in your RFP. > >Regards, >Ali > >At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: > >>I am new to the 802 standards development effort, so please >bear with me >>if I break protocol. >> >>I'd like to open up the floodgate on the issue of Customer FCS >>Retention. I am very interested in what other service >providers have to >>say. We have recently beat this to death in PWE3, and we haven't seen >>any service providers against it. It has been agreed that >the Ethernet >>PWE3 draft will be updated to make stripping the Ethernet FCS the >>default action rather than the mandatory action. >> >>Since 802.1ad is specifically for service providers, I think this is a >>logical place to put this. However, I don't really care >where it goes, >>but as a service provider, I can definitively say that it is a >>requirement. MCI is already requiring dual FCS in RFP >requirements, and >>it is preferred although not required that there be a standard behind >>this at some point in the future. >> >>I am a firm believer that this functionality is required to >make 802.1ad >>useful to service providers. Service providers require as much >>transparency as is possible. Keeping the customer FCS allows >a service >>provider to validate end-to-end that a packet was not corrupted. >> >>As a service provider writing RFP requirements for equipment >vendors, I >>can very easily require the FCS to be kept and I can do >packet captures >>to validate compliance in a lab setting. Asking an equipment provider >>to prove that their box is incapable of corrupting packets is a much >>more daunting task, especially given that service VLANs may be riding >>across an installed base of switches that may not meet these "packet >>corruption requirements." Other than the minimal effect of 4 extra >>bytes, FCS retention affects the endpoints only and not every >switch in >>between. >> >>As far as isolating the problem, a service providers can do fault >>isolation using tools like loopbacks once it is know there is >a problem. >>If it is not known that the network is broken, there's no >chance of ever >>fixing it. If equipment providers have done their jobs >right, internal >>corruptions of packets should never leave the equipment. However, if >>equipment gets into the network that is not performing >correctly, it is >>an absolute service provider requirement that it be possible to >>determine that this unfortunate event has transpired. >> >>My recommendation is that stacking a Service FCS along with a Service >>VLAN tag be an optional feature, with the default behavior >being not to >>do so. This will not affect equipment that does not support >it, but it >>will allow service providers who are willing to give up 4 bytes the >>capabilities to build more resilient and transparent networks. I >>understand that 802.3 would have to sign off on this as well, >but would >>like to get agreement in 802.1 first. >> >>I'd like to focus on whether or not this should be worked on and not >>specifically where it should go at this point. >> >>I'd like to understand concerns that anyone may have. >> >>Thanks, >> >>Scott > > >_______________________________________________ >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: Ali Sajassi Subject: RE: Re: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 14:55:49 -0800 Lines: 371 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCE3@nt-exch-yow.pmc_n t.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_69715545==_.ALT" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 11 23:57:04 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Shahram Davari , "'Ali Sajassi'" , Scott Kotrla , stds-802-1@ieee.org In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCE3@nt-exch-yow.pmc_n t.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 --=====================_69715545==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 02:22 PM 11/11/2003 -0800, Shahram Davari wrote: >Ali, > >I think when folks talk about passing the customer FCS transparently, they >mean reuse it if it is valid. >This is what 802.1D says: > >"If both a) and c) are true, then the FCS carried in the received frame is >still valid, and the ideal approach >would be to reuse this value as the FCS for the transmitted frame." With respect to .1ad, case (d) is the one to consider since either customer tag is changed or provider tag is added. And the Annex recommends a solution without adding additional FCS (4 bytes). Also, once the platform is capable of supporting case (d), it can apply the same method to case (a) and (c). I think the important requirement is what is stated in the document: "In each case, it is important to ensure that there is a low probability of additional undetected errors being generated by corruption of the data portion of the frame between removal of the old FCS and computation of the new one, which would result in the transmitted frame carrying invalid data and a valid FCS. Such corruption might occur, for example, as a result of the effect of environmental noise on the operation of the Bridge hardware." And as mentioned before there are several ways to skin this cat but we need to differentiate between the requirement and its corresponding solution. -Ali >Yours, >-Shahram > > >-----Original Message----- > >From: Ali Sajassi [mailto:sajassi@cisco.com] > >Sent: Tuesday, November 11, 2003 4:50 PM > >To: Scott Kotrla; stds-802-1@ieee.org > >Cc: pwe3@ietf.org; ali Sajassi > >Subject: [PWE3] Re: [802.1] 802.1ad Customer FCS Retention > > > > > >Scott, > > > >I tried to explain the issue and the possible solution in the > >PWE3 mailing > >list; however, since you have brought this discussion to 802.1 > >group, it is > >a good place to reference IEEE standards regarding this issue. This > >requirement is nothing new to IEEE and has already been > >captured in 802.1 > >standards. > > > >IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC > >bridges) > >talks about exactly what you want and it suggests a solution > >for it without > >passing original FCS transparently. If you think about it, you see the > >situation of passing an Ethernet frames over bunch of bridges > >while keeping > >the integrity of FCS is the same issue as the one discussed > >for EoPW (over > >PtP PW). > > > >Either the scheme that is discussed in Annex F or a derivative > >of it can be > >implemented to satisfy the requirement without passing the client FCS > >transparently. > > > >So instead of the solution to the requirement, it would be good if the > >requirement for this issue be clearly stated in your RFP. > > > >Regards, > >Ali > > > >At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: > > > >>I am new to the 802 standards development effort, so please > >bear with me > >>if I break protocol. > >> > >>I'd like to open up the floodgate on the issue of Customer FCS > >>Retention. I am very interested in what other service > >providers have to > >>say. We have recently beat this to death in PWE3, and we haven't seen > >>any service providers against it. It has been agreed that > >the Ethernet > >>PWE3 draft will be updated to make stripping the Ethernet FCS the > >>default action rather than the mandatory action. > >> > >>Since 802.1ad is specifically for service providers, I think this is a > >>logical place to put this. However, I don't really care > >where it goes, > >>but as a service provider, I can definitively say that it is a > >>requirement. MCI is already requiring dual FCS in RFP > >requirements, and > >>it is preferred although not required that there be a standard behind > >>this at some point in the future. > >> > >>I am a firm believer that this functionality is required to > >make 802.1ad > >>useful to service providers. Service providers require as much > >>transparency as is possible. Keeping the customer FCS allows > >a service > >>provider to validate end-to-end that a packet was not corrupted. > >> > >>As a service provider writing RFP requirements for equipment > >vendors, I > >>can very easily require the FCS to be kept and I can do > >packet captures > >>to validate compliance in a lab setting. Asking an equipment provider > >>to prove that their box is incapable of corrupting packets is a much > >>more daunting task, especially given that service VLANs may be riding > >>across an installed base of switches that may not meet these "packet > >>corruption requirements." Other than the minimal effect of 4 extra > >>bytes, FCS retention affects the endpoints only and not every > >switch in > >>between. > >> > >>As far as isolating the problem, a service providers can do fault > >>isolation using tools like loopbacks once it is know there is > >a problem. > >>If it is not known that the network is broken, there's no > >chance of ever > >>fixing it. If equipment providers have done their jobs > >right, internal > >>corruptions of packets should never leave the equipment. However, if > >>equipment gets into the network that is not performing > >correctly, it is > >>an absolute service provider requirement that it be possible to > >>determine that this unfortunate event has transpired. > >> > >>My recommendation is that stacking a Service FCS along with a Service > >>VLAN tag be an optional feature, with the default behavior > >being not to > >>do so. This will not affect equipment that does not support > >it, but it > >>will allow service providers who are willing to give up 4 bytes the > >>capabilities to build more resilient and transparent networks. I > >>understand that 802.3 would have to sign off on this as well, > >but would > >>like to get agreement in 802.1 first. > >> > >>I'd like to focus on whether or not this should be worked on and not > >>specifically where it should go at this point. > >> > >>I'd like to understand concerns that anyone may have. > >> > >>Thanks, > >> > >>Scott > > > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > --=====================_69715545==_.ALT Content-Type: text/html; charset="us-ascii"
At 02:22 PM 11/11/2003 -0800, Shahram Davari wrote:
Ali,

I think when folks talk about passing the customer FCS transparently, they mean reuse it if it is valid.
This is what 802.1D says:

"If both a) and c) are true, then the FCS carried in the received frame is still valid, and the ideal approach
would be to reuse this value as the FCS for the transmitted frame."

With respect to .1ad, case (d) is the one to consider since either customer tag is changed or provider tag is added. And the Annex recommends a solution without adding additional FCS (4 bytes). Also, once the platform is capable of supporting case (d), it can apply the same method to case (a) and (c).

I think the important requirement is what is stated in the document:

"In each case, it is important to ensure that there is a low probability of additional undetected errors being generated by corruption of the data portion of the frame between removal of the old FCS and computation of the new one, which would result in the transmitted frame carrying invalid data and a valid FCS. Such corruption might occur, for example, as a result of the effect of environmental noise on the operation of the Bridge hardware."

And as mentioned before there are several ways to skin this cat but we need to differentiate between the requirement and its corresponding solution.

-Ali


Yours,
-Shahram

>-----Original Message-----
>From: Ali Sajassi [mailto:sajassi@cisco.com]
>Sent: Tuesday, November 11, 2003 4:50 PM
>To: Scott Kotrla; stds-802-1@ieee.org
>Cc: pwe3@ietf.org; ali Sajassi
>Subject: [PWE3] Re: [802.1] 802.1ad Customer FCS Retention
>
>
>Scott,
>
>I tried to explain the issue and the possible solution in the
>PWE3 mailing
>list; however, since you have brought this discussion to 802.1
>group, it is
>a good place to reference IEEE standards regarding this issue. This
>requirement is nothing new to IEEE and has already been
>captured in 802.1
>standards.
>
>IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC
>bridges)
>talks about exactly what you want and it suggests a solution
>for it without
>passing original FCS transparently. If you think about it, you see the
>situation of passing an Ethernet frames over bunch of bridges
>while keeping
>the integrity of FCS is the same issue as the one discussed
>for EoPW (over
>PtP PW).
>
>Either the scheme that is discussed in Annex F or a derivative
>of it can be
>implemented to satisfy the requirement without passing the client FCS
>transparently.
>
>So instead of the solution to the requirement, it would be good if the
>requirement for this issue be clearly stated in your RFP.
>
>Regards,
>Ali
>
>At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote:
>
>>I am new to the 802 standards development effort, so please
>bear with me
>>if I break protocol.
>>
>>I'd like to open up the floodgate on the issue of Customer FCS
>>Retention.  I am very interested in what other service
>providers have to
>>say.  We have recently beat this to death in PWE3, and we haven't seen
>>any service providers against it.  It has been agreed that
>the Ethernet
>>PWE3 draft will be updated to make stripping the Ethernet FCS the
>>default action rather than the mandatory action.
>>
>>Since 802.1ad is specifically for service providers, I think this is a
>>logical place to put this.  However, I don't really care
>where it goes,
>>but as a service provider, I can definitively say that it is a
>>requirement.  MCI is already requiring dual FCS in RFP
>requirements, and
>>it is preferred although not required that there be a standard behind
>>this at some point in the future.
>>
>>I am a firm believer that this functionality is required to
>make 802.1ad
>>useful to service providers.  Service providers require as much
>>transparency as is possible.  Keeping the customer FCS allows
>a service
>>provider to validate end-to-end that a packet was not corrupted.
>>
>>As a service provider writing RFP requirements for equipment
>vendors, I
>>can very easily require the FCS to be kept and I can do
>packet captures
>>to validate compliance in a lab setting.  Asking an equipment provider
>>to prove that their box is incapable of corrupting packets is a much
>>more daunting task, especially given that service VLANs may be riding
>>across an installed base of switches that may not meet these "packet
>>corruption requirements."  Other than the minimal effect of 4 extra
>>bytes, FCS retention affects the endpoints only and not every
>switch in
>>between.
>>
>>As far as isolating the problem, a service providers can do fault
>>isolation using tools like loopbacks once it is know there is
>a problem.
>>If it is not known that the network is broken, there's no
>chance of ever
>>fixing it.  If equipment providers have done their jobs
>right, internal
>>corruptions of packets should never leave the equipment.  However, if
>>equipment gets into the network that is not performing
>correctly, it is
>>an absolute service provider requirement that it be possible to
>>determine that this unfortunate event has transpired.
>>
>>My recommendation is that stacking a Service FCS along with a Service
>>VLAN tag be an optional feature, with the default behavior
>being not to
>>do so.  This will not affect equipment that does not support
>it, but it
>>will allow service providers who are willing to give up 4 bytes the
>>capabilities to build more resilient and transparent networks.  I
>>understand that 802.3 would have to sign off on this as well,
>but would
>>like to get agreement in 802.1 first.
>>
>>I'd like to focus on whether or not this should be worked on and not
>>specifically where it should go at this point.
>>
>>I'd like to understand concerns that anyone may have.
>>
>>Thanks,
>>
>>Scott
>
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>
--=====================_69715545==_.ALT-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt Date: Tue, 11 Nov 2003 18:00:39 -0500 Lines: 145 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 00:03:02 2003 Return-path: To: "'Sasha Vainshtein'" , "Yaakov Stein (E-mail)" X-Mailer: Internet Mail Service (5.5.2656.59) 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: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Tuesday, November 11, 2003 3:02 PM > To: Yaakov Stein (E-mail) > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) > Subject: [PWE3] CE-to-CE PWs, Hierarchical VPLS and > Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt > > > Yaakov and all, > I'd like to present the technical problem I have with the > current text of draft-stein-pwe3-pwce2e-00.txt and options > for solving this problem. > > My problem is with the following para in Section 3: > > > The ideal way of handling a PWCE2E packet is to > have the CE perform the service specific encapsulation > and to prepend the (inner) PW label, but no (outer) MPLS > transport labels. The PE, which participates in the provider > network signaling, then adds the appropriate MPLS labels > as required. > > > IMO, it is easy to see why this will not work as written. > > Please consider the following use case: > > 1. There are three CEs (CE-1, CE-2 and CE-3) attached > to 3 PEs (PE-1, PE-2 and PE3 respectively). > 2. In each case the link between CE-i and PE-i is a > "single-hop" link (i.e., there are no LSRs in the > path, but there may be L2 switches - Ethernet, FR/ATM etc). > 3. You want to run two PWs: > a) PW-12 runs between CE-1 and CE-2 > b)PW-13 runs between CE-1 and CE-3. > > How can PE-1 (which both these PWs have to cross on their ways > to their peer CEs) know which transport labels to add to packets > received from CE-1? > > This decision CANNOT be based on the PW labels in these packets, > because these labels are independently allocated by CE-2 and CE-3 > respectively, so that nothing prevents them from being equal > (accidentally or else). > And inspection of the encapsulated data will not help either. > > (BTW, this is exactly the difference between MPLS and, say, > FR or ATM: in the latter cases, DLCI or VCI/VPI values are > unique on the attachment link and known to the PE, > in the former case they are not.) > > How can this be fixed? > > I see three ways to do so. > > 1. Limit this case to one PW per CE. IMO, this is > a very problematic limitation (one could say, that > it is ultimately non-scalable!) and does not > justify any action wrt the existing documents. > > 2. Allow the CE to push both the PW and transport labels > on top of the payload and PWE3 control info. > This would make it equivalent to the "normal" PW,and no > technical changes in the architecture doc are required. > The transport label can be obtained in many different ways, > including usage of the MPLS UNI (as suggested by David > Sinicrope). > > 3. Use PW stitching. This would introduce a new element > in the PWE3 architecture - the Pseudo-Wire > Stitching Function (PSF) - located in the PEs. > The PSF would operate like following: > a) Terminate a "usual" PW running between two PEs > adjacent to the CEs in question. > Note that the PEs must exchange their incoming > PW labels for this PW just as in the "normal" case > b) Terminate the "spoke" PW between the CE and its adjacent PE. > This PW would not require transport labels because the CE<-->PE > transport LSPs are just one hop, and PHP can be applied > to them. > The PW labels for the spoke PWs would be exchanged > between the CE and > its adjacent PE in the usual way. > c) Stitch the spoke PW with the PE-PE PW. Such a stitching would: > * Leave the PW packet payload and control info (if any) intact > * Swap the inner label > * In one direction (CE-->PE), push the transport > label(s) required for the PE-PE PW. > Opposite to the PW IWFs, one and only one PSF type is required. > The resulting architecture resembles the Hierarchical VPLS > defined in > draft-ietf-l2vln-vpls-ldp-01.txt (hence the term "Spoke PW"). Its > advantage > stems from moving the service-specific IWF functionality > towards the CE > (and hence > may be of special importance for TDM PWs), while possibility of > misconfiguration > (e.g., connection of IWFs with different service types) should be > considered > as a disadvantage. Another disadvantage, of course, is > introduction of a > new > (albeit simple) architectural element in the high-speed data plane. > > IMO, any technical changes in the architecture document > should be considered > only if we reach a conclusion that advantages of the PW > stitching option > outweigh its disadvantages. Sasha, I believe that option 3 is identical to the Distributed VPLS model described in section 5.5 of draft-ietf-l2vpn-signaling-00.txt. IMO, CE-CE PWs is just one example of situations that require multi-hop PWs. draft-ietf-l2vpn-signaling-00.txt talks about splicing PWs. You talk about stitching PWs. In both cases the solution sounds kludgy, to say the least. However, if you look at these multi-hop PWs as regular LSPs established along a multi-hop path, everything is pretty much straightforward. Setup of such multi-hop LSPs would require a protocol like CR-LDP or RSVP. RSVP is in my view the preferred solution, but CR-LDP would be closer to the current control draft. In any case, as I said in another email, I would prefer it if we would solve the multi-hop issue before progressing the control draft. The response to that email was that it is not clear that people are interested in the multi-hop solution. I would argue that Yaakov's contribution shows that there is interest. Peter > > Hope these notes would be helpful. > -------------------------------------------------------------- > -------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) > > _______________________________________________ > 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: Ali Sajassi Subject: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 15:14:55 -0800 Lines: 170 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031111133156.0265e600@airborne.cisco.com> <000001c3a8a3$22b61600$2d8f32a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 12 00:16:02 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Scott Kotrla , "'Ali Sajassi'" , stds-802-1@ieee.org In-Reply-To: <000001c3a8a3$22b61600$2d8f32a6@acer4wc5zk5t43> References: <4.3.2.7.2.20031111133156.0265e600@airborne.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 03:28 PM 11/11/2003 -0700, Scott Kotrla wrote: >As a service provider, my two issues with this approach are as follows: > >1. Every box end-to-end has to do this. Some of the boxes in the middle >may already be deployed and may not support this functionality. My >assumption is that the extra FCS could be added in such a way that >intermediate switches wouldn't have to know about it or act on it. The intermediate boxes need to have such capabilities because: a) If they don't detect, then they basically violate the basic requirement of "keeping the integrity of FCS" b) If they introduce an error and they cannot detect it and the end-point detects it, then how do you know where the error occurred and how do you trouble shoot c) If they detect the error, then what is the point of passing the frame to the end-point and waste BW >2. I have no way of proving one way or the other whether equipment >complies. If I add an FCS I can very easily validate whether or not a >vendor complies. But how do you trouble shoot to find out which box generated the error !! The important thing is to indicate the requirement and the vendors need to meet that requirement. For example, there is a requirement for availability and reliability of the box and a vendor needs to meet that. > Neither solution is implemented today, so an FCS seems >a lot simpler way to do things. Providers build scalable networks by >adding layers. But derivative of them have been implemented to ensure detection of error that may be introduced inside the platform. >While this has been addressed previously in 802.1, it has been discussed >in regards to enterprise applications and not provider applications. >Providers have different requirements than enterprises do, namely in the >requirement to add layers and separation. MAC-in-MAC would meet my >needs, but I'd rather not go that route since it adds overhead, and I >wouldn't be using the extra MAC address overhead. Service providers are >not looking to turn Ethernet completely into SONET. However, we are >looking to port the small amount of SONET functionality that is >regularly implemented into Ethernet so that carrier class Ethernet >implementations are possible. Line and Path level error checking are a >key part of these requirements. > >I believe it was agreed in PWE3 that this functionality should be >supported for those carriers who want to implement it. I would agree >that the 802.1ad and PWE3 applications are very similar and would >encourage the same agreement to be reached. I'm not asking for >mandatory FCS retention. I am asking for optional FCS retention. I made my comments that I felt would help in clarification of this issue. From this point onward, I will pass the table to whoever else wants to comment. Regards, Ali >Thanks, > >Scott > >-----Original Message----- >From: owner-stds-802-1@majordomo.ieee.org >[mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Ali Sajassi >Sent: Tuesday, November 11, 2003 2:50 PM >To: Scott Kotrla; stds-802-1@ieee.org >Cc: pwe3@ietf.org; ali Sajassi >Subject: Re: [802.1] 802.1ad Customer FCS Retention > > >Scott, > >I tried to explain the issue and the possible solution in the PWE3 >mailing >list; however, since you have brought this discussion to 802.1 group, it >is >a good place to reference IEEE standards regarding this issue. This >requirement is nothing new to IEEE and has already been captured in >802.1 >standards. > >IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC bridges) >talks about exactly what you want and it suggests a solution for it >without >passing original FCS transparently. If you think about it, you see the >situation of passing an Ethernet frames over bunch of bridges while >keeping >the integrity of FCS is the same issue as the one discussed for EoPW >(over >PtP PW). > >Either the scheme that is discussed in Annex F or a derivative of it can >be >implemented to satisfy the requirement without passing the client FCS >transparently. > >So instead of the solution to the requirement, it would be good if the >requirement for this issue be clearly stated in your RFP. > >Regards, >Ali > >At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: > > >I am new to the 802 standards development effort, so please bear with >me > >if I break protocol. > > > >I'd like to open up the floodgate on the issue of Customer FCS > >Retention. I am very interested in what other service providers have >to > >say. We have recently beat this to death in PWE3, and we haven't seen > >any service providers against it. It has been agreed that the Ethernet > >PWE3 draft will be updated to make stripping the Ethernet FCS the > >default action rather than the mandatory action. > > > >Since 802.1ad is specifically for service providers, I think this is a > >logical place to put this. However, I don't really care where it goes, > >but as a service provider, I can definitively say that it is a > >requirement. MCI is already requiring dual FCS in RFP requirements, >and > >it is preferred although not required that there be a standard behind > >this at some point in the future. > > > >I am a firm believer that this functionality is required to make >802.1ad > >useful to service providers. Service providers require as much > >transparency as is possible. Keeping the customer FCS allows a service > >provider to validate end-to-end that a packet was not corrupted. > > > >As a service provider writing RFP requirements for equipment vendors, I > >can very easily require the FCS to be kept and I can do packet captures > >to validate compliance in a lab setting. Asking an equipment provider > >to prove that their box is incapable of corrupting packets is a much > >more daunting task, especially given that service VLANs may be riding > >across an installed base of switches that may not meet these "packet > >corruption requirements." Other than the minimal effect of 4 extra > >bytes, FCS retention affects the endpoints only and not every switch in > >between. > > > >As far as isolating the problem, a service providers can do fault > >isolation using tools like loopbacks once it is know there is a >problem. > >If it is not known that the network is broken, there's no chance of >ever > >fixing it. If equipment providers have done their jobs right, internal > >corruptions of packets should never leave the equipment. However, if > >equipment gets into the network that is not performing correctly, it is > >an absolute service provider requirement that it be possible to > >determine that this unfortunate event has transpired. > > > >My recommendation is that stacking a Service FCS along with a Service > >VLAN tag be an optional feature, with the default behavior being not to > >do so. This will not affect equipment that does not support it, but it > >will allow service providers who are willing to give up 4 bytes the > >capabilities to build more resilient and transparent networks. I > >understand that 802.3 would have to sign off on this as well, but would > >like to get agreement in 802.1 first. > > > >I'd like to focus on whether or not this should be worked on and not > >specifically where it should go at this point. > > > >I'd like to understand concerns that anyone may have. > > > >Thanks, > > > >Scott From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 01:56:46 +0200 Lines: 207 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" , "Yaakov Stein (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 01:00:07 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" 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 Peter, Thank you for a prompt response. I'll check your reference to hierarchical VPLS in draft-ietf-l2vpn-signaling-00.txt However, I do not think that Option 3 is really identical to hierarchical VPLS because the PSF is service-agnostic and does not look at any part of the native frame. I would say it sounds like a hierarchical VPWS. I would appreciate references to multi-hop LSPs if you can provide them. Wrt interest - or lack thereof - based on Yaakov's draft, the crucial question, IMO, is: what justifies support of Option 3 when Option 2 does the same job as well? Saving one label stack entry on the CE-PE packet clearly does not. And, from little I know about MPLS UNI (David is the expert here), it allows you to obtain a valid transport label without the need to learn the core topology. It is also a clear-cut control plane solution, without the need for a new function (PSF) in the high-speed data plane. Please note that I do not reject Option 3 out of hand. I simply try to understand its advantages (and disadvantages:-). At the same time I feel pretty sure that Option 1 is a dead-end. ---------------------------------------------------------------------------- -------- 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: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Wednesday, November 12, 2003 1:01 AM > To: Sasha Vainshtein; Yaakov Stein (E-mail) > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); > PWE3 WG (E-mail); David Sinicrope (E-mail) > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and Pseudowire > Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Tuesday, November 11, 2003 3:02 PM > > To: Yaakov Stein (E-mail) > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) > > Subject: [PWE3] CE-to-CE PWs, Hierarchical VPLS and > > Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > Yaakov and all, > > I'd like to present the technical problem I have with the > > current text of draft-stein-pwe3-pwce2e-00.txt and options > > for solving this problem. > > > > My problem is with the following para in Section 3: > > > > > > The ideal way of handling a PWCE2E packet is to > > have the CE perform the service specific encapsulation > > and to prepend the (inner) PW label, but no (outer) MPLS > > transport labels. The PE, which participates in the provider > > network signaling, then adds the appropriate MPLS labels > > as required. > > > > > > IMO, it is easy to see why this will not work as written. > > > > Please consider the following use case: > > > > 1. There are three CEs (CE-1, CE-2 and CE-3) attached > > to 3 PEs (PE-1, PE-2 and PE3 respectively). > > 2. In each case the link between CE-i and PE-i is a > > "single-hop" link (i.e., there are no LSRs in the > > path, but there may be L2 switches - Ethernet, FR/ATM etc). > > 3. You want to run two PWs: > > a) PW-12 runs between CE-1 and CE-2 > > b)PW-13 runs between CE-1 and CE-3. > > > > How can PE-1 (which both these PWs have to cross on their ways > > to their peer CEs) know which transport labels to add to packets > > received from CE-1? > > > > This decision CANNOT be based on the PW labels in these packets, > > because these labels are independently allocated by CE-2 and CE-3 > > respectively, so that nothing prevents them from being equal > > (accidentally or else). > > And inspection of the encapsulated data will not help either. > > > > (BTW, this is exactly the difference between MPLS and, say, > > FR or ATM: in the latter cases, DLCI or VCI/VPI values are > > unique on the attachment link and known to the PE, > > in the former case they are not.) > > > > How can this be fixed? > > > > I see three ways to do so. > > > > 1. Limit this case to one PW per CE. IMO, this is > > a very problematic limitation (one could say, that > > it is ultimately non-scalable!) and does not > > justify any action wrt the existing documents. > > > > 2. Allow the CE to push both the PW and transport labels > > on top of the payload and PWE3 control info. > > This would make it equivalent to the "normal" PW,and no > > technical changes in the architecture doc are required. > > The transport label can be obtained in many different ways, > > including usage of the MPLS UNI (as suggested by David > > Sinicrope). > > > > 3. Use PW stitching. This would introduce a new element > > in the PWE3 architecture - the Pseudo-Wire > > Stitching Function (PSF) - located in the PEs. > > The PSF would operate like following: > > a) Terminate a "usual" PW running between two PEs > > adjacent to the CEs in question. > > Note that the PEs must exchange their incoming > > PW labels for this PW just as in the "normal" case > > b) Terminate the "spoke" PW between the CE and its adjacent PE. > > This PW would not require transport labels because > the CE<-->PE > > transport LSPs are just one hop, and PHP can be applied > > to them. > > The PW labels for the spoke PWs would be exchanged > > between the CE and > > its adjacent PE in the usual way. > > c) Stitch the spoke PW with the PE-PE PW. Such a stitching would: > > * Leave the PW packet payload and control info (if any) intact > > * Swap the inner label > > * In one direction (CE-->PE), push the transport > > label(s) required for the PE-PE PW. > > Opposite to the PW IWFs, one and only one PSF type is required. > > The resulting architecture resembles the Hierarchical VPLS > > defined in > > draft-ietf-l2vln-vpls-ldp-01.txt (hence the term "Spoke PW"). Its > > advantage > > stems from moving the service-specific IWF functionality > > towards the CE > > (and hence > > may be of special importance for TDM PWs), while possibility of > > misconfiguration > > (e.g., connection of IWFs with different service types) should be > > considered > > as a disadvantage. Another disadvantage, of course, is > > introduction of a > > new > > (albeit simple) architectural element in the high-speed > data plane. > > > > IMO, any technical changes in the architecture document > > should be considered > > only if we reach a conclusion that advantages of the PW > > stitching option > > outweigh its disadvantages. > > Sasha, > > I believe that option 3 is identical to the Distributed VPLS > model described in section 5.5 of draft-ietf-l2vpn-signaling-00.txt. > > IMO, CE-CE PWs is just one example of situations that require > multi-hop PWs. > > draft-ietf-l2vpn-signaling-00.txt talks about splicing PWs. > You talk about stitching PWs. In both cases the solution > sounds kludgy, to say the least. However, if you look at > these multi-hop PWs as regular LSPs established along a > multi-hop path, everything is pretty much straightforward. > Setup of such multi-hop LSPs would require a protocol like > CR-LDP or RSVP. RSVP is in my view the preferred solution, > but CR-LDP would be closer to the current control draft. > > In any case, as I said in another email, I would prefer it if > we would solve the multi-hop issue before progressing the > control draft. The response to that email was that it is not > clear that people are interested in the multi-hop solution. I > would argue that Yaakov's contribution shows that there is interest. > > Peter > > > > > Hope these notes would be helpful. > > -------------------------------------------------------------- > > -------------- > > -------- > > With best regards, > > Sasha Vainshtein > > email: sasha@axerra.com > > phone: +972-3-7659993 (office) > > +972-8-9254948 (home) > > +972-58-674833 (cellular) > > > > _______________________________________________ > > 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 Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 16:45:09 -0700 Lines: 287 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031111145717.0267e9c0@airborne.cisco.com> 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 Wed Nov 12 01:01:33 2003 Return-path: In-reply-to: <4.3.2.7.2.20031111145717.0267e9c0@airborne.cisco.com> To: "'Ali Sajassi'" , stds-802-1@ieee.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Let me make a small clarification. "My assumption is that the extra FCS could be added in such a way that intermediate switches wouldn't have to know about or act upon the original path FCS, since it would become part of the payload." To fully understand what would happen, I'd have to understand what happens per the 802 standards today. Does 802.1 requires that the FCS be: 1. Checked on ingress and carried across a device with recomputation at egress if needed. 2. Checked on ingress, thrown away, with new computation at egress every time. For the first case, the customer FCS would be checked at Provider Edge ingress, and a new service FCS would be added. All intermediate interfaces would treat the service FCS just like it has traditionally treated the single FCS. The Provider Edge egress would toss the service FCS (without checking it since it was checked on ingress into the last piece of equipment) and check the customer FCS before sending the original packet to the customer. For the second case, the customer FCS would be checked at the Provider Edge ingress and passed through the device. The egress of this device would add a service FCS in the same way that in intermediate interface would normally add a single layer FCS. All intermediate interfaces would treat the service FCS just like it has traditionally treated the single FCS. The ingress of the last piece of equipment would discard the service FCS after checking it. The Provider Edge egress would check the customer FCS before sending the original packet to the customer and it would not calculate a new FCS as would normally be done on a traditional interface. Intermediate switches could look at both the path and the line level FCS, but that requires even more functionality in the standard than I am currently asking for and it obliviates existing devices in the middle. If a device supports this functionality, then it should definitely not pass the frame. As far as not knowing which box generated the error, I covered this in my initial email: > >As far as isolating the problem, a service providers can do fault > >isolation using tools like loopbacks once it is know there is a >problem. > >If it is not known that the network is broken, there's no chance of >ever > >fixing it. If equipment providers have done their jobs right, internal > >corruptions of packets should never leave the equipment. However, if > >equipment gets into the network that is not performing correctly, it is > >an absolute service provider requirement that it be possible to > >determine that this unfortunate event has transpired. If I know there is a problem I the network, then I can troubleshoot and solve the problem. If I don't know there is an error, how would I ever know to even try to troubleshoot? It could take days or even weeks to determine that there is a problem that I need to troubleshoot. This is not acceptable to service providers who would use Ethernet as transport infrastructure. I am still in favor of requiring that devices in the middle of the network not corrupt packets. But this a requirement that is next to impossible to check coherence to until the device has failed in such a way and wreaked havoc on the network. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Ali Sajassi Sent: Tuesday, November 11, 2003 4:15 PM To: Scott Kotrla; 'Ali Sajassi'; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention At 03:28 PM 11/11/2003 -0700, Scott Kotrla wrote: >As a service provider, my two issues with this approach are as follows: > >1. Every box end-to-end has to do this. Some of the boxes in the middle >may already be deployed and may not support this functionality. My >assumption is that the extra FCS could be added in such a way that >intermediate switches wouldn't have to know about it or act on it. The intermediate boxes need to have such capabilities because: a) If they don't detect, then they basically violate the basic requirement of "keeping the integrity of FCS" b) If they introduce an error and they cannot detect it and the end-point detects it, then how do you know where the error occurred and how do you trouble shoot c) If they detect the error, then what is the point of passing the frame to the end-point and waste BW >2. I have no way of proving one way or the other whether equipment >complies. If I add an FCS I can very easily validate whether or not a >vendor complies. But how do you trouble shoot to find out which box generated the error !! The important thing is to indicate the requirement and the vendors need to meet that requirement. For example, there is a requirement for availability and reliability of the box and a vendor needs to meet that. > Neither solution is implemented today, so an FCS seems >a lot simpler way to do things. Providers build scalable networks by >adding layers. But derivative of them have been implemented to ensure detection of error that may be introduced inside the platform. >While this has been addressed previously in 802.1, it has been discussed >in regards to enterprise applications and not provider applications. >Providers have different requirements than enterprises do, namely in the >requirement to add layers and separation. MAC-in-MAC would meet my >needs, but I'd rather not go that route since it adds overhead, and I >wouldn't be using the extra MAC address overhead. Service providers are >not looking to turn Ethernet completely into SONET. However, we are >looking to port the small amount of SONET functionality that is >regularly implemented into Ethernet so that carrier class Ethernet >implementations are possible. Line and Path level error checking are a >key part of these requirements. > >I believe it was agreed in PWE3 that this functionality should be >supported for those carriers who want to implement it. I would agree >that the 802.1ad and PWE3 applications are very similar and would >encourage the same agreement to be reached. I'm not asking for >mandatory FCS retention. I am asking for optional FCS retention. I made my comments that I felt would help in clarification of this issue. From this point onward, I will pass the table to whoever else wants to comment. Regards, Ali >Thanks, > >Scott > >-----Original Message----- >From: owner-stds-802-1@majordomo.ieee.org >[mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Ali Sajassi >Sent: Tuesday, November 11, 2003 2:50 PM >To: Scott Kotrla; stds-802-1@ieee.org >Cc: pwe3@ietf.org; ali Sajassi >Subject: Re: [802.1] 802.1ad Customer FCS Retention > > >Scott, > >I tried to explain the issue and the possible solution in the PWE3 >mailing >list; however, since you have brought this discussion to 802.1 group, it >is >a good place to reference IEEE standards regarding this issue. This >requirement is nothing new to IEEE and has already been captured in >802.1 >standards. > >IEEE 802.1D/D3 Annex F (Preserving the integrity of FCS in MAC bridges) >talks about exactly what you want and it suggests a solution for it >without >passing original FCS transparently. If you think about it, you see the >situation of passing an Ethernet frames over bunch of bridges while >keeping >the integrity of FCS is the same issue as the one discussed for EoPW >(over >PtP PW). > >Either the scheme that is discussed in Annex F or a derivative of it can >be >implemented to satisfy the requirement without passing the client FCS >transparently. > >So instead of the solution to the requirement, it would be good if the >requirement for this issue be clearly stated in your RFP. > >Regards, >Ali > >At 11:57 AM 11/11/2003 -0700, Scott Kotrla wrote: > > >I am new to the 802 standards development effort, so please bear with >me > >if I break protocol. > > > >I'd like to open up the floodgate on the issue of Customer FCS > >Retention. I am very interested in what other service providers have >to > >say. We have recently beat this to death in PWE3, and we haven't seen > >any service providers against it. It has been agreed that the Ethernet > >PWE3 draft will be updated to make stripping the Ethernet FCS the > >default action rather than the mandatory action. > > > >Since 802.1ad is specifically for service providers, I think this is a > >logical place to put this. However, I don't really care where it goes, > >but as a service provider, I can definitively say that it is a > >requirement. MCI is already requiring dual FCS in RFP requirements, >and > >it is preferred although not required that there be a standard behind > >this at some point in the future. > > > >I am a firm believer that this functionality is required to make >802.1ad > >useful to service providers. Service providers require as much > >transparency as is possible. Keeping the customer FCS allows a service > >provider to validate end-to-end that a packet was not corrupted. > > > >As a service provider writing RFP requirements for equipment vendors, I > >can very easily require the FCS to be kept and I can do packet captures > >to validate compliance in a lab setting. Asking an equipment provider > >to prove that their box is incapable of corrupting packets is a much > >more daunting task, especially given that service VLANs may be riding > >across an installed base of switches that may not meet these "packet > >corruption requirements." Other than the minimal effect of 4 extra > >bytes, FCS retention affects the endpoints only and not every switch in > >between. > > > >As far as isolating the problem, a service providers can do fault > >isolation using tools like loopbacks once it is know there is a >problem. > >If it is not known that the network is broken, there's no chance of >ever > >fixing it. If equipment providers have done their jobs right, internal > >corruptions of packets should never leave the equipment. However, if > >equipment gets into the network that is not performing correctly, it is > >an absolute service provider requirement that it be possible to > >determine that this unfortunate event has transpired. > > > >My recommendation is that stacking a Service FCS along with a Service > >VLAN tag be an optional feature, with the default behavior being not to > >do so. This will not affect equipment that does not support it, but it > >will allow service providers who are willing to give up 4 bytes the > >capabilities to build more resilient and transparent networks. I > >understand that 802.3 would have to sign off on this as well, but would > >like to get agreement in 802.1 first. > > > >I'd like to focus on whether or not this should be worked on and not > >specifically where it should go at this point. > > > >I'd like to understand concerns that anyone may have. > > > >Thanks, > > > >Scott _______________________________________________ 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: Mark Seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 11 Nov 2003 16:03:52 -0800 (PST) Lines: 44 Sender: pwe3-admin@ietf.org References: <4.3.2.7.2.20031111145717.0267e9c0@airborne.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1183019875-1068595432=:21700" Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 12 01:05:05 2003 Return-path: To: Ali Sajassi , Scott Kotrla , stds-802-1@ieee.org In-Reply-To: <4.3.2.7.2.20031111145717.0267e9c0@airborne.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 --0-1183019875-1068595432=:21700 Content-Type: text/plain; charset=us-ascii Hi Ali, Ali Sajassi wrote: a) If they don't detect, then they basically violate the basic requirement of "keeping the integrity of FCS" Ultimately, the issue may not be the integrity of FCS but the integrity of the payload. If the payload and a FCS become separated, and the payload gets corrupted before/while a new FCS is being generated, what has protected the integrity of the payload. Serious concern for people doing financial transactions as an example. While I personally believe networks should be build so the layer that creates the PDU does the end-to-end check (so that service providers can do interworking for example without worrying about essentially the same issue and remembering that Ethernet is in some people's minds a link layer), it might be that service providers do not have control over their subscribers, and it might be that technologies built historically relying on link layer checks are at risk; and I suppose it could be argued that a PW is a virtual link layer - though I think that is debatable. So while I personally believe that we should not try to solve a PWE integrity problem (perceived or otherwise) by making use of an Ethernet FCS, if there is an integrity of the payload problem, that might be a different issue. >> b) If they introduce an error and they cannot detect it and the end-point detects it, then how do you know where the error occurred and how do you trouble shoot << Historically, service providers have used sectionalized (section, path, segment, end-to-end, near end, far end,.....) OAM mechanisms within the transport layer to achieve ongoing measurements, and theoretically recorded for retroactive inspection, to achieve such insights (not wishing to ignite another round of OAM discussions , just an observation). --0-1183019875-1068595432=:21700 Content-Type: text/html; charset=us-ascii
Hi Ali,
 
Ali Sajassi <sajassi@cisco.com> wrote:

<snip>
a) If they don't detect, then they basically violate the basic requirement
of "keeping the integrity of FCS"

 
Ultimately, the issue may not be the integrity of FCS but the integrity of the payload. If the payload and a FCS become separated, and the payload gets corrupted before/while a new FCS is being generated, what has protected the integrity of the payload. Serious concern for people doing financial transactions as an example.
 
While I personally believe networks should be build so the layer that creates the PDU does the end-to-end check (so that service providers can do interworking for example without worrying about essentially the same issue and remembering that Ethernet is in some people's minds a link layer), it might be that service providers do not have control over their subscribers, and it might be that technologies built historically relying on link layer checks are at risk; and I suppose it could be argued that a PW is a virtual link layer - though I think that is debatable.
 
So while I personally believe that we should not try to solve a PWE integrity problem (perceived or otherwise) by making use of an Ethernet FCS, if there is an integrity of the payload problem, that might be a different issue.
 
>> <snip> b) If they introduce an error and they cannot detect it and the end-point detects it, then how do you know where the error occurred and how do you trouble shoot <<
 
Historically, service providers have used sectionalized (section, path, segment, end-to-end, near end, far end,.....) OAM mechanisms within the transport layer to achieve ongoing measurements, and theoretically recorded for retroactive inspection, to achieve such insights (not wishing to ignite another round of OAM discussions , just an observation).
 
--0-1183019875-1068595432=:21700-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt Date: Tue, 11 Nov 2003 19:18:35 -0500 Lines: 237 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" , "Yaakov Stein (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 01:20:07 2003 Return-path: To: "'Sasha Vainshtein'" X-Mailer: Internet Mail Service (5.5.2656.59) 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: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > Sent: Tuesday, November 11, 2003 5:57 PM > To: 'Busschbach, Peter B (Peter)' > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail); Yaakov > Stein (E-mail) > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and > Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > > > Peter, > Thank you for a prompt response. > > I'll check your reference to hierarchical VPLS in > draft-ietf-l2vpn-signaling-00.txt > However, I do not think that Option 3 is really identical to > hierarchical VPLS because the PSF is service-agnostic > and does not look at any part of the native frame. > I would say it sounds like a hierarchical VPWS. My interpretation of HVPLS is that the N-PE (what you call PSF) performs a bridging function (i.e. a service-specific function), where as in DVPLS the N-PE merely splices PWs in a service-agnostic way. > > I would appreciate references to multi-hop LSPs if you can > provide them. RFC 3031, RFC 3209 and RFC 3212 :-) A multi-hop PW is essentially an regular LSP. You may need to extend existing specs to deal with FECs that may contain non-routable information, perhaps along the lines of Ina Minei's draft that we discussed this morning. Apart from that, I don't see anything special. > > Wrt interest - or lack thereof - based on Yaakov's draft, the crucial > question, IMO, is: what justifies support of Option 3 when Option 2 > does the same job as well? Saving one label stack entry on the CE-PE > packet clearly does not. And, from little I know about MPLS UNI > (David is the expert here), it allows you to obtain a valid transport > label without the need to learn the core topology. It is also > a clear-cut > control plane solution, without the need for a new function > (PSF) in the > high-speed data plane. > > Please note that I do not reject Option 3 out of hand. I simply try to > understand its advantages (and disadvantages:-). > > At the same time I feel pretty sure that Option 1 is a dead-end. > > -------------------------------------------------------------- > -------------- > -------- > 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: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Wednesday, November 12, 2003 1:01 AM > > To: Sasha Vainshtein; Yaakov Stein (E-mail) > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); > > PWE3 WG (E-mail); David Sinicrope (E-mail) > > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and Pseudowire > > Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > > > > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > Sent: Tuesday, November 11, 2003 3:02 PM > > > To: Yaakov Stein (E-mail) > > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > > > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) > > > Subject: [PWE3] CE-to-CE PWs, Hierarchical VPLS and > > > Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > > > > Yaakov and all, > > > I'd like to present the technical problem I have with the > > > current text of draft-stein-pwe3-pwce2e-00.txt and options > > > for solving this problem. > > > > > > My problem is with the following para in Section 3: > > > > > > > > > The ideal way of handling a PWCE2E packet is to > > > have the CE perform the service specific encapsulation > > > and to prepend the (inner) PW label, but no (outer) MPLS > > > transport labels. The PE, which participates in the provider > > > network signaling, then adds the appropriate MPLS labels > > > as required. > > > > > > > > > IMO, it is easy to see why this will not work as written. > > > > > > Please consider the following use case: > > > > > > 1. There are three CEs (CE-1, CE-2 and CE-3) attached > > > to 3 PEs (PE-1, PE-2 and PE3 respectively). > > > 2. In each case the link between CE-i and PE-i is a > > > "single-hop" link (i.e., there are no LSRs in the > > > path, but there may be L2 switches - Ethernet, FR/ATM etc). > > > 3. You want to run two PWs: > > > a) PW-12 runs between CE-1 and CE-2 > > > b)PW-13 runs between CE-1 and CE-3. > > > > > > How can PE-1 (which both these PWs have to cross on their ways > > > to their peer CEs) know which transport labels to add to packets > > > received from CE-1? > > > > > > This decision CANNOT be based on the PW labels in these packets, > > > because these labels are independently allocated by CE-2 and CE-3 > > > respectively, so that nothing prevents them from being equal > > > (accidentally or else). > > > And inspection of the encapsulated data will not help either. > > > > > > (BTW, this is exactly the difference between MPLS and, say, > > > FR or ATM: in the latter cases, DLCI or VCI/VPI values are > > > unique on the attachment link and known to the PE, > > > in the former case they are not.) > > > > > > How can this be fixed? > > > > > > I see three ways to do so. > > > > > > 1. Limit this case to one PW per CE. IMO, this is > > > a very problematic limitation (one could say, that > > > it is ultimately non-scalable!) and does not > > > justify any action wrt the existing documents. > > > > > > 2. Allow the CE to push both the PW and transport labels > > > on top of the payload and PWE3 control info. > > > This would make it equivalent to the "normal" PW,and no > > > technical changes in the architecture doc are required. > > > The transport label can be obtained in many different ways, > > > including usage of the MPLS UNI (as suggested by David > > > Sinicrope). > > > > > > 3. Use PW stitching. This would introduce a new element > > > in the PWE3 architecture - the Pseudo-Wire > > > Stitching Function (PSF) - located in the PEs. > > > The PSF would operate like following: > > > a) Terminate a "usual" PW running between two PEs > > > adjacent to the CEs in question. > > > Note that the PEs must exchange their incoming > > > PW labels for this PW just as in the "normal" case > > > b) Terminate the "spoke" PW between the CE and its adjacent PE. > > > This PW would not require transport labels because > > the CE<-->PE > > > transport LSPs are just one hop, and PHP can be applied > > > to them. > > > The PW labels for the spoke PWs would be exchanged > > > between the CE and > > > its adjacent PE in the usual way. > > > c) Stitch the spoke PW with the PE-PE PW. Such a > stitching would: > > > * Leave the PW packet payload and control info (if > any) intact > > > * Swap the inner label > > > * In one direction (CE-->PE), push the transport > > > label(s) required for the PE-PE PW. > > > Opposite to the PW IWFs, one and only one PSF type is required. > > > The resulting architecture resembles the Hierarchical VPLS > > > defined in > > > draft-ietf-l2vln-vpls-ldp-01.txt (hence the term > "Spoke PW"). Its > > > advantage > > > stems from moving the service-specific IWF functionality > > > towards the CE > > > (and hence > > > may be of special importance for TDM PWs), while possibility of > > > misconfiguration > > > (e.g., connection of IWFs with different service > types) should be > > > considered > > > as a disadvantage. Another disadvantage, of course, is > > > introduction of a > > > new > > > (albeit simple) architectural element in the high-speed > > data plane. > > > > > > IMO, any technical changes in the architecture document > > > should be considered > > > only if we reach a conclusion that advantages of the PW > > > stitching option > > > outweigh its disadvantages. > > > > Sasha, > > > > I believe that option 3 is identical to the Distributed VPLS > > model described in section 5.5 of draft-ietf-l2vpn-signaling-00.txt. > > > > IMO, CE-CE PWs is just one example of situations that require > > multi-hop PWs. > > > > draft-ietf-l2vpn-signaling-00.txt talks about splicing PWs. > > You talk about stitching PWs. In both cases the solution > > sounds kludgy, to say the least. However, if you look at > > these multi-hop PWs as regular LSPs established along a > > multi-hop path, everything is pretty much straightforward. > > Setup of such multi-hop LSPs would require a protocol like > > CR-LDP or RSVP. RSVP is in my view the preferred solution, > > but CR-LDP would be closer to the current control draft. > > > > In any case, as I said in another email, I would prefer it if > > we would solve the multi-hop issue before progressing the > > control draft. The response to that email was that it is not > > clear that people are interested in the multi-hop solution. I > > would argue that Yaakov's contribution shows that there is interest. > > > > Peter > > > > > > > > Hope these notes would be helpful. > > > -------------------------------------------------------------- > > > -------------- > > > -------- > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > phone: +972-3-7659993 (office) > > > +972-8-9254948 (home) > > > +972-58-674833 (cellular) > > > > > > _______________________________________________ > > > 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: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 03:14:01 +0200 Lines: 284 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" , "Yaakov Stein (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 02:16:11 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" 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 Peterm, Sorry I have mixed HVPLS and DVPLS. I'll check the references (as I have said) and respond accordingly. ---------------------------------------------------------------------------- -------- 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: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > Sent: Wednesday, November 12, 2003 2:19 AM > To: Sasha Vainshtein > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); > PWE3 WG (E-mail); David Sinicrope (E-mail); Yaakov Stein (E-mail) > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and Pseudowire > Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > -----Original Message----- > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > Sent: Tuesday, November 11, 2003 5:57 PM > > To: 'Busschbach, Peter B (Peter)' > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail); Yaakov > > Stein (E-mail) > > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and > > Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > Peter, > > Thank you for a prompt response. > > > > I'll check your reference to hierarchical VPLS in > > draft-ietf-l2vpn-signaling-00.txt > > However, I do not think that Option 3 is really identical to > > hierarchical VPLS because the PSF is service-agnostic > > and does not look at any part of the native frame. > > I would say it sounds like a hierarchical VPWS. > > My interpretation of HVPLS is that the N-PE (what you call > PSF) performs a bridging function (i.e. a service-specific > function), where as in DVPLS the N-PE merely splices PWs in a > service-agnostic way. > > > > > I would appreciate references to multi-hop LSPs if you can > > provide them. > > RFC 3031, RFC 3209 and RFC 3212 :-) > > A multi-hop PW is essentially an regular LSP. You may need to > extend existing specs to deal with FECs that may contain > non-routable information, perhaps along the lines of Ina > Minei's draft that we discussed this morning. Apart from > that, I don't see anything special. > > > > > Wrt interest - or lack thereof - based on Yaakov's draft, > the crucial > > question, IMO, is: what justifies support of Option 3 when Option 2 > > does the same job as well? Saving one label stack entry on the CE-PE > > packet clearly does not. And, from little I know about MPLS UNI > > (David is the expert here), it allows you to obtain a valid > transport > > label without the need to learn the core topology. It is also > > a clear-cut > > control plane solution, without the need for a new function > > (PSF) in the > > high-speed data plane. > > > > Please note that I do not reject Option 3 out of hand. I > simply try to > > understand its advantages (and disadvantages:-). > > > > At the same time I feel pretty sure that Option 1 is a dead-end. > > > > -------------------------------------------------------------- > > -------------- > > -------- > > 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: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > > Sent: Wednesday, November 12, 2003 1:01 AM > > > To: Sasha Vainshtein; Yaakov Stein (E-mail) > > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson > Pate (E-mail); > > > PWE3 WG (E-mail); David Sinicrope (E-mail) > > > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and Pseudowire > > > Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > > Sent: Tuesday, November 11, 2003 3:02 PM > > > > To: Yaakov Stein (E-mail) > > > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > > > > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) > > > > Subject: [PWE3] CE-to-CE PWs, Hierarchical VPLS and > > > > Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt > > > > > > > > > > > > Yaakov and all, > > > > I'd like to present the technical problem I have with the > > > > current text of draft-stein-pwe3-pwce2e-00.txt and options > > > > for solving this problem. > > > > > > > > My problem is with the following para in Section 3: > > > > > > > > > > > > The ideal way of handling a PWCE2E packet is to > > > > have the CE perform the service specific encapsulation > > > > and to prepend the (inner) PW label, but no > (outer) MPLS > > > > transport labels. The PE, which participates > in the provider > > > > network signaling, then adds the appropriate > MPLS labels > > > > as required. > > > > > > > > > > > > IMO, it is easy to see why this will not work as written. > > > > > > > > Please consider the following use case: > > > > > > > > 1. There are three CEs (CE-1, CE-2 and CE-3) attached > > > > to 3 PEs (PE-1, PE-2 and PE3 respectively). > > > > 2. In each case the link between CE-i and PE-i is a > > > > "single-hop" link (i.e., there are no LSRs in the > > > > path, but there may be L2 switches - Ethernet, FR/ATM etc). > > > > 3. You want to run two PWs: > > > > a) PW-12 runs between CE-1 and CE-2 > > > > b)PW-13 runs between CE-1 and CE-3. > > > > > > > > How can PE-1 (which both these PWs have to cross on their ways > > > > to their peer CEs) know which transport labels to add > to packets > > > > received from CE-1? > > > > > > > > This decision CANNOT be based on the PW labels in these > packets, > > > > because these labels are independently allocated by > CE-2 and CE-3 > > > > respectively, so that nothing prevents them from being equal > > > > (accidentally or else). > > > > And inspection of the encapsulated data will not help either. > > > > > > > > (BTW, this is exactly the difference between MPLS and, say, > > > > FR or ATM: in the latter cases, DLCI or VCI/VPI values are > > > > unique on the attachment link and known to the PE, > > > > in the former case they are not.) > > > > > > > > How can this be fixed? > > > > > > > > I see three ways to do so. > > > > > > > > 1. Limit this case to one PW per CE. IMO, this is > > > > a very problematic limitation (one could say, that > > > > it is ultimately non-scalable!) and does not > > > > justify any action wrt the existing documents. > > > > > > > > 2. Allow the CE to push both the PW and transport labels > > > > on top of the payload and PWE3 control info. > > > > This would make it equivalent to the "normal" PW,and no > > > > technical changes in the architecture doc are required. > > > > The transport label can be obtained in many different ways, > > > > including usage of the MPLS UNI (as suggested by David > > > > Sinicrope). > > > > > > > > 3. Use PW stitching. This would introduce a new element > > > > in the PWE3 architecture - the Pseudo-Wire > > > > Stitching Function (PSF) - located in the PEs. > > > > The PSF would operate like following: > > > > a) Terminate a "usual" PW running between two PEs > > > > adjacent to the CEs in question. > > > > Note that the PEs must exchange their incoming > > > > PW labels for this PW just as in the "normal" case > > > > b) Terminate the "spoke" PW between the CE and its > adjacent PE. > > > > This PW would not require transport labels because > > > the CE<-->PE > > > > transport LSPs are just one hop, and PHP can be applied > > > > to them. > > > > The PW labels for the spoke PWs would be exchanged > > > > between the CE and > > > > its adjacent PE in the usual way. > > > > c) Stitch the spoke PW with the PE-PE PW. Such a > > stitching would: > > > > * Leave the PW packet payload and control info (if > > any) intact > > > > * Swap the inner label > > > > * In one direction (CE-->PE), push the transport > > > > label(s) required for the PE-PE PW. > > > > Opposite to the PW IWFs, one and only one PSF type > is required. > > > > The resulting architecture resembles the Hierarchical VPLS > > > > defined in > > > > draft-ietf-l2vln-vpls-ldp-01.txt (hence the term > > "Spoke PW"). Its > > > > advantage > > > > stems from moving the service-specific IWF functionality > > > > towards the CE > > > > (and hence > > > > may be of special importance for TDM PWs), while > possibility of > > > > misconfiguration > > > > (e.g., connection of IWFs with different service > > types) should be > > > > considered > > > > as a disadvantage. Another disadvantage, of course, is > > > > introduction of a > > > > new > > > > (albeit simple) architectural element in the high-speed > > > data plane. > > > > > > > > IMO, any technical changes in the architecture document > > > > should be considered > > > > only if we reach a conclusion that advantages of the PW > > > > stitching option > > > > outweigh its disadvantages. > > > > > > Sasha, > > > > > > I believe that option 3 is identical to the Distributed VPLS > > > model described in section 5.5 of > draft-ietf-l2vpn-signaling-00.txt. > > > > > > IMO, CE-CE PWs is just one example of situations that require > > > multi-hop PWs. > > > > > > draft-ietf-l2vpn-signaling-00.txt talks about splicing PWs. > > > You talk about stitching PWs. In both cases the solution > > > sounds kludgy, to say the least. However, if you look at > > > these multi-hop PWs as regular LSPs established along a > > > multi-hop path, everything is pretty much straightforward. > > > Setup of such multi-hop LSPs would require a protocol like > > > CR-LDP or RSVP. RSVP is in my view the preferred solution, > > > but CR-LDP would be closer to the current control draft. > > > > > > In any case, as I said in another email, I would prefer it if > > > we would solve the multi-hop issue before progressing the > > > control draft. The response to that email was that it is not > > > clear that people are interested in the multi-hop solution. I > > > would argue that Yaakov's contribution shows that there > is interest. > > > > > > Peter > > > > > > > > > > > Hope these notes would be helpful. > > > > -------------------------------------------------------------- > > > > -------------- > > > > -------- > > > > With best regards, > > > > Sasha Vainshtein > > > > email: sasha@axerra.com > > > > phone: +972-3-7659993 (office) > > > > +972-8-9254948 (home) > > > > +972-58-674833 (cellular) > > > > > > > > _______________________________________________ > > > > 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: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 03:27:54 +0200 Lines: 304 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A8BC.3241834D" Cc: "Alik Shimelmits" , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 02:30:05 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Thread-Index: AcOolwxSDo96ui9aRW6yyKyYrsdgLgAIvicl To: "Alexander Vainshtein" 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_01C3A8BC.3241834D Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Sasha,=20 See a few comments below, I'd like to present the technical problem I have with the=20 current text of draft-stein-pwe3-pwce2e-00.txt and options=20 for solving this problem. My problem is with the following para in Section 3: The ideal way of handling a PWCE2E packet is to=20 have the CE perform the service specific encapsulation=20 and to prepend the (inner) PW label, but no (outer) MPLS=20 transport labels. The PE, which participates in the provider=20 network signaling, then adds the appropriate MPLS labels=20 as required. IMO, it is easy to see why this will not work as written. Please consider the following use case: 1. There are three CEs (CE-1, CE-2 and CE-3) attached=20 to 3 PEs (PE-1, PE-2 and PE3 respectively). 2. In each case the link between CE-i and PE-i is a=20 "single-hop" link (i.e., there are no LSRs in the=20 path, but there may be L2 switches - Ethernet, FR/ATM etc). 3. You want to run two PWs:=20 a) PW-12 runs between CE-1 and CE-2=20 b)PW-13 runs between CE-1 and CE-3. How can PE-1 (which both these PWs have to cross on their ways=20 to their peer CEs) know which transport labels to add to packets=20 received from CE-1? This decision CANNOT be based on the PW labels in these packets,=20 because these labels are independently allocated by CE-2 and CE-3=20 respectively, so that nothing prevents them from being equal=20 (accidentally or else).=20 And inspection of the encapsulated data will not help either. (BTW, this is exactly the difference between MPLS and, say,=20 FR or ATM: in the latter cases, DLCI or VCI/VPI values are=20 unique on the attachment link and known to the PE,=20 in the former case they are not.) [Y(J)S] You are assuming that these inner labels are independently downstream allocated by CE2 and CE3, which doesn't have to be the case.=20 [Y(J)S] An easy fix is for PW labels to have "structure", for example (what we do) is to use input-port + output port + = serial-number. [Y(J)S] All that is needed is for the PW labels to be unique in CE1. How can this be fixed? I see three ways to do so. 1. Limit this case to one PW per CE. IMO, this is a very problematic limitation (one could say, that it is ultimately non-scalable!) and does not=20 justify any action wrt the existing documents. [Y(J)S] Agreed that this is very limited, although a common situation. 2. Allow the CE to push both the PW and transport labels on top of the payload and PWE3 control info. This would make it equivalent to the "normal" PW,and no technical changes in the architecture doc are required. The transport label can be obtained in many different ways, including usage of the MPLS UNI (as suggested by David=20 Sinicrope). [Y(J)S] I don't want to make an MPLS stack here. 3. Use PW stitching. This would introduce a new element=20 in the PWE3 architecture - the Pseudo-Wire Stitching Function (PSF) - located in the PEs.=20 The PSF would operate like following: a) Terminate a "usual" PW running between two PEs=20 adjacent to the CEs in question.=20 Note that the PEs must exchange their incoming PW labels for this PW just as in the "normal" case b) Terminate the "spoke" PW between the CE and its adjacent PE. This PW would not require transport labels because the CE<-->PE transport LSPs are just one hop, and PHP can be applied to them.=20 The PW labels for the spoke PWs would be exchanged between the CE = and its adjacent PE in the usual way. c) Stitch the spoke PW with the PE-PE PW. Such a stitching would: * Leave the PW packet payload and control info (if any) intact * Swap the inner label=20 * In one direction (CE-->PE), push the transport label(s) required for the PE-PE PW.=20 Opposite to the PW IWFs, one and only one PSF type is required. The resulting architecture resembles the Hierarchical VPLS defined in draft-ietf-l2vln-vpls-ldp-01.txt (hence the term "Spoke PW"). Its advantage stems from moving the service-specific IWF functionality towards the = CE (and hence may be of special importance for TDM PWs), while possibility of misconfiguration=20 (e.g., connection of IWFs with different service types) should be considered=20 as a disadvantage. Another disadvantage, of course, is introduction = of a new=20 (albeit simple) architectural element in the high-speed data plane. =20 IMO, any technical changes in the architecture document should be = considered only if we reach a conclusion that advantages of the PW stitching option outweigh its disadvantages.=20 =20 Hope these notes would be helpful. [Y(J)S] Very. ------_=_NextPart_001_01C3A8BC.3241834D Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching = Function in draft-stein-pwe3-pwce2e-00.txt

Sasha,

See a few comments below,


I'd like to present the technical problem I have with the
current text of draft-stein-pwe3-pwce2e-00.txt and options
for solving this problem.

My problem is with the following para in Section 3:

<quote>
        The ideal way of handling a = PWCE2E packet is to
        have the CE perform  the = service specific encapsulation
        and to prepend the (inner) PW = label, but no (outer) MPLS
        transport labels.  The = PE, which participates in the provider
        network signaling, then adds = the appropriate MPLS labels
        as required.
<end quote>

IMO, it is easy to see why this will not work as written.

Please consider the following use case:

1. There are three CEs  (CE-1, CE-2 and CE-3) attached
   to 3 PEs (PE-1, PE-2 and PE3 respectively).
2. In each case the link between CE-i and PE-i is a
   "single-hop" link (i.e., there are no LSRs in = the
   path, but there may be L2 switches - Ethernet, FR/ATM = etc).
3. You want to run two PWs:
   a) PW-12 runs between CE-1 and CE-2
   b)PW-13 runs between CE-1 and CE-3.

How can PE-1 (which both these PWs have to cross on their ways
to their peer CEs) know which transport labels to add to packets
received from CE-1?

This decision CANNOT be based on the PW labels in these packets,
because these labels are independently allocated by CE-2 and CE-3
respectively, so that nothing prevents them from being equal
(accidentally or else).
And inspection of the encapsulated data will not help either.

(BTW, this is exactly the difference between MPLS and, say,
FR or ATM: in the latter cases, DLCI or VCI/VPI values are
unique on the attachment link and known to the PE,
in the former case they are not.)

[Y(J)S]  You are assuming that these inner labels are
independently downstream allocated by CE2 and CE3,
which doesn't have to be the case.

[Y(J)S] An easy fix is for PW labels to have "structure",
for example (what we do) is to use input-port + output port + = serial-number.

[Y(J)S] All that is needed is for the PW labels to be unique in CE1.

How can this be fixed?

I see three ways to do so.

1. Limit this case to one PW per CE. IMO, this is
   a very problematic limitation (one could say, that
   it is ultimately non-scalable!) and does not
   justify any action wrt the existing documents.

[Y(J)S] Agreed that this is very limited, although a common = situation.

2. Allow the CE to push both the PW and transport labels
   on top of the payload and PWE3 control info.
   This would make it equivalent to the "normal" = PW,and no
   technical changes in the architecture doc are required.
   The transport label can be obtained in many different = ways,
   including usage of the MPLS UNI (as suggested by David
   Sinicrope).

[Y(J)S] I don't want to make an MPLS stack here.

3. Use PW stitching. This would introduce a new element
   in the PWE3 architecture - the Pseudo-Wire
   Stitching Function (PSF) - located in the PEs.
   The PSF would operate like following:
   a) Terminate a "usual" PW running between two = PEs
      adjacent to the CEs in question.
      Note that the PEs  must exchange = their incoming
      PW labels for this PW just as in the = "normal" case
   b) Terminate the "spoke" PW between the CE and = its adjacent PE.
      This PW would not require transport = labels because the CE<-->PE
      transport LSPs are just one hop, and PHP = can be applied to them.
      The PW labels for the spoke PWs would be = exchanged between the CE and
      its adjacent PE in the usual way.
   c) Stitch the spoke PW with the PE-PE PW. Such a stitching = would:
      * Leave the PW packet payload and control = info (if any) intact
      * Swap the inner label
      * In one direction (CE-->PE), push the = transport
        label(s) required for the = PE-PE PW.
   Opposite to the PW IWFs, one and only one PSF type is = required.
   The resulting architecture resembles the Hierarchical VPLS = defined in
   draft-ietf-l2vln-vpls-ldp-01.txt (hence the term = "Spoke PW"). Its
advantage
   stems from moving the service-specific IWF functionality = towards the CE
(and hence
   may be of special importance for TDM PWs), while = possibility of
misconfiguration
   (e.g., connection of IWFs with different service types) = should be
considered
   as a disadvantage. Another disadvantage, of course, is = introduction of a
new
   (albeit simple) architectural element in the high-speed = data plane.
  
IMO, any technical changes in the architecture document should be = considered
only if we reach a conclusion that advantages of the PW stitching = option
outweigh its disadvantages.
  
Hope these notes would be helpful.

[Y(J)S] Very.

------_=_NextPart_001_01C3A8BC.3241834D-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: ITU-T FR draft Date: Wed, 12 Nov 2003 03:49:38 +0200 Lines: 64 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A8BF.3B3898C1" Cc: X-From: pwe3-admin@ietf.org Wed Nov 12 02:52:03 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: ITU-T FR draft Thread-Index: AcOovzr1PhDBoEecQYC0RqA/DVrvPA== 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_01C3A8BF.3B3898C1 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Dear WG chairs and everyone,=20 I would like to re-iterate my suggestion that the IETF and ITU-T SG17 work together to produce a single harmonized=20 FR draft. Since SG17 has adopted the PWE3 terminology, and there is great overlap in authors of the PWE and ITU drafts, it should be possible to make the documents precisely identical. This has been done before (e.g. Megaco/H.248) and has the advantage of ensuring that there can be no minor issues that can later crop up due to different wording. Y(J)S ------_=_NextPart_001_01C3A8BF.3B3898C1 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable ITU-T FR draft

Dear WG chairs and everyone,

I would like to re-iterate my suggestion that the IETF and
ITU-T SG17 work together to produce a single harmonized
FR draft.

Since SG17 has adopted the PWE3 terminology,
and there is great overlap in authors of the PWE and ITU drafts,
it should be possible to make the documents precisely identical.

This has been done before (e.g. Megaco/H.248)
and has the advantage of ensuring that there can be
no minor issues that can later crop up due to different
wording.

Y(J)S

------_=_NextPart_001_01C3A8BF.3B3898C1-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: PW-CE2-E Date: Wed, 12 Nov 2003 04:00:33 +0200 Lines: 95 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A8C0.C1850E09" X-From: pwe3-admin@ietf.org Wed Nov 12 03:03:04 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: PW-CE2-E Thread-Index: AcOowMGCLoIZ0l/0S2mZCIONK/ixyQ== 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_01C3A8C0.C1850E09 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable >From the questions people have asked after the presentation, I have realized that I may have been misunderstood. (except, of course, by people who read the draft ...) My suggestion is to move the IWF only, not the PE signaling function, to the CE location. The CE does not start participating in the PW setup - rather like the decoupled PE model in VPLS. The new technical feature (the 5 percent I was talking about) is the ability to send a "light MPLS" packet from the CE to the PE. This packet contains the payload (of whatever type), the CW and the "inner" label. (See also Sasha's comments on this label.) The present breed of MPLS edge routers do not understand what to do with such packets, and require the CE to use full IP encapsulation. So we end up with XoIPoMPLS instead of XoMPLS PWs. Albeit, this may be a subject for the MPLS WG, but the motivation is PWE. =20 Due to the state of the architecture draft, I withdraw my request to modify it. The question remains as to whether we need an additional draft to explain this case. Y(J)S ------_=_NextPart_001_01C3A8C0.C1850E09 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable PW-CE2-E

From the questions people have asked after the = presentation,
I have realized that I may have been misunderstood.
(except, of course, by people who read the draft ...)

My suggestion is to move the IWF only,
not the PE signaling function,
to the CE location.

The CE does not start participating in
the PW setup - rather like the decoupled PE model
in VPLS.

The new technical feature (the 5 percent I was talking about)
is the ability to send a "light MPLS" packet
from the CE to the PE. This packet contains the payload
(of whatever type), the CW and the "inner" label.
(See also Sasha's comments on this label.)

The present breed of MPLS edge routers do not understand
what to do with such packets, and require the CE to use full IP
encapsulation. So we end up with XoIPoMPLS instead of XoMPLS PWs.
Albeit, this may be a subject for the MPLS WG,
but the motivation is PWE.

Due to the state of the architecture draft,
I withdraw my request to modify it.
The question remains as to whether we need an additional
draft to explain this case.


Y(J)S

------_=_NextPart_001_01C3A8C0.C1850E09-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Func tion in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 04:03:34 +0200 Lines: 280 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-e57721af-277d-44b7-a9e5-f3044e558357" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 03:06:05 2003 Return-path: To: "'Yaakov Stein'" 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-e57721af-277d-44b7-a9e5-f3044e558357 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A8C1.2D9A5770" ------_=_NextPart_001_01C3A8C1.2D9A5770 Content-Type: text/plain; charset="windows-1255" Yaakov and all, Please see some comments/answers inline. I have snipped the irrelevant parts of the original text to increase readability. ---------------------------------------------------------------------------- -------- 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: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, November 12, 2003 3:28 AM To: Sasha Vainshtein Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Sasha, See a few comments below, [[Sasha]] ...snipped ... This decision CANNOT be based on the PW labels in these packets, because these labels are independently allocated by CE-2 and CE-3 respectively, so that nothing prevents them from being equal (accidentally or else). And inspection of the encapsulated data will not help either. [[Sasha]] ... snipped ... [Y(J)S] You are assuming that these inner labels are independently downstream allocated by CE2 and CE3, which doesn't have to be the case. [Y(J)S] An easy fix is for PW labels to have "structure", for example (what we do) is to use input-port + output port + serial-number. [Y(J)S] All that is needed is for the PW labels to be unique in CE1. [[Sasha]] I do not see this as ever becoming a standard approach. PW labels must be understood by the devices that terminate the pWs (in your case - CE-2 and CE-3).These devices can have their own preferences regarding global label space etc., and your "structured" labels can easily contradict these preferences. Not every device is ready to receive and process any value between 16 and 1M as a valid incoming labels (in fact, most don't). In addition, you require the labels to be correctly interpreted in two points - by the CE that terminates them and by the PE that adds transport labels based on the PW ones. IMO, this is a fundamental contadiction with the MPLS architecture and hence not acceptable. But let's, at least, present the complete solution ("structured" non-local labels and all) and discuss it! The draft did not ever mention "structured" labels (unless I missed something), and I did not consider an option that clearly contradicts the basics of the MPLS architecture. How can this be fixed? I see three ways to do so. 1. Limit this case to one PW per CE. IMO, this is a very problematic limitation (one could say, that it is ultimately non-scalable!) and does not justify any action wrt the existing documents. [Y(J)S] Agreed that this is very limited, although a common situation. [[Sasha]] The problem, as I see it, is that, with your solution, this is a dead-end situation. The moment your customer requests termination of one more PW in the same CE, you cannot provide a solution even if the customer is ready to pay for a more powerful CE! 2. Allow the CE to push both the PW and transport labels on top of the payload and PWE3 control info. This would make it equivalent to the "normal" PW,and no technical changes in the architecture doc are required. The transport label can be obtained in many different ways, including usage of the MPLS UNI (as suggested by David Sinicrope). [Y(J)S] I don't want to make an MPLS stack here. [[Sasha]] Franly I do not see it as a problem, but, if it is, let's solve it in the specific devices that encounter it - this is definitely not a common problem! [[Sasha]] ... snipped ... IMO, any technical changes in the architecture document should be considered only if we reach a conclusion that advantages of the PW stitching option outweigh its disadvantages. Hope these notes would be helpful. [Y(J)S] Very. ------_=_NextPart_001_01C3A8C1.2D9A5770 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching = Function in draft-stein-pwe3-pwce2e-00.txt
Yaakov=20 and all,
Please=20 see some comments/answers inline.
I have=20 snipped the irrelevant parts of the original text to increase=20 readability.
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:   sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
-----Original Message-----
From: Yaakov Stein=20 [mailto:yaakov_s@rad.com]
Sent: Wednesday, November 12, = 2003 3:28=20 AM
To: Sasha Vainshtein
Cc: Alik Shimelmits; = Stewart=20 Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David = Sinicrope=20 (E-mail)
Subject: RE: CE-to-CE PWs, Hierarchical VPLS and = Pseudowire=20 Stitching Function in = draft-stein-pwe3-pwce2e-00.txt


Sasha,

See a few comments = below,

[[Sasha]] ...snipped = ...

 This = decision=20 CANNOT be based on the PW labels in these packets,
because these = labels are=20 independently allocated by CE-2 and CE-3
respectively, so that = nothing=20 prevents them from being equal
(accidentally or else).
And = inspection of=20 the encapsulated data will not help either.

[[Sasha]] ...=20 snipped ... 
[Y(J)S]  You are assuming = that these=20 inner labels are
independently downstream allocated by CE2 and=20 CE3,
which doesn't have to be the case.

[Y(J)S] An easy fix = is for=20 PW labels to have "structure",
for example (what we do) is to use=20 input-port + output port + serial-number.

[Y(J)S] All that is = needed is=20 for the PW labels to be unique in CE1.
[[Sasha]] I do not see this as ever = becoming a=20 standard approach.  PW labels must be understood by the devices = that=20 terminate the pWs (in your case - CE-2 and CE-3).These devices can = have their=20 own preferences regarding global label space etc., and your = "structured"=20 labels can easily contradict these preferences. Not every device is = ready to=20 receive and process any value between 16 and 1M as a valid incoming = labels (in=20 fact, most don't). In addition, you require the labels to be = correctly=20 interpreted in two points - by the CE that terminates them and by the = PE that=20 adds transport labels based on the PW ones. IMO, this is a = fundamental=20 contadiction with the MPLS architecture and hence not acceptable. But = let's,=20 at least, present the complete solution ("structured" non-local = labels and=20 all) and discuss it! The draft did not ever mention "structured" = labels=20 (unless I missed something), and I did not consider an option that = clearly=20 contradicts the basics of the MPLS = architecture.

How can=20 this be fixed?

I see three ways to do so.

1. Limit this = case to=20 one PW per CE. IMO, this is
   a very problematic = limitation (one=20 could say, that
   it is ultimately non-scalable!) and = does=20 not
   justify any action wrt the existing=20 documents.

[Y(J)S] Agreed that this is very limited, although = a common=20 situation.
[[Sasha]] The problem, as I see it, is = that, with your=20 solution, this is a dead-end situation. The moment your customer = requests=20 termination of one more PW in the same CE, you cannot provide a = solution=20 even if the customer is ready to pay for a more powerful=20 CE!

2. Allow the CE to push both the PW and = transport=20 labels
   on top of the payload and PWE3 control=20 info.
   This would make it equivalent to the "normal" = PW,and=20 no
   technical changes in the architecture doc are=20 required.
   The transport label can be obtained in many = different ways,
   including usage of the MPLS UNI (as = suggested=20 by David
   Sinicrope).

[Y(J)S] I don't want to = make an=20 MPLS stack here.
[[Sasha]] Franly I do not see it as = a problem, but, if=20 it is, let's solve it in the specific devices that encounter it - = this is=20 definitely not a common problem! 
[[Sasha]] ...=20 snipped ...

 IMO, = any technical=20 changes in the architecture document should be considered
only if = we reach=20 a conclusion that advantages of the PW stitching option
outweigh = its=20 disadvantages.
  
Hope these notes would be=20 helpful.

[Y(J)S] Very.

------_=_NextPart_001_01C3A8C1.2D9A5770-- ------=_NextPartTM-000-e57721af-277d-44b7-a9e5-f3044e558357-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: IP PW labeling Date: Wed, 12 Nov 2003 04:18:25 +0200 Lines: 122 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A8C3.4078E3AF" X-From: pwe3-admin@ietf.org Wed Nov 12 03:21:06 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: IP PW labeling Thread-Index: AcOow0B2PeEV102SQ0+6lAccaPE7gA== 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_01C3A8C3.4078E3AF Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi everyone,=20 Last night an important point came up once again, one we have been avoiding for too long. For the MPLS case we have a single agreed upon method of putting the PW label onto the packet. It is placed in an MPLS-style "inner label" which is at the bottom of the stack. We have never resolved where the PW label goes for the IP case. There are at least three possibilities. 1) Using the UDP source or destination port field. The problem is that using the UDP destination port (which is what RTP does) is non-standard use, since this field should be an application demuxer, not a PW demux. Although PWE devices may not be general purpose servers expected to respond in the completely standard way to=20 socket identifiers, it would not be unusual for certain UDP port numbers to be used, e.g. TFTP for SW upgrade, SNMP for management. Alternatively, we could use a well known UDP=20 destination port number identifying the PWE service,=20 and the IDP source port for PW label. This is the most efficient method in that it does not require any additional overhead. =20 2) We can use L2TPv3 as the demuxing mechanism. This has been discussed at length in the past, and seems to be a clean solution, even if nothing else of the L2TP is needed. 3) We can use "MPLS-light", i.e. slap on an MPLS-style inner label before the control word. Which of these methods does the WG want to endorse? Or do we want to allow everyone to pick what they want? Y(J)S ------_=_NextPart_001_01C3A8C3.4078E3AF Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IP PW labeling

Hi everyone,

Last night an important point came up once again,
one we have been avoiding for too long.

For the MPLS case we have a single agreed upon
method of putting the PW label onto the packet.
It is placed in an MPLS-style "inner label"
which is at the bottom of the stack.

We have never resolved where the PW label goes
for the IP case.

There are at least three possibilities.

1) Using the UDP source or destination port field.
   The problem is that using the UDP destination port
   (which is what RTP does) is non-standard use,
   since this field should be an application
   demuxer, not a PW demux. Although PWE devices
   may not be general purpose servers expected
   to respond in the completely standard way to
   socket identifiers, it would not be unusual
   for certain UDP port numbers to be used,
   e.g. TFTP for SW upgrade, SNMP for management.
   Alternatively, we could use a well known UDP
   destination port number identifying the PWE service,
   and the IDP source port for PW label.

   This is the most efficient method in that
   it does not require any additional overhead.
  
2) We can use L2TPv3 as the demuxing mechanism.
  This has been discussed at length in the past,
  and seems to be a clean solution, even if nothing
  else of the L2TP is needed.

3) We can use "MPLS-light", i.e. slap on an MPLS-style
  inner label before the control word.

Which of these methods does the WG want to endorse?
Or do we want to allow everyone to pick what they want?

Y(J)S

------_=_NextPart_001_01C3A8C3.4078E3AF-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 04:26:50 +0200 Lines: 139 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A8C4.6D8A76A5" Cc: "Alik Shimelmits" , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 03:29:01 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Thread-Index: AcOowRLSt0WZ6/DzSnu0JXTHd8CZFgAAmYLH To: "Alexander Vainshtein" 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_01C3A8C4.6D8A76A5 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable [[Sasha]] I do not see this as ever becoming a standard approach. PW = labels must be understood by the devices that terminate the pWs (in your case - CE-2 and CE-3).These devices can have their own preferences regarding = global label space etc., and your "structured" labels can easily contradict = these preferences. Not every device is ready to receive and process any value between 16 and 1M as a valid incoming labels (in fact, most don't). In addition, you require the labels to be correctly interpreted in two = points - by the CE that terminates them and by the PE that adds transport labels based on the PW ones. IMO, this is a fundamental contadiction with the = MPLS architecture and hence not acceptable. But let's, at least, present the complete solution ("structured" non-local labels and all) and discuss = it! The draft did not ever mention "structured" labels (unless I missed something), and I did not consider an option that clearly contradicts = the basics of the MPLS architecture. [Y(J)S] But these are NOT MPLS labels, they are PW labels. Why should PW labels be required to conform to the full MPLS constraints? [Y(J)S] What do we really need the PW label for? To diifferentiate between multiple PWs going together in a tunnel between the same two = devices. For example, several E1s going between two points. A very common solution is to use some coding of the port numbers of these E1s. [[Sasha]] Franly I do not see it as a problem, but, if it is, let's = solve it in the specific devices that encounter it - this is definitely not a = common problem!=20 [Y(J)S] Once again, the inner label is not a true MPLS label, and I don't see the need to force it to be one. Y(J)S ------_=_NextPart_001_01C3A8C4.6D8A76A5 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching = Function in draft-stein-pwe3-pwce2e-00.txt

[[Sasha]] I do not see this as ever becoming a = standard approach.  PW labels
must be understood by the devices that terminate the pWs (in your case = -
CE-2 and CE-3).These devices can have their own preferences regarding = global
label space etc., and your "structured" labels can easily = contradict these
preferences. Not every device is ready to receive and process any = value
between 16 and 1M as a valid incoming labels (in fact, most don't). = In
addition, you require the labels to be correctly interpreted in two = points -
by the CE that terminates them and by the PE that adds transport = labels
based on the PW ones. IMO, this is a fundamental contadiction with the = MPLS
architecture and hence not acceptable. But let's, at least, present = the
complete solution ("structured" non-local labels and all) and = discuss it!
The draft did not ever mention "structured" labels (unless I = missed
something), and I did not consider an option that clearly contradicts = the
basics of the MPLS architecture.

[Y(J)S] But these are NOT MPLS labels, they are PW labels.
Why should PW labels be required to conform to the full MPLS
constraints?

[Y(J)S] What do we really need the PW label for? To diifferentiate
between multiple PWs going together in a tunnel between the same two = devices.
For example, several E1s going between two points.
A very common solution is to use some coding of the port numbers
of these E1s.


<snip>


[[Sasha]] Franly I do not see it as a problem, but, if it is, let's = solve it
in the specific devices that encounter it - this is definitely not a = common
problem!

[Y(J)S] Once again, the inner label is not a true MPLS label,
and I don't see the need to force it to be one.

Y(J)S

------_=_NextPart_001_01C3A8C4.6D8A76A5-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 05:28:49 -0500 Lines: 36 Sender: pwe3-admin@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 12 11:30:17 2003 Return-path: To: "'tnadeau@cisco.com'" , "'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 Tom: It would be good to see Y.1712 (OAM functionality for ATM-MPLS interworking) also covered in this draft as it is directly applicable. I'd be glad to provide suggested edits. (it was presented as http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview-00.txt in Vienna) cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, November 10, 2003 10:47 PM > To: pwe3@ietf.org > Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as > PWE3 WG draft? > > > > The chairs requested that we take the > matter of adoption of this draft to the > list. Please comment. > > --Tom > http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt _______________________________________________ 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: neil.2.harrison@bt.com Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 12:06:53 -0000 Lines: 57 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 Nov 12 13:08:07 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? thread-index: AcOpCBQp41k86O1CSPWW3PBxHUXsJgAB4l8g To: , , X-OriginalArrivalTime: 12 Nov 2003 12:06:53.0490 (UTC) FILETIME=[75F4F120:01C3A915] 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 Dave I agree. Its also a very simple solution since we have a high = degree of functional convergence on both sides. regards, Neil > -----Original Message----- > From: David Allan [mailto:dallan@nortelnetworks.com] > Sent: 12 November 2003 10:29 > To: 'tnadeau@cisco.com'; 'pwe3@ietf.org' > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? >=20 >=20 > Tom: >=20 > It would be good to see Y.1712 (OAM functionality for=20 > ATM-MPLS interworking) > also covered in this draft as it is directly applicable. I'd=20 > be glad to > provide suggested edits. >=20 > (it was presented as > http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview -00.txt in Vienna) cheers=20 Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]=20 > Sent: Monday, November 10, 2003 10:47 PM > To: pwe3@ietf.org > Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as=20 > PWE3 WG draft? >=20 >=20 >=20 > The chairs requested that we take the > matter of adoption of this draft to the > list. Please comment. >=20 > --Tom >=20 http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt _______________________________________________ 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: Stewart Bryant Subject: IETF-58 draft minutes Date: Wed, 12 Nov 2003 15:38:45 +0000 Organization: Cisco Systems, Inc. Lines: 6 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 Wed Nov 12 16:40:11 2003 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 The draft minutes from the IETF-58 PWE3 meeting are on the pwe3 web site at: pwe3.tcb.net/meetings/ietf58/ Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: IP PW labeling Date: Wed, 12 Nov 2003 17:26:18 +0200 Lines: 276 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-8e808377-c00b-4b41-9343-931d32bde79d" Cc: Gonen Zilber , Sharon Galtzur X-From: pwe3-admin@ietf.org Wed Nov 12 17:01:06 2003 Return-path: To: "'Yaakov Stein'" , 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. ------=_NextPartTM-000-8e808377-c00b-4b41-9343-931d32bde79d Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A931.516CEAD0" ------_=_NextPart_001_01C3A931.516CEAD0 Content-Type: text/plain; charset="windows-1255" Yaakov and all, Please see some comments inline. ---------------------------------------------------------------------------- -------- 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: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, November 12, 2003 4:18 AM To: pwe3@ietf.org Subject: [PWE3] IP PW labeling Hi everyone, Last night an important point came up once again, one we have been avoiding for too long. For the MPLS case we have a single agreed upon method of putting the PW label onto the packet. It is placed in an MPLS-style "inner label" which is at the bottom of the stack. [[Sasha]] Please note that this method comes complete with a signaling protocol (Martini LDP extension). This protocol is now a WG document that have completed its WG Last Call and, to the best ofmy knowledge, has gained the de-facto industry acceptance even before that. A signaling protocol serves as an extremely powerful tool, e.g., by allowing shutdown of one endpoint of the PW if the other one has failed etc. We have never resolved where the PW label goes for the IP case. [[Sasha]] The architecture draft suggests several options.. There are at least three possibilities. 1) Using the UDP source or destination port field. The problem is that using the UDP destination port (which is what RTP does) is non-standard use, since this field should be an application demuxer, not a PW demux. Although PWE devices may not be general purpose servers expected to respond in the completely standard way to socket identifiers, it would not be unusual for certain UDP port numbers to be used, e.g. TFTP for SW upgrade, SNMP for management. [[Sasha]] I do not see any problem here nor does usage of some well-known UDP port numbers (You should probably add NTP,Radius and more to your list) prevent successful usage of destination UDP port as a PW demultiplexer. The real problem with using UDP is that it only admits manual configuration. Alternatively, we could use a well known UDP destination port number identifying the PWE service, and the IDP source port for PW label. This is the most efficient method in that it does not require any additional overhead. 2) We can use L2TPv3 as the demuxing mechanism. This has been discussed at length in the past, and seems to be a clean solution, even if nothing else of the L2TP is needed. [[Sasha]] L2TP provides both demultiplexing and a control protocol. This is its main advantage, and the L2TPExt WG has adopted a series of WG items describing signaling detailsfor may specific L2 services (FR, HFLC, Ethernet etc.). 3) We can use "MPLS-light", i.e. slap on an MPLS-style inner label before the control word. [[Sasha]] IMO the data plane of such a proposal is fully covered by the MPLS-in-IP/GRE/IPSec and it can go along with the same Martini-extended LDP as the control protocol. I can see a problem for the vendors (and,possibly, customers), who can find required degree of understanding of MPLS and LDP in devices that actually are not parts of any MPLS network problematic. Additional advantage of L2TPv3 is that it inherently established bi-directional connections (suitable for PWs) while LDP establishes uni-directional PW LSPs, and additional logic (described in somedetail in the PWE3 control protocol draft) is required to "pair" these into bi-directional PWs). The bottom line: IMO, the real difference is not in the data plane (unless we consider UDP checksums an advantage even if, as we know, they are routinely disabled) but in the complexity and flexibility of a control plane (or the consequences of not having one altogether). Which of these methods does the WG want to endorse? Or do we want to allow everyone to pick what they want? Y(J)S ------_=_NextPart_001_01C3A931.516CEAD0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable IP PW labeling
Yaakov=20 and all,
Please=20 see some comments inline.
 
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:   sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
-----Original Message-----
From: Yaakov Stein=20 [mailto:yaakov_s@rad.com]
Sent: Wednesday, November 12, = 2003 4:18=20 AM
To: pwe3@ietf.org
Subject: [PWE3] IP PW=20 labeling

Hi everyone,

Last night an important point = came up once=20 again,
one we have been avoiding for too long.

For the MPLS = case we=20 have a single agreed upon
method of putting the PW label onto the=20 packet.
It is placed in an MPLS-style "inner label"
which is at = the=20 bottom of the stack.
[[Sasha]] Please note that this method=20 comes complete with a signaling protocol (Martini LDP = extension). This=20 protocol is now a WG document that have completed its WG Last Call = and, to the=20 best ofmy knowledge, has gained the de-facto industry acceptance = even=20 before that. A signaling protocol serves as an extremely powerful = tool, e.g.,=20 by allowing shutdown of one endpoint of the PW if the other one has = failed=20 etc.

We have never resolved where the PW label=20 goes
for the IP case.
[[Sasha]] The architecture draft suggests = several=20 options..  

There are at least three=20 possibilities.

1) Using the UDP source or destination port=20 field.
   The problem is that using the UDP destination=20 port
   (which is what RTP does) is non-standard=20 use,
   since this field should be an = application
  =20 demuxer, not a PW demux. Although PWE devices
   may not = be=20 general purpose servers expected
   to respond in the = completely=20 standard way to
   socket identifiers, it would not be=20 unusual
   for certain UDP port numbers to be=20 used,
   e.g. TFTP for SW upgrade, SNMP for = management.
[[Sasha]] I=20 do not see any problem here nor does usage of some well-known UDP = port numbers=20 (You should probably add NTP,Radius and more to your list) prevent = successful=20 usage  of destination UDP port as a PW demultiplexer. The=20 real  problem=20 with using UDP is that it only admits manual=20 configuration.
   = Alternatively, we=20 could use a well known UDP
   destination port number = identifying=20 the PWE service,
   and the IDP source port for PW=20 label.

   This is the most efficient method in=20 that
   it does not require any additional=20 overhead.

  
2) We can use L2TPv3 as the demuxing = mechanism.
  This has been discussed at length in the = past,
 =20 and seems to be a clean solution, even if nothing
  else of = the L2TP=20 is needed.
[[Sasha]] L2TP provides both demultiplexing and = a=20 control protocol. This is its main advantage, and the L2TPExt WG = has=20 adopted a series of WG items describing signaling detailsfor may = specific L2=20 services (FR, HFLC, Ethernet etc.). 

3) We = can use=20 "MPLS-light", i.e. slap on an MPLS-style
  inner label before = the=20 control word.
[[Sasha]] IMO the data plane of such a proposal = is fully=20 covered by the MPLS-in-IP/GRE/IPSec and it can go along with the = same=20 Martini-extended LDP as the control protocol. I can see a = problem for the=20 vendors (and,possibly, customers), who can find required degree of=20 understanding of MPLS and LDP in devices that actually are not parts = of any=20 MPLS network problematic. Additional advantage of L2TPv3 is that it = inherently=20 established bi-directional connections (suitable for PWs) while LDP=20 establishes uni-directional PW LSPs, and additional logic (described = in=20 somedetail in the PWE3 control protocol draft) is required to "pair" = these=20 into bi-directional PWs). 

The bottom line: IMO, the = real=20 difference is not in the data plane (unless we consider UDP = checksums an advantage even if, as we know, they are routinely = disabled)=20 but in the complexity and flexibility of a control plane (or the = consequences of not having one altogether). 

Which of these methods = does the WG=20 want to endorse?
Or do we want to allow everyone to pick what they = want?

Y(J)S

------_=_NextPart_001_01C3A931.516CEAD0-- ------=_NextPartTM-000-8e808377-c00b-4b41-9343-931d32bde79d-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 09:06:08 -0700 Lines: 372 Sender: pwe3-admin@ietf.org References: <20031111092947.47774.qmail@web13505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Boundary_(ID_g/j/3sBIsAuSvrrkLOsj1Q)" Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 17:13:08 2003 Return-path: In-reply-to: <20031111092947.47774.qmail@web13505.mail.yahoo.com> To: "'Mark Seery'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: 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. --Boundary_(ID_g/j/3sBIsAuSvrrkLOsj1Q) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My requirement is that any errors that are injected into the network by the service provider not be allowed to leave the service provider network. Any PW/IP control traffic remains in the service provider network and should be protected from errors by TCP. If the service is IP, which does not have a checksum for the whole packet, the only solution at the egress of the provider's routed network would be to look at the Layer 4 CRC. The layer 2 tail circuits would be protected by the end-to-end FCS which would go from the customer router to the IP service edge. Hope this makes sense. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mark Seery Sent: Tuesday, November 11, 2003 2:30 AM To: Scott Kotrla Cc: pwe3@ietf.org Subject: RE: [PWE3] last call on control and ethernet drafts Scott Kotrla wrote: As a service provider writing RFPs for equipment vendors, I can very easily require the FCS to be kept..... Scott, please do not take my following comments as a rebuttal to your points, because I think enough people have expressed interest in this, for all types of logical transport/separation of layer arguments etc in addition to what you have said. However, I would like to make the following observation for your consideration, in what ever present or future context the observation might apply: At some point here we are establishing an architectural house of cards. If we can not trust the integrity of a PW, then it begs the question how will you trust any other service you offer based on IP or MPLS, and can you even trust the integrity of the PW control plane, making use of a PW data plane, and if you can't....... --Boundary_(ID_g/j/3sBIsAuSvrrkLOsj1Q) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

My requirement is that any errors = that are injected into the network by the service provider not be allowed to = leave the service provider network.  = Any PW/IP control traffic remains in the service provider network and should be = protected from errors by TCP.  If the = service is IP, which does not have a checksum for the whole packet, the only = solution at the egress of the provider’s routed network would be to look at = the Layer 4 CRC.  The layer 2 = tail circuits would be protected by the end-to-end FCS which would go from = the customer router to the IP service edge.

 

Hope this makes = sense.

 

Thanks,

=

 

Scott

 

-----Original = Message-----
From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On = Behalf Of Mark Seery
Sent: Tuesday, November = 11, 2003 2:30 AM
To: Scott Kotrla
Cc: pwe3@ietf.org
Subject: RE: [PWE3] last = call on control and ethernet drafts

 

 

Scott Kotrla <scott.kotrla@mci.com> wrote: =

As a service provider writing RFPs for = equipment vendors, I can very
easily require the FCS to be kept.....

<snipped to the = end>

Scott, please do not take my following = comments as a rebuttal to your points, because I think enough people have expressed = interest in this, for all types of logical transport/separation of layer = arguments etc in addition to what you have said.

 

However, I would like to make the following observation for your consideration, in what ever present or future = context the observation might apply:

 

At some point here we are establishing an architectural house of cards. If we can not trust the integrity of a PW, = then it begs the question how will you trust any other service you offer = based on IP or MPLS, and can you even trust the integrity of the PW control = plane, making use of a PW data plane, and if you = can't.......

 

 

 

 

--Boundary_(ID_g/j/3sBIsAuSvrrkLOsj1Q)-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Mark Seery Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 08:40:10 -0800 (PST) Lines: 60 Sender: pwe3-admin@ietf.org References: <000a01c3a936$e7f754e0$4a6032a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 17:41:14 2003 Return-path: To: Scott Kotrla In-Reply-To: <000a01c3a936$e7f754e0$4a6032a6@acer4wc5zk5t43> 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 Scott, thanks for the response. this makes sense, few comments below. --- Scott Kotrla wrote: > My requirement is that any errors that are injected into the network by > the service provider not be allowed to leave the service provider > network. Makes all kinds of sense - preserving a fundamental promise/value to the customer.... > Any PW/IP control traffic remains in the service provider > network and should be protected from errors by TCP. If the service is > IP, which does not have a checksum for the whole packet, the only > solution at the egress of the provider's routed network would be to look > at the Layer 4 CRC. The layer 2 tail circuits would be protected by the > end-to-end FCS which would go from the customer router to the IP service > edge. > > Hope this makes sense. > Your desire to preserve the integrity of the subscriber's payload makes sense, I don't think that is under any debate, by anyone that I have seen. Neil's comments about layer separation and simplification also make sense to me on a variety of intellectual/philiosophical (sp?) levels as well. There is a fundamental problem this entire issue raises though. For those that have worked around routers for a long time (and not suggesting you have not) there is a comfort and familiarity with the concept for stripping L2 headers/trailers on ingress and then reapplying them on egress (now extended by PWE from within a system to across a network - which perhaps is what makes a difference to you). The issue you raise, unintentionally perhaps, raises the question of whether routing works (as compared to transport - which is essentially what you are suggesting). There appears to be existence proofs that routing works, so I suspect this is the crux of the response. Yes some equipment does not support retaining the FCS, but this is an attribute of an approach (routing) not simply a technical nit. The power of routing has been the ability to strip PDUs out of any layer 2 network, forward them based on information not present in the L2 header, and then place the PDU back on to any other L2 network. It is a kind of interworking, without the complexity of interworking (I realise this is not interworking - just trying to make a point). In the IETF's approach to PWE, we see an extension of this philosphy (IMHO) - and I don't say that to diminish your concerns, merely to highlight a philisophical issue. So we see here in PWE an approach that is kind of routing and kind of transport, which makes for some interesting conversations, tensions, and expectation short falls ;-) Perhaps that is what organic (non-architected) evolution is all about, perhaps it is not, we shall see. For the record, I understand the desire of those to get a base draft moving forward, especially if adding the option to retain FCS is a moot point for a large base of installed equipment, and I support the movement forward of a separate draft on this issue. Best, Mark (BTW, thanks to chairs for a great issues presentation at yesterdays meeting) From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Func tion in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 17:39:14 +0200 Lines: 228 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-587f2a65-6682-4c4b-aeb2-7a57254da756" Cc: Alik Shimelmits , "Stewart Bryant (E-mail)" , "Prayson Pate (E-mail)" , "PWE3 WG (E-mail)" , "David Sinicrope (E-mail)" X-From: pwe3-admin@ietf.org Wed Nov 12 17:41:15 2003 Return-path: To: "'Yaakov Stein'" 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-587f2a65-6682-4c4b-aeb2-7a57254da756 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A933.2018D370" ------_=_NextPart_001_01C3A933.2018D370 Content-Type: text/plain; charset="windows-1255" Yaakov, Please see some answers/comments inline. ---------------------------------------------------------------------------- -------- 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: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, November 12, 2003 4:27 AM To: Sasha Vainshtein Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt [[Sasha]] I do not see this as ever becoming a standard approach. PW labels must be understood by the devices that terminate the pWs (in your case - CE-2 and CE-3).These devices can have their own preferences regarding global label space etc., and your "structured" labels can easily contradict these preferences. Not every device is ready to receive and process any value between 16 and 1M as a valid incoming labels (in fact, most don't). In addition, you require the labels to be correctly interpreted in two points - by the CE that terminates them and by the PE that adds transport labels based on the PW ones. IMO, this is a fundamental contadiction with the MPLS architecture and hence not acceptable. But let's, at least, present the complete solution ("structured" non-local labels and all) and discuss it! The draft did not ever mention "structured" labels (unless I missed something), and I did not consider an option that clearly contradicts the basics of the MPLS architecture. [Y(J)S] But these are NOT MPLS labels, they are PW labels. Why should PW labels be required to conform to the full MPLS constraints? [[Sasha]] One reason could be that demultiplexing in your data plane is the common MPLS one. BTW, this is why the PW labels are required to be marked as "bottom of the stack" while the transport labels are (implicitly) required not to be marked so. Another reason can be that you can use a well-known Ethertype (for Ethernet) or PPP protocol type (for PPP) when you carry the packet with asingle label over the CE-PE attachment circuit. [Y(J)S] What do we really need the PW label for? To diifferentiate between multiple PWs going together in a tunnel between the same two devices. For example, several E1s going between two points. [[Sasha]] IMO you contradict yourself here, because, in fact, your draft requires that the "PW label" is understood both by the receiving CE and by the PE adjacent to he transmitting CE. A very common solution is to use some coding of the port numbers of these E1s. [[Sasha]] I am not sure there is anything common about that, at least not with MPLS-based PWs. [[Sasha]] Franly I do not see it as a problem, but, if it is, let's solve it in the specific devices that encounter it - this is definitely not a common problem! [Y(J)S] Once again, the inner label is not a true MPLS label, and I don't see the need to force it to be one. Y(J)S ------_=_NextPart_001_01C3A933.2018D370 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching = Function in draft-stein-pwe3-pwce2e-00.txt
Yaakov,
Please=20 see some answers/comments inline.
 
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:   sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
-----Original Message-----
From: Yaakov Stein=20 [mailto:yaakov_s@rad.com]
Sent: Wednesday, November 12, = 2003 4:27=20 AM
To: Sasha Vainshtein
Cc: Alik Shimelmits; = Stewart=20 Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David = Sinicrope=20 (E-mail)
Subject: RE: CE-to-CE PWs, Hierarchical VPLS and = Pseudowire=20 Stitching Function in = draft-stein-pwe3-pwce2e-00.txt


[[Sasha]] I do not see this as ever becoming a = standard=20 approach.  PW labels
must be understood by the devices that = terminate=20 the pWs (in your case -
CE-2 and CE-3).These devices can have = their own=20 preferences regarding global
label space etc., and your = "structured" labels=20 can easily contradict these
preferences. Not every device is ready = to=20 receive and process any value
between 16 and 1M as a valid = incoming labels=20 (in fact, most don't). In
addition, you require the labels to be = correctly=20 interpreted in two points -
by the CE that terminates them and by = the PE=20 that adds transport labels
based on the PW ones. IMO, this is a = fundamental=20 contadiction with the MPLS
architecture and hence not acceptable. = But=20 let's, at least, present the
complete solution ("structured" = non-local=20 labels and all) and discuss it!
The draft did not ever mention = "structured"=20 labels (unless I missed
something), and I did not consider an = option that=20 clearly contradicts the
basics of the MPLS = architecture.

[Y(J)S] But=20 these are NOT MPLS labels, they are PW labels.
Why should PW = labels be=20 required to conform to the full MPLS
constraints?
[[Sasha]] One=20 reason could be that demultiplexing in your data = plane is the=20 common MPLS one. BTW, this is why the PW labels are = required to be=20 marked as "bottom of the stack" while the transport labels are=20 (implicitly) required not to be marked so. Another reason can be that = you can=20 use a well-known Ethertype (for Ethernet) or PPP protocol = type (for=20 PPP) when you carry the packet with asingle label over the CE-PE = attachment circuit.  

[Y(J)S] What do we = really need=20 the PW label for? To diifferentiate
between multiple PWs going = together in=20 a tunnel between the same two devices.
For example, several E1s = going=20 between two points.
[[Sasha]] IMO you contradict yourself = here,=20 because, in fact, your draft requires that the "PW label" is = understood both=20 by the receiving CE and by the PE adjacent to he transmitting=20 CE. 
A very common solution is to use some = coding of the=20 port numbers
of these E1s.
[[Sasha]] I am not = sure there is=20 anything common about that, at least not with = MPLS-based=20 PWs.


<snip>


[[Sasha]] = Franly I do=20 not see it as a problem, but, if it is, let's solve it
in the = specific=20 devices that encounter it - this is definitely not a=20 common
problem!

[Y(J)S] Once again, the inner label is not = a true=20 MPLS label,
and I don't see the need to force it to be=20 one.

Y(J)S


------_=_NextPart_001_01C3A933.2018D370-- ------=_NextPartTM-000-587f2a65-6682-4c4b-aeb2-7a57254da756-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 08:49:29 -0800 Lines: 36 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Wed Nov 12 17:51:05 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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, The only OAM function that is mappable in a network interworking case (e.g., PW) is AIS/RDI and up/down state. Any other type of mapping is not only architecturally wrong, but not required. So I suggest that first we have a debate on the higher level architectural issues and requirements before accepting this draft. Yours, -Shahram >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Monday, November 10, 2003 10:47 PM >To: pwe3@ietf.org >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG >draft? > > > > The chairs requested that we take the >matter of adoption of this draft to the >list. Please comment. > > --Tom > >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m ap-03.txt _______________________________________________ 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 Kotrla Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 10:17:35 -0700 Lines: 103 Sender: pwe3-admin@ietf.org References: <20031112164010.15115.qmail@web13505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 18:24:05 2003 Return-path: In-reply-to: <20031112164010.15115.qmail@web13505.mail.yahoo.com> To: "'Mark Seery'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Mark, I think the issue is that routers have never been considered transmission equipment. With advent of Pseudowires, that is changing, and I would propose that the requirement for L3 routers are different from the requirements of L3 networks that will be transporting lower level protocols. Thanks, Scott -----Original Message----- From: Mark Seery [mailto:m_seery@yahoo.com] Sent: Wednesday, November 12, 2003 9:40 AM To: Scott Kotrla Cc: pwe3@ietf.org; stds-802-1@ieee.org Subject: RE: [PWE3] last call on control and ethernet drafts Hi Scott, thanks for the response. this makes sense, few comments below. --- Scott Kotrla wrote: > My requirement is that any errors that are injected into the network by > the service provider not be allowed to leave the service provider > network. Makes all kinds of sense - preserving a fundamental promise/value to the customer.... > Any PW/IP control traffic remains in the service provider > network and should be protected from errors by TCP. If the service is > IP, which does not have a checksum for the whole packet, the only > solution at the egress of the provider's routed network would be to look > at the Layer 4 CRC. The layer 2 tail circuits would be protected by the > end-to-end FCS which would go from the customer router to the IP service > edge. > > Hope this makes sense. > Your desire to preserve the integrity of the subscriber's payload makes sense, I don't think that is under any debate, by anyone that I have seen. Neil's comments about layer separation and simplification also make sense to me on a variety of intellectual/philiosophical (sp?) levels as well. There is a fundamental problem this entire issue raises though. For those that have worked around routers for a long time (and not suggesting you have not) there is a comfort and familiarity with the concept for stripping L2 headers/trailers on ingress and then reapplying them on egress (now extended by PWE from within a system to across a network - which perhaps is what makes a difference to you). The issue you raise, unintentionally perhaps, raises the question of whether routing works (as compared to transport - which is essentially what you are suggesting). There appears to be existence proofs that routing works, so I suspect this is the crux of the response. Yes some equipment does not support retaining the FCS, but this is an attribute of an approach (routing) not simply a technical nit. The power of routing has been the ability to strip PDUs out of any layer 2 network, forward them based on information not present in the L2 header, and then place the PDU back on to any other L2 network. It is a kind of interworking, without the complexity of interworking (I realise this is not interworking - just trying to make a point). In the IETF's approach to PWE, we see an extension of this philosphy (IMHO) - and I don't say that to diminish your concerns, merely to highlight a philisophical issue. So we see here in PWE an approach that is kind of routing and kind of transport, which makes for some interesting conversations, tensions, and expectation short falls ;-) Perhaps that is what organic (non-architected) evolution is all about, perhaps it is not, we shall see. For the record, I understand the desire of those to get a base draft moving forward, especially if adding the option to retain FCS is a moot point for a large base of installed equipment, and I support the movement forward of a separate draft on this issue. Best, Mark (BTW, thanks to chairs for a great issues presentation at yesterdays meeting) From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 17:45:07 -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 X-From: pwe3-admin@ietf.org Wed Nov 12 18:46:07 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? thread-index: AcOpPUcEV+gVX2stTGSxbRDtvTUVYQABmMmg To: , , X-OriginalArrivalTime: 12 Nov 2003 17:45:07.0810 (UTC) FILETIME=[B6506C20:01C3A944] 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 Shahram.....to be strictly accurate here, in a client/server = networking I/W case the only server->client OAM function mapping that is = relevent is FDI (or AIS in old currency). RDI stays within the = layer/trail it is relevant to.....it has no upwards mapping from = server->client in a 'backwards direction' (if you see what I mean) but = terminates at the trail sink of the return direction (if one exists). Otherwise I agree with your remarks. =20 regards, Neil > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 12 November 2003 16:49 > To: 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? >=20 >=20 > Hi, >=20 > The only OAM function that is mappable in a network=20 > interworking case (e.g., PW) > is AIS/RDI and up/down state. Any other type of mapping is=20 > not only architecturally wrong, but not required. >=20 > So I suggest that first we have a debate on the higher level=20 > architectural issues > and requirements before accepting this draft. >=20 > Yours, > -Shahram >=20 >=20 > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Monday, November 10, 2003 10:47 PM > >To: pwe3@ietf.org > >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG > >draft? > > > > > > > > The chairs requested that we take the > >matter of adoption of this draft to the > >list. Please comment. > > > > --Tom > > > >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > ap-03.txt >=20 >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=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: Wei Luo Subject: Re: PW-CE2-E Date: Wed, 12 Nov 2003 09:48:53 -0800 Lines: 43 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5201860E96@exrad2.ad.rad.co.il> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 12 18:50:05 2003 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: Yaakov Stein 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 Yaakov, Could you help us understand how different this is from renaming "CE" to "PE" and "PE" to "P" from the functionality point of view (excluding the administrative boundary issue for a second)? Thanks, ---Wei Yaakov Stein wrote: > From the questions people have asked after the presentation, > I have realized that I may have been misunderstood. > (except, of course, by people who read the draft ...) > > My suggestion is to move the IWF only, > not the PE signaling function, > to the CE location. > > The CE does not start participating in > the PW setup - rather like the decoupled PE model > in VPLS. > > The new technical feature (the 5 percent I was talking about) > is the ability to send a "light MPLS" packet > from the CE to the PE. This packet contains the payload > (of whatever type), the CW and the "inner" label. > (See also Sasha's comments on this label.) > > The present breed of MPLS edge routers do not understand > what to do with such packets, and require the CE to use full IP > encapsulation. So we end up with XoIPoMPLS instead of XoMPLS PWs. > Albeit, this may be a subject for the MPLS WG, > but the motivation is PWE. > > Due to the state of the architecture draft, > I withdraw my request to modify it. > The question remains as to whether we need an additional > draft to explain this case. > > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Mustapha Aissaoui Subject: Re: PW-CE2-E Date: Wed, 12 Nov 2003 13:00:31 -0500 Organization: Alcatel Networks Corporaton Lines: 64 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5201860E96@exrad2.ad.rad.co.il> <3FB27285.4060700@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Yaakov Stein , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 12 19:03:09 2003 Return-path: X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en To: 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 Wei, well the service boundary dictates everything here. I interpret what Yaakov is looking for as a new attachment circuit type which uses the shim header as the identifier. How this label is assigned depends on the type of service being sold by the service provider. It could be assigned by the SP and then gets swapped in the PE to a PW lable (keep a 2-label stack model). Or it can be distributed between the CE and the PE does not mess with it and instead adds a 2 label stack to it (3 label stack model with the bottom label treated as a L2 identifier). Mustapha. ----------- Wei Luo wrote: > > Yaakov, > > Could you help us understand how different this is from renaming "CE" to "PE" > and "PE" to "P" from the functionality point of view (excluding the > administrative boundary issue for a second)? > > Thanks, > > ---Wei > > Yaakov Stein wrote: > > From the questions people have asked after the presentation, > > I have realized that I may have been misunderstood. > > (except, of course, by people who read the draft ...) > > > > My suggestion is to move the IWF only, > > not the PE signaling function, > > to the CE location. > > > > The CE does not start participating in > > the PW setup - rather like the decoupled PE model > > in VPLS. > > > > The new technical feature (the 5 percent I was talking about) > > is the ability to send a "light MPLS" packet > > from the CE to the PE. This packet contains the payload > > (of whatever type), the CW and the "inner" label. > > (See also Sasha's comments on this label.) > > > > The present breed of MPLS edge routers do not understand > > what to do with such packets, and require the CE to use full IP > > encapsulation. So we end up with XoIPoMPLS instead of XoMPLS PWs. > > Albeit, this may be a subject for the MPLS WG, > > but the motivation is PWE. > > > > Due to the state of the architecture draft, > > I withdraw my request to modify it. > > The question remains as to whether we need an additional > > draft to explain this case. > > > > > > Y(J)S > > > > _______________________________________________ > 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: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 10:04:03 -0800 Lines: 83 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Nov 12 19:05:05 2003 Return-path: To: "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 Right. So only AIS/FDI and Down state are mappable. The down state of MPLS layer (using CV or periodic ping) is used to generate AIS on the client layer (i.e., ATM, or FR). Also an FDI in MPLS layer could be used to generate AIS on client layer (ATM/FR). If the PEs don't support transport of ATM/FR AIS/RDI, then in theory it is possible (although not architecturally clean) to use some sort of signaling/message in MPLS network to inform the egress PE to generate the AIS/RDI on the ATM/FR connections. -Shahram >-----Original Message----- >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >Sent: Wednesday, November 12, 2003 12:45 PM >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > >Hi Shahram.....to be strictly accurate here, in a >client/server networking I/W case the only server->client OAM >function mapping that is relevent is FDI (or AIS in old >currency). RDI stays within the layer/trail it is relevant >to.....it has no upwards mapping from server->client in a >'backwards direction' (if you see what I mean) but terminates >at the trail sink of the return direction (if one exists). > >Otherwise I agree with your remarks. > >regards, Neil >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: 12 November 2003 16:49 >> To: 'tnadeau@cisco.com'; pwe3@ietf.org >> Subject: RE: [PWE3] Adopt >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> WG draft? >> >> >> Hi, >> >> The only OAM function that is mappable in a network >> interworking case (e.g., PW) >> is AIS/RDI and up/down state. Any other type of mapping is >> not only architecturally wrong, but not required. >> >> So I suggest that first we have a debate on the higher level >> architectural issues >> and requirements before accepting this draft. >> >> Yours, >> -Shahram >> >> >> >-----Original Message----- >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> >Sent: Monday, November 10, 2003 10:47 PM >> >To: pwe3@ietf.org >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >as PWE3 WG >> >draft? >> > >> > >> > >> > The chairs requested that we take the >> >matter of adoption of this draft to the >> >list. Please comment. >> > >> > --Tom >> > >> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >> ap-03.txt >> >> >> >> _______________________________________________ >> 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: mark seery Subject: Re: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 12:06:38 -0800 Lines: 33 Sender: pwe3-admin@ietf.org References: <002301c3a940$dde83690$4a6032a6@acer4wc5zk5t43> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 21:08:39 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Scott Kotrla In-Reply-To: <002301c3a940$dde83690$4a6032a6@acer4wc5zk5t43> 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 Kotrla wrote: >Mark, > >I think the issue is that routers have never been considered >transmission equipment. > true, worth noting, no doubt our friends at 802 have heard similar comments, but hard to parse in an engineering work group. I would also observe that class 5 switches are not used as transmission equipment either, so we have to understand whether we are dealing with a) requirements issues b) familiarity issues c) architecture domain issues (i.e. switching vs transmission) d) organizational issues e) other f) all of the above; and if we merge switching and transmission does that require a new way of thinking, or simply replicating both capabilities in the same system - no simple question for the industry to grapple with. no doubt though this is the unlanced boil that will pop in many forms during the life of this WG. >With advent of Pseudowires, that is changing, >and I would propose that the requirement for L3 routers are different >from the requirements of L3 networks that will be transporting lower >level protocols. > this is unquestionably true on many levels, specifically if the goal is to recreate a transmission facility from a functional, operations, and management perspective. my only, clumsy, point was that there is a proof point that you can strip an FCS, even change the PDU, and reapply the FCS and it works. people here are inherently aware of that proof point which plays in to the discussion. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Func tion in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 19:54:33 +0200 Lines: 393 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a7378d62-d44d-44ab-9fe2-5825700c81a4" Cc: Alik Shimelmits , "'Stewart Bryant (E-mail)'" , "'Prayson Pate (E-mail)'" , "'PWE3 WG (E-mail)'" , "'David Sinicrope (E-mail)'" X-From: pwe3-admin@ietf.org Wed Nov 12 21:43:30 2003 Return-path: To: "'Yaakov Stein'" 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-a7378d62-d44d-44ab-9fe2-5825700c81a4 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3A946.07933A80" ------_=_NextPart_001_01C3A946.07933A80 Content-Type: text/plain; charset="windows-1255" Yaakov and all, I did not address the following statement/question in my previous email: [Y(J)S] Once again, the inner label is not a true MPLS label, and I don't see the need to force it to be one. I'll try to do so now. Let's assume for the moment that the inner label is not part of the label stack (IMO,it cannot be if it is not a true MPLS label!). As a consequence, the transport label must be marked as the bottom-of-the-stack,and the PE that is adjacent to the egress CE must know (somehow) how to forward the packet after it pops the last label. This brings us to the situation described in Section 2.2 of RFC 3032 "Determining the network layer protocol". Instead of quoting the RFC I will only say that the egress PE MUST know that the packets carried over the terminated tunnel are CE-2-CE PW labels. In other words,you cannot reuse the PE-PE tunnel used by your CE-to-CE PWs to carry anything but PWs. What's more, in the case when more than one CE is attached to the same egress PE, you will need multiple tunels between the same pair of PEs (because PEs cannot rely on the non-MPLS "PW labels" for forwarding decisions. In short, as far asI can see, your proposal willonly work under the following restrictions: 1. No more than one CE is attached to each PE 2. No more than one PW is terminated at each CE. I do not think that these limitations are realistic, especially as I do not see any technical problems with doing same things in the standard way. ---------------------------------------------------------------------------- -------- 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: Sasha Vainshtein Sent: Wednesday, November 12, 2003 5:39 PM To: 'Yaakov Stein' Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt Yaakov, Please see some answers/comments inline. ---------------------------------------------------------------------------- -------- 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: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, November 12, 2003 4:27 AM To: Sasha Vainshtein Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt [[Sasha]] I do not see this as ever becoming a standard approach. PW labels must be understood by the devices that terminate the pWs (in your case - CE-2 and CE-3).These devices can have their own preferences regarding global label space etc., and your "structured" labels can easily contradict these preferences. Not every device is ready to receive and process any value between 16 and 1M as a valid incoming labels (in fact, most don't). In addition, you require the labels to be correctly interpreted in two points - by the CE that terminates them and by the PE that adds transport labels based on the PW ones. IMO, this is a fundamental contadiction with the MPLS architecture and hence not acceptable. But let's, at least, present the complete solution ("structured" non-local labels and all) and discuss it! The draft did not ever mention "structured" labels (unless I missed something), and I did not consider an option that clearly contradicts the basics of the MPLS architecture. [Y(J)S] But these are NOT MPLS labels, they are PW labels. Why should PW labels be required to conform to the full MPLS constraints? [[Sasha]] One reason could be that demultiplexing in your data plane is the common MPLS one. BTW, this is why the PW labels are required to be marked as "bottom of the stack" while the transport labels are (implicitly) required not to be marked so. Another reason can be that you can use a well-known Ethertype (for Ethernet) or PPP protocol type (for PPP) when you carry the packet with asingle label over the CE-PE attachment circuit. [Y(J)S] What do we really need the PW label for? To diifferentiate between multiple PWs going together in a tunnel between the same two devices. For example, several E1s going between two points. [[Sasha]] IMO you contradict yourself here, because, in fact, your draft requires that the "PW label" is understood both by the receiving CE and by the PE adjacent to he transmitting CE. A very common solution is to use some coding of the port numbers of these E1s. [[Sasha]] I am not sure there is anything common about that, at least not with MPLS-based PWs. [[Sasha]] Franly I do not see it as a problem, but, if it is, let's solve it in the specific devices that encounter it - this is definitely not a common problem! [Y(J)S] Once again, the inner label is not a true MPLS label, and I don't see the need to force it to be one. Y(J)S ------_=_NextPart_001_01C3A946.07933A80 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching = Function in draft-stein-pwe3-pwce2e-00.txt
Yaakov=20 and all,
I did=20 not address the following statement/question in my previous=20 email:
<quote>
[Y(J)S] Once = again, the inner=20 label is not a true MPLS label,
and I don't see the need to force = it to be=20 one.
<end quote>
I'll=20 try to do so now.
 
Let's=20 assume for the moment that the inner label is not part of the label = stack=20 (IMO,it cannot be if it is not a true MPLS label!). As a consequence, = the=20 transport label must be marked as the bottom-of-the-stack,and the PE = that is=20 adjacent to the egress CE must know (somehow) how to forward the packet = after it=20 pops the last label.
This=20 brings us to the situation described in Section 2.2 of RFC 3032 = "Determining the=20 network layer protocol". Instead of quoting the RFC I will only say = that the=20 egress PE MUST know that the packets carried over the terminated tunnel = are=20 CE-2-CE PW labels. In other words,you cannot reuse the PE-PE tunnel = used by your=20 CE-to-CE PWs to carry anything but PWs. What's more, in the case when = more than=20 one CE is attached to the same egress PE, you will need multiple tunels = between=20 the same pair of PEs (because PEs cannot rely on the non-MPLS "PW = labels" for=20 forwarding decisions.
In=20 short, as far asI can see, your proposal willonly work under the = following=20 restrictions:
  1. No=20 more than one CE is attached to each PE
  2. No=20 more than one PW is terminated at each CE.
I do=20 not think that these limitations are realistic, especially as I do not = see any=20 technical problems with doing same things in the standard=20 way.
 
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:   sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
-----Original Message-----
From: Sasha Vainshtein=20
Sent: Wednesday, November 12, 2003 5:39 PM
To: = 'Yaakov=20 Stein'
Cc: Alik Shimelmits; Stewart Bryant (E-mail); = Prayson Pate=20 (E-mail); PWE3 WG (E-mail); David Sinicrope = (E-mail)
Subject: RE:=20 CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitching Function in=20 draft-stein-pwe3-pwce2e-00.txt

Yaakov,
Please see some answers/comments inline.
 
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:  =20 sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
-----Original Message-----
From: Yaakov Stein=20 [mailto:yaakov_s@rad.com]
Sent: Wednesday, November 12, = 2003 4:27=20 AM
To: Sasha Vainshtein
Cc: Alik Shimelmits; = Stewart=20 Bryant (E-mail); Prayson Pate (E-mail); PWE3 WG (E-mail); David = Sinicrope=20 (E-mail)
Subject: RE: CE-to-CE PWs, Hierarchical VPLS and = Pseudowire Stitching Function in=20 draft-stein-pwe3-pwce2e-00.txt


[[Sasha]] I do not see this as ever becoming a = standard=20 approach.  PW labels
must be understood by the devices that = terminate the pWs (in your case -
CE-2 and CE-3).These devices = can have=20 their own preferences regarding global
label space etc., and = your=20 "structured" labels can easily contradict these
preferences. Not = every=20 device is ready to receive and process any value
between 16 and = 1M as a=20 valid incoming labels (in fact, most don't). In
addition, you = require the=20 labels to be correctly interpreted in two points -
by the CE = that=20 terminates them and by the PE that adds transport labels
based = on the PW=20 ones. IMO, this is a fundamental contadiction with the = MPLS
architecture=20 and hence not acceptable. But let's, at least, present = the
complete=20 solution ("structured" non-local labels and all) and discuss = it!
The=20 draft did not ever mention "structured" labels (unless I=20 missed
something), and I did not consider an option that clearly = contradicts the
basics of the MPLS architecture.

[Y(J)S] = But these=20 are NOT MPLS labels, they are PW labels.
Why should PW labels be = required=20 to conform to the full MPLS
constraints?
[[Sasha]] One=20 reason could be that demultiplexing in your data = plane is the=20 common MPLS one. BTW, this is why the PW labels are = required to be=20 marked as "bottom of the stack" while the transport labels are = (implicitly) required not to be marked so. Another reason can be = that you=20 can use a well-known Ethertype (for Ethernet) or PPP = protocol type=20 (for PPP) when you carry the packet with asingle label over = the CE-PE=20 attachment circuit.  

[Y(J)S] What do we = really=20 need the PW label for? To diifferentiate
between multiple PWs = going=20 together in a tunnel between the same two devices.
For example, = several=20 E1s going between two points.
[[Sasha]] IMO you=20 contradict yourself here, because, in fact, your draft = requires that=20 the "PW label" is understood both by the receiving CE and by the PE = adjacent=20 to he transmitting CE. 
A very common = solution is to=20 use some coding of the port numbers
of these E1s.
[[Sasha]] I am not sure there is = anything=20 common about that, at least not with MPLS-based=20 PWs.


<snip>


[[Sasha]] = Franly I do=20 not see it as a problem, but, if it is, let's solve it
in the = specific=20 devices that encounter it - this is definitely not a=20 common
problem!

[Y(J)S] Once again, the inner label is = not a true=20 MPLS label,
and I don't see the need to force it to be=20 = one.

Y(J)S


------_=_NextPart_001_01C3A946.07933A80-- ------=_NextPartTM-000-a7378d62-d44d-44ab-9fe2-5825700c81a4-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 16:07:57 -0500 Lines: 111 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Nov 12 22:09:06 2003 Return-path: To: "'Shahram Davari'" , "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 Sharam, Are you commenting on the draft, or are you just guessing what you might find in the draft if you actually read it? Peter > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, November 12, 2003 12:04 PM > To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? > > > Right. So only AIS/FDI and Down state are mappable. The down > state of MPLS layer (using CV or periodic ping) is used to > generate AIS on the client layer (i.e., ATM, or FR). Also an > FDI in MPLS layer could be used to generate AIS on client > layer (ATM/FR). > > If the PEs don't support transport of ATM/FR AIS/RDI, then in > theory it is possible (although not architecturally clean) to > use some sort of signaling/message in MPLS network to inform > the egress PE to generate the AIS/RDI on the ATM/FR connections. > > -Shahram > > > > >-----Original Message----- > >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >Sent: Wednesday, November 12, 2003 12:45 PM > >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >Subject: RE: [PWE3] Adopt > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > >Hi Shahram.....to be strictly accurate here, in a > >client/server networking I/W case the only server->client OAM > >function mapping that is relevent is FDI (or AIS in old > >currency). RDI stays within the layer/trail it is relevant > >to.....it has no upwards mapping from server->client in a > >'backwards direction' (if you see what I mean) but terminates > >at the trail sink of the return direction (if one exists). > > > >Otherwise I agree with your remarks. > > > >regards, Neil > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: 12 November 2003 16:49 > >> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >> Subject: RE: [PWE3] Adopt > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> WG draft? > >> > >> > >> Hi, > >> > >> The only OAM function that is mappable in a network > >> interworking case (e.g., PW) > >> is AIS/RDI and up/down state. Any other type of mapping is > >> not only architecturally wrong, but not required. > >> > >> So I suggest that first we have a debate on the higher level > >> architectural issues > >> and requirements before accepting this draft. > >> > >> Yours, > >> -Shahram > >> > >> > >> >-----Original Message----- > >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> >Sent: Monday, November 10, 2003 10:47 PM > >> >To: pwe3@ietf.org > >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt > >as PWE3 WG > >> >draft? > >> > > >> > > >> > > >> > The chairs requested that we take the > >> >matter of adoption of this draft to the > >> >list. Please comment. > >> > > >> > --Tom > >> > > >> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > >> ap-03.txt > >> > >> > >> > >> _______________________________________________ > >> 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: Scott Kotrla Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 14:02:43 -0700 Lines: 96 Sender: pwe3-admin@ietf.org References: <3FB292CE.4010106@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 22:12:03 2003 Return-path: In-reply-to: <3FB292CE.4010106@yahoo.com> To: m_seery@yahoo.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Mark, I think we are dealing with all of the issues that you mentioned. While you can do a lot of things on a small scale, service providers can't put 10000s of devices into a network and afford to have gaping holes in their abilities to detect faults. One difference between transmission and switching has traditionally been that the size of the transmission network greatly outnumbered the size of the switching network in terms of number of nodes. As switching technology becomes intertwined in the transmission network, there is no doubt that changes must be made to switching protocols to build scale. Essentially, MCI's requirement is for an end-to-end FCS for detecting faults in the transmission/switching network. All MCI RFP's dealing with Ethernet transmission/switching will have this requirement. I believe that any service provider who looks at the ramifications of not providing an end-to-end guarantee against corruption (bounded by the CRC32 capabilities) will comes to the same conclusions that MCI has. Many service providers are ambivalent today in this area for many reasons: 1. They have not looked at anything beyond Private Line Ethernet services 2. They are not aware of the ramifications of not providing an end-to-end FCS 3. They haven't looked forward to a time in the future where the switching protocols become part of the transmission network I will stand by the assertion that all service providers will ultimately demand these capabilities until other service providers say otherwise. As long as this is the case, any equipment provider that wants to sell to service providers (and I assume this is any equipment provider involved in the 802.1ad project) will ultimately have to provide these capabilities in their equipment, whether it is part of the standard or not. I would think it would be in everybody's best interest to find out whether or not this is really a service provider requirement (and to make sure that those service providers who say it is not have really looked at the issue). If it is a requirement, it would seem that standardizing it is the only logical course of action, so that equipment providers can begin designing the capabilities into their equipment. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of mark seery Sent: Wednesday, November 12, 2003 1:07 PM To: Scott Kotrla Cc: pwe3@ietf.org; stds-802-1@ieee.org Subject: Re: [PWE3] last call on control and ethernet drafts Scott Kotrla wrote: >Mark, > >I think the issue is that routers have never been considered >transmission equipment. > true, worth noting, no doubt our friends at 802 have heard similar comments, but hard to parse in an engineering work group. I would also observe that class 5 switches are not used as transmission equipment either, so we have to understand whether we are dealing with a) requirements issues b) familiarity issues c) architecture domain issues (i.e. switching vs transmission) d) organizational issues e) other f) all of the above; and if we merge switching and transmission does that require a new way of thinking, or simply replicating both capabilities in the same system - no simple question for the industry to grapple with. no doubt though this is the unlanced boil that will pop in many forms during the life of this WG. >With advent of Pseudowires, that is changing, >and I would propose that the requirement for L3 routers are different >from the requirements of L3 networks that will be transporting lower >level protocols. > this is unquestionably true on many levels, specifically if the goal is to recreate a transmission facility from a functional, operations, and management perspective. my only, clumsy, point was that there is a proof point that you can strip an FCS, even change the PDU, and reapply the FCS and it works. people here are inherently aware of that proof point which plays in to the discussion. _______________________________________________ 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: Mark Seery Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 13:39:16 -0800 (PST) Lines: 36 Sender: pwe3-admin@ietf.org References: <000001c3a960$51bad860$498032a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 22:40:11 2003 Return-path: To: Scott Kotrla In-Reply-To: <000001c3a960$51bad860$498032a6@acer4wc5zk5t43> X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA11407 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 may have had HTML reenabled previously by mistake - my apologies if I = did).=A0 =A0 " Scott Kotrla wrote:=20 Mark, I think we are dealing with all of the issues that you mentioned. While you can do a lot of things on a small scale, service providers can't put 10000s of devices into a network and afford to have gaping holes in their abilities to detect faults. << So I think the question on some people's minds (mine included, I think Al= i also alluded to this) is whether e2e reuse of FCS helps the SP detect fault, o= r merely enables the subscriber to detect fault. I assume both are goals? I= also assume that you prefer not to enable the subscriber to do so unless you c= an as well ;-) Once again my clumsy articulation was the difference between pay= load integrity and FCS integrity. =A0 " 3. They haven't looked forward to a time in the future where the switching protocols become part of the transmission network " I don't know what assumptions the WG makes WRT this issue (would be inter= ested to hear an opinion from the chairs), what assumptions 802 makes, or what assumptions people in general make. But I suspect this is=A0a salient poi= nt, and the subconscious long-term pretext/foundation of challenges we have in pe= ople from different backgrounds holding hands across the aisle. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 21:57:35 -0000 Lines: 151 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 Nov 12 22:59:08 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? thread-index: AcOpR2KJFRBMAdoTQBOSkz0CnuU/QwAGgoZQ To: , , X-OriginalArrivalTime: 12 Nov 2003 21:57:35.0662 (UTC) FILETIME=[FB2334E0:01C3A967] 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 Shahram, please see below. regards, Neil Shahram Davari wrote=20 >=20 > Right. So only AIS/FDI and Down state are mappable. NH=3D> Correct. > The down=20 > state of MPLS layer (using CV or periodic ping) is used to=20 > generate AIS on the client layer (i.e., ATM, or FR). NH=3D> Yes. This is right architectural relationship. However, since = we also have the notion of PWs in this WG then strictly speaking the = mapping is now MPLS_FDI->PW_FDI->client_FDI. That is, there is an extra = layer here to 'map through'. Further, if there are any defects that can = exist in the extra PW layer entity itself then these must also be fully = specified in terms of entry/exit criteria and consequent actions.....one = of which is the mapping of FDI as we are discussing. As I have = mentioned before, the *adaptation* between any client and server layers = should be as simple as possible and the client and server layer networks = should be functionally independent. PWs have Seq No.s defined. = Therefore defects for these must also be defined, ie at what point are = Seq No. corruptions considered 'failed'? This has still not been done = and, speaking as an operator, it is not acceptable to leave this = open-ended like this. However, I can also say the same for the MPLS = layer, ie the LSPs themselves. These too need a complete set of defects = specifying in terms of entry/exit criteria and consequent actions. The = only place this exists AFAIK is in Y.1711. > Also an=20 > FDI in MPLS layer could be used to generate AIS on client=20 > layer (ATM/FR). NH=3D> Yes....and if you think about it, since MPLS layer defects can = only be detected at an LSP trail termination point, then the only source = of an observed FDI on a given LSP would be from a lower layer network = trail (which could be a co-cs technology like an SDH VC_4 or a lower = layer co-ps LSP). >=20 > If the PEs don't support transport of ATM/FR AIS/RDI, then in=20 > theory it is possible (although not architecturally clean) to=20 > use some sort of signaling/message in MPLS network to inform=20 > the egress PE to generate the AIS/RDI on the ATM/FR connections. NH=3D> The answer depends on the I/W relationship, ie whether it is = client/server network I/W or peer service I/W. In the case of simple client/server network I/W the server layer (eg = MPLS) should *never* interrupt the client's OAM signals....these are = required to pass transparently. If they don't, this is a serious = architectural violation. So here it should never be an issue (assuming = of course FDI is actually specified for the client layer technology = considered). If we have a peer service I/W relationship there is strictly *no* OAM = relationship between any of the peer network trails involved....as each = terminates it trail's CI (characteristic information) at an IWF, and = this includes all its OAM. However, this requires a FDI mapping to = whatever is the common higher layer entity that transparently spans all = the underlying peer server layer trails....and the mapping is = independent from each peer server layer trail partition to the common = higher layer entity. Most higher layer entities however do not have any = such OAM functions defined. In this case one can relax the strict = architectural rules and do what you are suggesting, ie map defects = detected in 1 network technology partition to an FDI indicate in the = downstream network partition. However, you must be very careful to make = sure this is done correctly. A good example of this is the OAM I/W = defined for ATM (I.610) and MPLS (Y.1711) in Y.1712. This is also very = simple because the harmonisation of these issues was considered early = on. This means we can have simple automatic defect detection/handling = between ATM and MPLS technologies......and which is something I'd assume = most operators would like to see in place.=20 >=20 > -Shahram >=20 >=20 >=20 > >-----Original Message----- > >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >Sent: Wednesday, November 12, 2003 12:45 PM > >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >Subject: RE: [PWE3] Adopt=20 > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > >Hi Shahram.....to be strictly accurate here, in a=20 > >client/server networking I/W case the only server->client OAM=20 > >function mapping that is relevent is FDI (or AIS in old=20 > >currency). RDI stays within the layer/trail it is relevant=20 > >to.....it has no upwards mapping from server->client in a=20 > >'backwards direction' (if you see what I mean) but terminates=20 > >at the trail sink of the return direction (if one exists). > > > >Otherwise I agree with your remarks. =20 > > > >regards, Neil > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: 12 November 2003 16:49 > >> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >> Subject: RE: [PWE3] Adopt=20 > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> WG draft? > >>=20 > >>=20 > >> Hi, > >>=20 > >> The only OAM function that is mappable in a network=20 > >> interworking case (e.g., PW) > >> is AIS/RDI and up/down state. Any other type of mapping is=20 > >> not only architecturally wrong, but not required. > >>=20 > >> So I suggest that first we have a debate on the higher level=20 > >> architectural issues > >> and requirements before accepting this draft. > >>=20 > >> Yours, > >> -Shahram > >>=20 > >>=20 > >> >-----Original Message----- > >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> >Sent: Monday, November 10, 2003 10:47 PM > >> >To: pwe3@ietf.org > >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >as PWE3 WG > >> >draft? > >> > > >> > > >> > > >> > The chairs requested that we take the > >> >matter of adoption of this draft to the > >> >list. Please comment. > >> > > >> > --Tom > >> > > >> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > >> ap-03.txt > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >>=20 > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www1.ietf.org/mailman/listinfo/pwe3 > >>=20 > > >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 15:12:41 -0700 Lines: 79 Sender: pwe3-admin@ietf.org References: <20031112213916.82994.qmail@web13505.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 23:19:10 2003 Return-path: In-reply-to: <20031112213916.82994.qmail@web13505.mail.yahoo.com> To: "'Mark Seery'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 The requirement would actually be to check the Path FCS on egress before handing off to the customer and not to pass packets that are corrupt. I sent out another email that describes the functionality of various interfaces in detail, but in short: 1. On ingress the customer FCS is checked, and either the packet is tossed and the appropriate counter is incremented or the packet is modified with new headers and new service FCS is added after the customer FCS 2. On egress after the packet is returned to its original condition with service tag and service FCS removed, the customer FCS is checked, and either the packet is tossed and the appropriate counter is incremented or the packet is sent to the customer. The ingress counters tell me if the customer was sending corrupt data and the egress counters tell me if the service provider network corrupted the packet. This seems extremely simple and extremely clean to me. People have said that this method doesn't tell you where the error is, and I would be interested to understanding the costs of checking both the customer and service FCS at every ingress port in the middle. My guess is that it is cost prohibitive and not backwards compatible. =20 I think everyone can agree that once you have identified that there is a problem in the service provider network, troubleshooting the problem is feasible, whereas if you can't determine if a problem is a customer problem or a service provider problem, troubleshooting a problem is next to impossible because there are too many variables. Thanks, Scott -----Original Message----- From: Mark Seery [mailto:m_seery@yahoo.com]=20 Sent: Wednesday, November 12, 2003 2:39 PM To: Scott Kotrla Cc: pwe3@ietf.org; stds-802-1@ieee.org Subject: RE: [PWE3] last call on control and ethernet drafts (I may have had HTML reenabled previously by mistake - my apologies if I did).=A0 =A0 " Scott Kotrla wrote:=20 Mark, I think we are dealing with all of the issues that you mentioned. While you can do a lot of things on a small scale, service providers can't put 10000s of devices into a network and afford to have gaping holes in their abilities to detect faults. << So I think the question on some people's minds (mine included, I think Ali also alluded to this) is whether e2e reuse of FCS helps the SP detect fault, or merely enables the subscriber to detect fault. I assume both are goals? I also assume that you prefer not to enable the subscriber to do so unless you can as well ;-) Once again my clumsy articulation was the difference between payload integrity and FCS integrity. =A0 " 3. They haven't looked forward to a time in the future where the switching protocols become part of the transmission network " I don't know what assumptions the WG makes WRT this issue (would be interested to hear an opinion from the chairs), what assumptions 802 makes, or what assumptions people in general make. But I suspect this is=A0a salient point, and the subconscious long-term pretext/foundation of challenges we have in people from different backgrounds holding hands across the aisle. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 14:33:14 -0800 Lines: 7 Sender: pwe3-admin@ietf.org References: <000001c3a96a$17a98900$498032a6@acer4wc5zk5t43> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Wed Nov 12 23:35:03 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Scott Kotrla In-Reply-To: <000001c3a96a$17a98900$498032a6@acer4wc5zk5t43> 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 Thanks Scott, actually my bad, rereading: draft-malis-pwe3-fcs-retention, because the customer FCS is rechecked on Egress, a secondary (service) FCS is probably not required for the Ethernet service case, if the customer FCS is retained, and the SP will know that a problem has occurred/or not. Your question about checking FCS at each point remains open, and perhaps other OAM mechanisms can supplement insight here. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 22:45:52 -0000 Lines: 65 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 Nov 12 23:47:02 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] last call on control and ethernet drafts thread-index: AcOpYbEH8kX4tJfoSOm/q9M1bewVMQAB2KPQ To: , X-OriginalArrivalTime: 12 Nov 2003 22:45:53.0148 (UTC) FILETIME=[BA2C7BC0:01C3A96E] 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 Scott please see below.......and speaking as service provider I am with = you totally on this stuff. regards, Neil Scott Kotrla wrote 12 November 2003 21:03 > >=20 > Mark, >=20 > I think we are dealing with all of the issues that you=20 > mentioned. While > you can do a lot of things on a small scale, service=20 > providers can't put > 10000s of devices into a network and afford to have gaping holes in > their abilities to detect faults. One difference between transmission > and switching has traditionally been that the size of the transmission > network greatly outnumbered the size of the switching network in terms > of number of nodes. As switching technology becomes=20 > intertwined in the > transmission network, there is no doubt that changes must be made to > switching protocols to build scale. >=20 > Essentially, MCI's requirement is for an end-to-end FCS for detecting > faults in the transmission/switching network. > > All MCI RFP's dealing > with Ethernet transmission/switching will have this requirement. I > believe that any service provider who looks at the=20 > ramifications of not > providing an end-to-end guarantee against corruption (bounded by the > CRC32 capabilities) will comes to the same conclusions that MCI has. > Many service providers are ambivalent today in this area for many > reasons: >=20 > 1. They have not looked at anything beyond Private Line Ethernet > services > 2. They are not aware of the ramifications of not providing an > end-to-end FCS > 3. They haven't looked forward to a time in the future where the > switching protocols become part of the transmission network >=20 > I will stand by the assertion that all service providers will=20 > ultimately > demand these capabilities until other service providers say otherwise. NH=3D> Scott, I'd go further than this and generalise your remarks here = to say that any layer network technology must have its own independent = OAM that can automatically detect all failures and automatically take = the right consequent actions. We need this to deliver quality services = to our customers and drive down our opex. The FCS of ethernet belongs = to the ethernet layer's characteristic information and thus can be = considered to be an intrinsic part of its OAM functionality. Further, a = layer network's characteristic information (which includes its OAM = functionality) must be transparently preserved in any client->server = encapsulations. {aside - The above reasons are precisely why, esp looking ahead at = possibly using MPLS as converged co-ps core, I was instrumental in = drafting Y.1710 and Y.1711 (MPLS OAM requirements and mechanisms = respectively). This is the only place I know where all defects are = fully specified in terms of automatic detection and handling. And for = similar reasons there is also now great activity in enhancing ethernet's = OAM capability in IEEE, MEF and ITU.} From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 18:02:50 -0600 Organization: Cisco Systems, inc. Lines: 57 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Nov 13 00:06:03 2003 Return-path: To: "'David Allan'" , 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 Importance: Normal 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 OK. I will take a look. --Tom >-----Original Message----- >From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >Behalf Of David Allan >Sent: Wednesday, November 12, 2003 4:29 AM >To: 'tnadeau@cisco.com'; 'pwe3@ietf.org' >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >as PWE3 WG draft? > > >Tom: > >It would be good to see Y.1712 (OAM functionality for ATM-MPLS >interworking) >also covered in this draft as it is directly applicable. I'd be glad to >provide suggested edits. > >(it was presented as >http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview- 00.txt in Vienna) cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, November 10, 2003 10:47 PM > To: pwe3@ietf.org > Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as > PWE3 WG draft? > > > > The chairs requested that we take the > matter of adoption of this draft to the > list. Please comment. > > --Tom > http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt _______________________________________________ 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: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 18:02:50 -0600 Organization: Cisco Systems, inc. Lines: 57 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Nov 13 00:06:04 2003 Return-path: To: "'David Allan'" , 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 Importance: Normal 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 OK. I will take a look. --Tom >-----Original Message----- >From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >Behalf Of David Allan >Sent: Wednesday, November 12, 2003 4:29 AM >To: 'tnadeau@cisco.com'; 'pwe3@ietf.org' >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >as PWE3 WG draft? > > >Tom: > >It would be good to see Y.1712 (OAM functionality for ATM-MPLS >interworking) >also covered in this draft as it is directly applicable. I'd be glad to >provide suggested edits. > >(it was presented as >http://www.ietf.org/internet-drafts/draft-allan-y17iw-overview- 00.txt in Vienna) cheers Dave > -----Original Message----- > From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > Sent: Monday, November 10, 2003 10:47 PM > To: pwe3@ietf.org > Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as > PWE3 WG draft? > > > > The chairs requested that we take the > matter of adoption of this draft to the > list. Please comment. > > --Tom > http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt _______________________________________________ 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: neil.2.harrison@bt.com Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 23:05:20 -0000 Lines: 57 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 Nov 13 00:06:05 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] last call on control and ethernet drafts thread-index: AcOpax9h4NxMZZ+JTZeHnNDO2Hw9vAABM6cQ To: , X-OriginalArrivalTime: 12 Nov 2003 23:05:20.0835 (UTC) FILETIME=[722B6130:01C3A971] 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 Scott, Scott Kotrla wrote 12 November 2003 22:13 =20 >=20 > The requirement would actually be to check the Path FCS on=20 > egress before > handing off to the customer and not to pass packets that are=20 > corrupt. I > sent out another email that describes the functionality of various > interfaces in detail, but in short: >=20 > 1. On ingress the customer FCS is checked, and either the packet is > tossed and the appropriate counter is incremented or the packet is > modified with new headers and new service FCS is added after the > customer FCS >=20 > 2. On egress after the packet is returned to its original=20 > condition with > service tag and service FCS removed, the customer FCS is checked, and > either the packet is tossed and the appropriate counter is incremented > or the packet is sent to the customer. >=20 > The ingress counters tell me if the customer was sending corrupt data > and the egress counters tell me if the service provider network > corrupted the packet. >=20 > This seems extremely simple and extremely clean to me. NH=3D> Sounds right to me. =20 > People have said > that this method doesn't tell you where the error is, NH=3D> And nor should it...see next comment. > and I would be > interested to understanding the costs of checking both the=20 > customer and > service FCS at every ingress port in the middle. My guess is=20 > that it is > cost prohibitive and not backwards compatible. =20 >=20 > I think everyone can agree that once you have identified that=20 > there is a > problem in the service provider network, troubleshooting the=20 > problem is > feasible, whereas if you can't determine if a problem is a customer > problem or a service provider problem, troubleshooting a=20 > problem is next > to impossible because there are too many variables. NH=3D> Precisely so. Detection comes before diagnosis.....these are not = the same issues. The former needs to be simple and automatically = operate (in G.805/809 parlance) at the trail termination points. Once = the problem has been detected then one can wheel out more sophisticated = diagnosis tools to delve into the network. IMO this is all just common = sense. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 17:28:01 -0600 Organization: Cisco Systems, inc. Lines: 114 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCF3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Nov 13 00:29:03 2003 Return-path: To: 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 Importance: Normal In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCF3@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> 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 Although a valid point for discussion, the real question should be whether a document in question is useful to the WG or not. If it is, we can discuss the details on the list, as is normal IETF policy. --Tom >-----Original Message----- >From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >Behalf Of Shahram Davari >Sent: Wednesday, November 12, 2003 12:04 PM >To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >as PWE3 WG draft? > > >Right. So only AIS/FDI and Down state are mappable. The down >state of MPLS layer (using CV or periodic ping) is used to >generate AIS on the client layer (i.e., ATM, or FR). Also an >FDI in MPLS layer could be used to generate AIS on client >layer (ATM/FR). > >If the PEs don't support transport of ATM/FR AIS/RDI, then in >theory it is possible (although not architecturally clean) to >use some sort of signaling/message in MPLS network to inform >the egress PE to generate the AIS/RDI on the ATM/FR connections. > >-Shahram > > > >>-----Original Message----- >>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>Sent: Wednesday, November 12, 2003 12:45 PM >>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>WG draft? >> >> >>Hi Shahram.....to be strictly accurate here, in a >>client/server networking I/W case the only server->client OAM >>function mapping that is relevent is FDI (or AIS in old >>currency). RDI stays within the layer/trail it is relevant >>to.....it has no upwards mapping from server->client in a >>'backwards direction' (if you see what I mean) but terminates >>at the trail sink of the return direction (if one exists). >> >>Otherwise I agree with your remarks. >> >>regards, Neil >>> -----Original Message----- >>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> Sent: 12 November 2003 16:49 >>> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>> Subject: RE: [PWE3] Adopt >>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> WG draft? >>> >>> >>> Hi, >>> >>> The only OAM function that is mappable in a network >>> interworking case (e.g., PW) >>> is AIS/RDI and up/down state. Any other type of mapping is >>> not only architecturally wrong, but not required. >>> >>> So I suggest that first we have a debate on the higher level >>> architectural issues >>> and requirements before accepting this draft. >>> >>> Yours, >>> -Shahram >>> >>> >>> >-----Original Message----- >>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>> >Sent: Monday, November 10, 2003 10:47 PM >>> >To: pwe3@ietf.org >>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>as PWE3 WG >>> >draft? >>> > >>> > >>> > >>> > The chairs requested that we take the >>> >matter of adoption of this draft to the >>> >list. Please comment. >>> > >>> > --Tom >>> > >>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >>> ap-03.txt >>> >>> >>> >>> _______________________________________________ >>> 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: Danny McPherson Subject: Re: ITU-T FR draft Date: Wed, 12 Nov 2003 19:43:53 -0700 Lines: 27 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5201860E95@exrad2.ad.rad.co.il> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Jon Peterson X-From: pwe3-admin@ietf.org Thu Nov 13 05:35:06 2003 Return-path: In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201860E95@exrad2.ad.rad.co.il> To: pwe3@ietf.org, Yaakov Stein X-Mailer: Apple Mail (2.606) 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 think this is fine, so long as the IETF document is aligned with the goals and consensus of the WG and the IETF. Do you foresee any potential reasons why this might not be the case? -danny On Nov 11, 2003, at 6:49 PM, Yaakov Stein wrote: > Dear WG chairs and everyone, > > I would like to re-iterate my suggestion that the IETF and > ITU-T SG17 work together to produce a single harmonized > FR draft. > > Since SG17 has adopted the PWE3 terminology, > and there is great overlap in authors of the PWE and ITU drafts, > it should be possible to make the documents precisely identical. > > This has been done before (e.g. Megaco/H.248) > and has the advantage of ensuring that there can be > no minor issues that can later crop up due to different > wording. > > Y(J)S > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 21:54:08 -0800 Lines: 127 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu Nov 13 06:55:08 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 No, I have actually read it. -Shahram >-----Original Message----- >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >Sent: Wednesday, November 12, 2003 4:08 PM >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; >pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > >Sharam, > >Are you commenting on the draft, or are you just guessing what >you might find in the draft if you actually read it? > >Peter > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Wednesday, November 12, 2003 12:04 PM >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >> Subject: RE: [PWE3] Adopt >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> WG draft? >> >> >> Right. So only AIS/FDI and Down state are mappable. The down >> state of MPLS layer (using CV or periodic ping) is used to >> generate AIS on the client layer (i.e., ATM, or FR). Also an >> FDI in MPLS layer could be used to generate AIS on client >> layer (ATM/FR). >> >> If the PEs don't support transport of ATM/FR AIS/RDI, then in >> theory it is possible (although not architecturally clean) to >> use some sort of signaling/message in MPLS network to inform >> the egress PE to generate the AIS/RDI on the ATM/FR connections. >> >> -Shahram >> >> >> >> >-----Original Message----- >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> >Sent: Wednesday, November 12, 2003 12:45 PM >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >> >Subject: RE: [PWE3] Adopt >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> >WG draft? >> > >> > >> >Hi Shahram.....to be strictly accurate here, in a >> >client/server networking I/W case the only server->client OAM >> >function mapping that is relevent is FDI (or AIS in old >> >currency). RDI stays within the layer/trail it is relevant >> >to.....it has no upwards mapping from server->client in a >> >'backwards direction' (if you see what I mean) but terminates >> >at the trail sink of the return direction (if one exists). >> > >> >Otherwise I agree with your remarks. >> > >> >regards, Neil >> >> -----Original Message----- >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >> Sent: 12 November 2003 16:49 >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org >> >> Subject: RE: [PWE3] Adopt >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> >> WG draft? >> >> >> >> >> >> Hi, >> >> >> >> The only OAM function that is mappable in a network >> >> interworking case (e.g., PW) >> >> is AIS/RDI and up/down state. Any other type of mapping is >> >> not only architecturally wrong, but not required. >> >> >> >> So I suggest that first we have a debate on the higher level >> >> architectural issues >> >> and requirements before accepting this draft. >> >> >> >> Yours, >> >> -Shahram >> >> >> >> >> >> >-----Original Message----- >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> >> >Sent: Monday, November 10, 2003 10:47 PM >> >> >To: pwe3@ietf.org >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >> >as PWE3 WG >> >> >draft? >> >> > >> >> > >> >> > >> >> > The chairs requested that we take the >> >> >matter of adoption of this draft to the >> >> >list. Please comment. >> >> > >> >> > --Tom >> >> > >> >> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >> >> ap-03.txt >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 22:03:19 -0800 Lines: 136 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Thu Nov 13 07:04:02 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 A document on OAM Interworking between PW and ATM/FR is needed. Does that mean any draft with this title should be accepted? -Shahram >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Wednesday, November 12, 2003 6:28 PM >To: pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > > > Although a valid point for discussion, the real question >should be whether a document in question is useful to the WG >or not. If it is, we can discuss the details on the list, >as is normal IETF policy. > > --Tom > > >>-----Original Message----- >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>Behalf Of Shahram Davari >>Sent: Wednesday, November 12, 2003 12:04 PM >>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>as PWE3 WG draft? >> >> >>Right. So only AIS/FDI and Down state are mappable. The down >>state of MPLS layer (using CV or periodic ping) is used to >>generate AIS on the client layer (i.e., ATM, or FR). Also an >>FDI in MPLS layer could be used to generate AIS on client >>layer (ATM/FR). >> >>If the PEs don't support transport of ATM/FR AIS/RDI, then in >>theory it is possible (although not architecturally clean) to >>use some sort of signaling/message in MPLS network to inform >>the egress PE to generate the AIS/RDI on the ATM/FR connections. >> >>-Shahram >> >> >> >>>-----Original Message----- >>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>>Sent: Wednesday, November 12, 2003 12:45 PM >>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>>Subject: RE: [PWE3] Adopt >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>WG draft? >>> >>> >>>Hi Shahram.....to be strictly accurate here, in a >>>client/server networking I/W case the only server->client OAM >>>function mapping that is relevent is FDI (or AIS in old >>>currency). RDI stays within the layer/trail it is relevant >>>to.....it has no upwards mapping from server->client in a >>>'backwards direction' (if you see what I mean) but terminates >>>at the trail sink of the return direction (if one exists). >>> >>>Otherwise I agree with your remarks. >>> >>>regards, Neil >>>> -----Original Message----- >>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>>> Sent: 12 November 2003 16:49 >>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>>> Subject: RE: [PWE3] Adopt >>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>> WG draft? >>>> >>>> >>>> Hi, >>>> >>>> The only OAM function that is mappable in a network >>>> interworking case (e.g., PW) >>>> is AIS/RDI and up/down state. Any other type of mapping is >>>> not only architecturally wrong, but not required. >>>> >>>> So I suggest that first we have a debate on the higher level >>>> architectural issues >>>> and requirements before accepting this draft. >>>> >>>> Yours, >>>> -Shahram >>>> >>>> >>>> >-----Original Message----- >>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>> >Sent: Monday, November 10, 2003 10:47 PM >>>> >To: pwe3@ietf.org >>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>as PWE3 WG >>>> >draft? >>>> > >>>> > >>>> > >>>> > The chairs requested that we take the >>>> >matter of adoption of this draft to the >>>> >list. Please comment. >>>> > >>>> > --Tom >>>> > >>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >>>> ap-03.txt >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > >_______________________________________________ >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: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Wed, 12 Nov 2003 22:11:10 -0800 Lines: 157 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Thu Nov 13 07:12:01 2003 Return-path: To: Shahram Davari , "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 Tom, I don't mind accepting the draft as a WG item, as long as major changes in the draft are possible (off course after valid discussions). Yours, Shahram >-----Original Message----- >From: Shahram Davari >Sent: Thursday, November 13, 2003 1:03 AM >To: 'tnadeau@cisco.com'; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > >I think A document on OAM Interworking between PW and ATM/FR is needed. >Does that mean any draft with this title should be accepted? > >-Shahram > >>-----Original Message----- >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>Sent: Wednesday, November 12, 2003 6:28 PM >>To: pwe3@ietf.org >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>WG draft? >> >> >> >> Although a valid point for discussion, the real question >>should be whether a document in question is useful to the WG >>or not. If it is, we can discuss the details on the list, >>as is normal IETF policy. >> >> --Tom >> >> >>>-----Original Message----- >>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>>Behalf Of Shahram Davari >>>Sent: Wednesday, November 12, 2003 12:04 PM >>>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>as PWE3 WG draft? >>> >>> >>>Right. So only AIS/FDI and Down state are mappable. The down >>>state of MPLS layer (using CV or periodic ping) is used to >>>generate AIS on the client layer (i.e., ATM, or FR). Also an >>>FDI in MPLS layer could be used to generate AIS on client >>>layer (ATM/FR). >>> >>>If the PEs don't support transport of ATM/FR AIS/RDI, then in >>>theory it is possible (although not architecturally clean) to >>>use some sort of signaling/message in MPLS network to inform >>>the egress PE to generate the AIS/RDI on the ATM/FR connections. >>> >>>-Shahram >>> >>> >>> >>>>-----Original Message----- >>>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>>>Sent: Wednesday, November 12, 2003 12:45 PM >>>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>>>Subject: RE: [PWE3] Adopt >>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>>WG draft? >>>> >>>> >>>>Hi Shahram.....to be strictly accurate here, in a >>>>client/server networking I/W case the only server->client OAM >>>>function mapping that is relevent is FDI (or AIS in old >>>>currency). RDI stays within the layer/trail it is relevant >>>>to.....it has no upwards mapping from server->client in a >>>>'backwards direction' (if you see what I mean) but terminates >>>>at the trail sink of the return direction (if one exists). >>>> >>>>Otherwise I agree with your remarks. >>>> >>>>regards, Neil >>>>> -----Original Message----- >>>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>>>> Sent: 12 November 2003 16:49 >>>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>>>> Subject: RE: [PWE3] Adopt >>>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>>> WG draft? >>>>> >>>>> >>>>> Hi, >>>>> >>>>> The only OAM function that is mappable in a network >>>>> interworking case (e.g., PW) >>>>> is AIS/RDI and up/down state. Any other type of mapping is >>>>> not only architecturally wrong, but not required. >>>>> >>>>> So I suggest that first we have a debate on the higher level >>>>> architectural issues >>>>> and requirements before accepting this draft. >>>>> >>>>> Yours, >>>>> -Shahram >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>>> >Sent: Monday, November 10, 2003 10:47 PM >>>>> >To: pwe3@ietf.org >>>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>>as PWE3 WG >>>>> >draft? >>>>> > >>>>> > >>>>> > >>>>> > The chairs requested that we take the >>>>> >matter of adoption of this draft to the >>>>> >list. Please comment. >>>>> > >>>>> > --Tom >>>>> > >>>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >>>>> ap-03.txt >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >>_______________________________________________ >>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: Ali Sajassi Subject: RE: last call on control and ethernet drafts Date: Wed, 12 Nov 2003 22:25:23 -0800 Lines: 169 Sender: pwe3-admin@ietf.org References: <20031112213916.82994.qmail@web13505.mail.yahoo.com> <000001c3a96a$17a98900$498032a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Thu Nov 13 07:27:03 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: Scott Kotrla , "'Mark Seery'" In-Reply-To: <000001c3a96a$17a98900$498032a6@acer4wc5zk5t43> References: <20031112213916.82994.qmail@web13505.mail.yahoo.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 Lets first all agree on the requirements and then talk about the solutions to these requirements. I think the requirements are: 1) The service provider network that offers transport services, to provide a reliable transport mechanism similar to transmission facilities (the reliability is dictated by the weakest link in the end-to-end path) 2) The probability of undetectable errors introduced by the service provider network to be in the same ball park as the probability of undetectable errors by the FCS 3) The probability of detectable errors introduced inside the service provider nodes (PE and P nodes) to be in the same ball park as the probability of transmission facilities among these nodes (links between them) 4) There exist an easy way to detect and isolate the errors introduced in the PW path by the PE and P nodes WITHOUT service interruption 5) The P and PE nodes have the capability of detecting errors that may have introduced inadvertently inside them (between ingress and egress ports) 6) The P and PE nodes discard the packets detected with errors (both over their interfaces and between their interfaces) and keep stats for them If I missed any requirements, please let me know - but just the requirements and not the possible solutions for these requirements !!! Now as I have been trying to explain in my previous emails, I think we can meet all these requirements by using a single FCS throughout the PW path (over PE and P nodes) with reliable platforms (platforms that can reliably transfer packets through them and detect errors that may occur within them). Regarding single FCS either IEEE mechanisms or derivative of them can be used. Now if it is still not clear how we can achieve this via a single FCS, then we can go over it again. BTW, the requirements (5) and (6) doesn't mean we need to replace the existing P or PE nodes, because most well-designed platforms already have such capability Now, if we look at the solution with two FCS (both customer and service FCS) and the error detection within the platforms (e.g., P nodes) is not addressed properly, then it would not meet requirements 4, 5, and 6. And thus detecting errors at the customer CE or egress port of the egress PE, doesn't buy you anything because as I said isolation of it becomes an issue. Scott mention that isolation can be done by simply doing "loopbacks" but that is NOT viable because: a) To get any reasonable sampling period to detect the error that we are talking about, you need to run intrusive loopback which would interrupt services to your customers b) The path through PE or P nodes goes through several/many modules (active or passive) and you cannot perform loopback on every one of them. So if these error detection mechanisms are not already built-in within the platforms, it would be very difficult to isolate the error !! and if these error detection mechanisms are already built-in such that it reduces the probability of the undetected errors into the noise, then what do we gain by having this double FCS !! Another point that I mention earlier was we need to address this issue properly such that it works for all services (EPL, EVPL, EPLAN, EVPLAN) and not just EPL. One reply was for the EVPL, we can have the same VLANs for both ends. This like saying I will offer a frame relay service with DLCIs at both end to be the same !!! Are your customers going to be happy with this restriction that limits their provisioning !! Final point, with respect to 802.1ad, the basic premise is that to have maximum compatibility with existing bridges, minimum disruption with the existing defined IEEE standards, keep the cost of the provider bridges low, and yet satisfy the requirements. So unless a new mechanism buys you something of value, it would be difficult to convince the group. At the end, I just like to say that I still don't see the value in double FCS mechanism. If I can convince myself of its value, then I can convince others :-) -Ali At 03:12 PM 11/12/2003 -0700, Scott Kotrla wrote: >The requirement would actually be to check the Path FCS on egress before >handing off to the customer and not to pass packets that are corrupt. I >sent out another email that describes the functionality of various >interfaces in detail, but in short: > >1. On ingress the customer FCS is checked, and either the packet is >tossed and the appropriate counter is incremented or the packet is >modified with new headers and new service FCS is added after the >customer FCS > >2. On egress after the packet is returned to its original condition with >service tag and service FCS removed, the customer FCS is checked, and >either the packet is tossed and the appropriate counter is incremented >or the packet is sent to the customer. > >The ingress counters tell me if the customer was sending corrupt data >and the egress counters tell me if the service provider network >corrupted the packet. > >This seems extremely simple and extremely clean to me. People have said >that this method doesn't tell you where the error is, and I would be >interested to understanding the costs of checking both the customer and >service FCS at every ingress port in the middle. My guess is that it is >cost prohibitive and not backwards compatible. > >I think everyone can agree that once you have identified that there is a >problem in the service provider network, troubleshooting the problem is >feasible, whereas if you can't determine if a problem is a customer >problem or a service provider problem, troubleshooting a problem is next >to impossible because there are too many variables. > >Thanks, > >Scott > >-----Original Message----- >From: Mark Seery [mailto:m_seery@yahoo.com] >Sent: Wednesday, November 12, 2003 2:39 PM >To: Scott Kotrla >Cc: pwe3@ietf.org; stds-802-1@ieee.org >Subject: RE: [PWE3] last call on control and ethernet drafts > >(I may have had HTML reenabled previously by mistake - my apologies if I >did). > >" Scott Kotrla wrote: > >Mark, > >I think we are dealing with all of the issues that you mentioned. While >you can do a lot of things on a small scale, service providers can't put >10000s of devices into a network and afford to have gaping holes in >their abilities to detect faults. << > > >So I think the question on some people's minds (mine included, I think >Ali also >alluded to this) is whether e2e reuse of FCS helps the SP detect fault, >or >merely enables the subscriber to detect fault. I assume both are goals? >I also >assume that you prefer not to enable the subscriber to do so unless you >can as >well ;-) Once again my clumsy articulation was the difference between >payload >integrity and FCS integrity. > >" 3. They haven't looked forward to a time in the future where >the >switching protocols become part of the transmission network " > >I don't know what assumptions the WG makes WRT this issue (would be >interested >to hear an opinion from the chairs), what assumptions 802 makes, or what >assumptions people in general make. But I suspect this is a salient >point, and >the subconscious long-term pretext/foundation of challenges we have in >people >from different backgrounds holding hands across the aisle. > > > > >_______________________________________________ >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: mark seery Subject: Re: last call on control and ethernet drafts Date: Thu, 13 Nov 2003 00:16:44 -0800 Lines: 57 Sender: pwe3-admin@ietf.org References: <20031112213916.82994.qmail@web13505.mail.yahoo.com> <4.3.2.7.2.20031112211703.02602de8@airborne.cisco.com> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Kotrla , pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Thu Nov 13 09:18:09 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Ali Sajassi In-Reply-To: <4.3.2.7.2.20031112211703.02602de8@airborne.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 Ali, Sorry to see this is testing your endurance threshold (as measured by double !s), and anything I am doing to contribute to that. I understand your frustration at people throwing solutions at you and not requirements - this is obviously an oft-expressed angst by engineers in many different contexts. However, I think it is natural for experienced operators to offer their opinions on a solution, and can help sometimes to flush out the issues. I do agree that to deviate to far from a focus on the requirements is a dangerous path to travel in the long-term, so good to bring it back to that, but given the general scarcity of input from carriers, a little leeway might be constructive. As I stated in my last email, I do see how a single FCS can work, based on the draft from andy et el. I have seen you consistently suggest that solving the problems for all modes is desired - and I agree. I have seen others say this is not achieveable. Unfortunately I missed your proposal on how it is achieveable, and the technical critique from others on how it is not - I'll look back at the april/september entrails to re-educate myself. While I agree that solving for all modes is best, and ultimately the test of whether PW is a good layer - or at the least a consistent layer, if people seem to be focused heavily on the EPL case, that might be suggestive of where their interest lay. Personally, I think stating a requirement such as "like a transmission facility" is a good starting point, but ultimately does provide engineers anything constructive to design towards, it would be nice if someone could turn that general requirement in to something more specific, then all your comments like "probability of undetectable errors" would come more into focus. I am not sure I agree with your observations about loopbacks. It is not clear to me that it is impossible to construct non-intrusive tests with sufficient samples. I obviously missed that explanation as well. In addition, there is a distinction between the process of detecting an error and the process of diagnosing one - which is a point that has been made by others. I missed that distinction in your comments. I am not sure I understand your comments about IEEE 802.1ad compatibility. Even though I can see how one FCS might be sufficient, if a PW used two, I am not sure how this creates a compatibility problem as I don't forsee an "existing" bridge being in the middle of a PW. I do think the issue about cost is something I would have preferred the carrier representatives to have picked up on and commented on - but they probably can not give an intelligent response without a meaningful estimate of cost difference. If their answer is its your job to get the costs in line, we aint doing it with this functionality, well then I suggest that should probably spark a set of offline discussions. And the cost discussion is obviously not just pertinent to the double FCS case, the zero FCS case clearly provides for an interesting set of discussions between incumbent vendors and customers (one that is beyond me how I personally would gain by promoting, but it is clear to me how it is a worthy discussion for some set of agents in the value chain to have). From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 09:02:16 -0000 Lines: 158 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 Thu Nov 13 10:03:14 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? thread-index: AcOpq/tcBBHWmN3eTqeFTi7SzJWUpwAH90hw To: , , X-OriginalArrivalTime: 13 Nov 2003 09:02:17.0305 (UTC) FILETIME=[D672FC90:01C3A9C4] 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 As Dave Allan pointed out earlier, there is a document on ATM and MPLS = peer OAM I/W....it is Y.1712. Its simple and complete. This should not = be ignored. regards, Neil > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 13 November 2003 06:03 > To: 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? >=20 >=20 > I think A document on OAM Interworking between PW and ATM/FR=20 > is needed. > Does that mean any draft with this title should be accepted? >=20 > -Shahram >=20 > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Wednesday, November 12, 2003 6:28 PM > >To: pwe3@ietf.org > >Subject: RE: [PWE3] Adopt=20 > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > > > > Although a valid point for discussion, the real question=20 > >should be whether a document in question is useful to the WG=20 > >or not. If it is, we can discuss the details on the list, > >as is normal IETF policy. =20 > > > > --Tom > > > > > >>-----Original Message----- > >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On=20 > >>Behalf Of Shahram Davari > >>Sent: Wednesday, November 12, 2003 12:04 PM > >>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >>as PWE3 WG draft? > >> > >> > >>Right. So only AIS/FDI and Down state are mappable. The down=20 > >>state of MPLS layer (using CV or periodic ping) is used to=20 > >>generate AIS on the client layer (i.e., ATM, or FR). Also an=20 > >>FDI in MPLS layer could be used to generate AIS on client=20 > >>layer (ATM/FR). > >> > >>If the PEs don't support transport of ATM/FR AIS/RDI, then in=20 > >>theory it is possible (although not architecturally clean) to=20 > >>use some sort of signaling/message in MPLS network to inform=20 > >>the egress PE to generate the AIS/RDI on the ATM/FR connections. > >> > >>-Shahram > >> > >> > >> > >>>-----Original Message----- > >>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >>>Sent: Wednesday, November 12, 2003 12:45 PM > >>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >>>Subject: RE: [PWE3] Adopt=20 > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>>WG draft? > >>> > >>> > >>>Hi Shahram.....to be strictly accurate here, in a=20 > >>>client/server networking I/W case the only server->client OAM=20 > >>>function mapping that is relevent is FDI (or AIS in old=20 > >>>currency). RDI stays within the layer/trail it is relevant=20 > >>>to.....it has no upwards mapping from server->client in a=20 > >>>'backwards direction' (if you see what I mean) but terminates=20 > >>>at the trail sink of the return direction (if one exists). > >>> > >>>Otherwise I agree with your remarks. =20 > >>> > >>>regards, Neil > >>>> -----Original Message----- > >>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >>>> Sent: 12 November 2003 16:49 > >>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >>>> Subject: RE: [PWE3] Adopt=20 > >>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>>> WG draft? > >>>>=20 > >>>>=20 > >>>> Hi, > >>>>=20 > >>>> The only OAM function that is mappable in a network=20 > >>>> interworking case (e.g., PW) > >>>> is AIS/RDI and up/down state. Any other type of mapping is=20 > >>>> not only architecturally wrong, but not required. > >>>>=20 > >>>> So I suggest that first we have a debate on the higher level=20 > >>>> architectural issues > >>>> and requirements before accepting this draft. > >>>>=20 > >>>> Yours, > >>>> -Shahram > >>>>=20 > >>>>=20 > >>>> >-----Original Message----- > >>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>> >Sent: Monday, November 10, 2003 10:47 PM > >>>> >To: pwe3@ietf.org > >>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >>>as PWE3 WG > >>>> >draft? > >>>> > > >>>> > > >>>> > > >>>> > The chairs requested that we take the > >>>> >matter of adoption of this draft to the > >>>> >list. Please comment. > >>>> > > >>>> > --Tom > >>>> > > >>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > >>>> ap-03.txt > >>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> pwe3 mailing list > >>>> pwe3@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>=20 > >>>> _______________________________________________ > >>>> pwe3 mailing list > >>>> pwe3@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>=20 > >>> > >> > >>_______________________________________________ > >>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 > > >=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: neil.2.harrison@bt.com Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 09:02:19 -0000 Lines: 202 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 Thu Nov 13 10:03:15 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? thread-index: AcOprSJoU+gZ+HCQR0qaHLx6dDhmSAAIK+XQ To: , , X-OriginalArrivalTime: 13 Nov 2003 09:02:20.0105 (UTC) FILETIME=[D81E3B90:01C3A9C4] 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 agree Shahram. But, speaking as an operator, we need to see defects = specified in terms of automatic detection/handling, ie entry/exit = criteria and consequent actions. AFAIK these are not specified in any = IETF documentation. The only place these are specified for MPLS is in = Y.1711. Admittedly this is only for constructs that are architecturally = allowed in the co-ps mode. When the allowed arch of this mode is = violated (by mp2p and PHP say) then the OAM problems this causes will = require other techniques, eg LSP-Ping. However, since XoverMPLS *must* = always have p2p LSPs above the lower mp2p constructs (as this is the = only way to recover from the merging) then one can run the simple Y.1711 = OAM flows on these top LSPs. {Aside - IP is cnls and therefore always = uses *multiplexing and not merging*....so these OAM problems do not = exist in IP.} If the p2p LSPs show a problem then check out the = SDH/Sonet trails..if these show clear then wheel out the complex = diagostics tools like LSP-Ping. This seems a fine solution to me and = I'd like to hear what is wrong with it. Unless Y.1711 etc are properly taken into account I hardly think this WG = can be considered to be doing a good job.=20 BTW - PWs will also require similar defect detction/handling = considerations as the adaptation process here contains 'active' = functions like Seq Nos. regards, Neil > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 13 November 2003 06:11 > To: Shahram Davari; 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? >=20 >=20 > Tom, >=20 > I don't mind accepting the draft as a WG item, as long as=20 > major changes in the draft are possible (off course after=20 > valid discussions). >=20 > Yours, > Shahram >=20 > >-----Original Message----- > >From: Shahram Davari=20 > >Sent: Thursday, November 13, 2003 1:03 AM > >To: 'tnadeau@cisco.com'; pwe3@ietf.org > >Subject: RE: [PWE3] Adopt=20 > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > >I think A document on OAM Interworking between PW and ATM/FR=20 > is needed. > >Does that mean any draft with this title should be accepted? > > > >-Shahram > > > >>-----Original Message----- > >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>Sent: Wednesday, November 12, 2003 6:28 PM > >>To: pwe3@ietf.org > >>Subject: RE: [PWE3] Adopt=20 > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>WG draft? > >> > >> > >> > >> Although a valid point for discussion, the real question=20 > >>should be whether a document in question is useful to the WG=20 > >>or not. If it is, we can discuss the details on the list, > >>as is normal IETF policy. =20 > >> > >> --Tom > >> > >> > >>>-----Original Message----- > >>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On=20 > >>>Behalf Of Shahram Davari > >>>Sent: Wednesday, November 12, 2003 12:04 PM > >>>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >>>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >>>as PWE3 WG draft? > >>> > >>> > >>>Right. So only AIS/FDI and Down state are mappable. The down=20 > >>>state of MPLS layer (using CV or periodic ping) is used to=20 > >>>generate AIS on the client layer (i.e., ATM, or FR). Also an=20 > >>>FDI in MPLS layer could be used to generate AIS on client=20 > >>>layer (ATM/FR). > >>> > >>>If the PEs don't support transport of ATM/FR AIS/RDI, then in=20 > >>>theory it is possible (although not architecturally clean) to=20 > >>>use some sort of signaling/message in MPLS network to inform=20 > >>>the egress PE to generate the AIS/RDI on the ATM/FR connections. > >>> > >>>-Shahram > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >>>>Sent: Wednesday, November 12, 2003 12:45 PM > >>>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >>>>Subject: RE: [PWE3] Adopt=20 > >>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>>>WG draft? > >>>> > >>>> > >>>>Hi Shahram.....to be strictly accurate here, in a=20 > >>>>client/server networking I/W case the only server->client OAM=20 > >>>>function mapping that is relevent is FDI (or AIS in old=20 > >>>>currency). RDI stays within the layer/trail it is relevant=20 > >>>>to.....it has no upwards mapping from server->client in a=20 > >>>>'backwards direction' (if you see what I mean) but terminates=20 > >>>>at the trail sink of the return direction (if one exists). > >>>> > >>>>Otherwise I agree with your remarks. =20 > >>>> > >>>>regards, Neil > >>>>> -----Original Message----- > >>>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >>>>> Sent: 12 November 2003 16:49 > >>>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >>>>> Subject: RE: [PWE3] Adopt=20 > >>>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>>>> WG draft? > >>>>>=20 > >>>>>=20 > >>>>> Hi, > >>>>>=20 > >>>>> The only OAM function that is mappable in a network=20 > >>>>> interworking case (e.g., PW) > >>>>> is AIS/RDI and up/down state. Any other type of mapping is=20 > >>>>> not only architecturally wrong, but not required. > >>>>>=20 > >>>>> So I suggest that first we have a debate on the higher level=20 > >>>>> architectural issues > >>>>> and requirements before accepting this draft. > >>>>>=20 > >>>>> Yours, > >>>>> -Shahram > >>>>>=20 > >>>>>=20 > >>>>> >-----Original Message----- > >>>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>>> >Sent: Monday, November 10, 2003 10:47 PM > >>>>> >To: pwe3@ietf.org > >>>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >>>>as PWE3 WG > >>>>> >draft? > >>>>> > > >>>>> > > >>>>> > > >>>>> > The chairs requested that we take the > >>>>> >matter of adoption of this draft to the > >>>>> >list. Please comment. > >>>>> > > >>>>> > --Tom > >>>>> > > >>>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > >>>>> ap-03.txt > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> pwe3 mailing list > >>>>> pwe3@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>>=20 > >>>>> _______________________________________________ > >>>>> pwe3 mailing list > >>>>> pwe3@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>>=20 > >>>> > >>> > >>>_______________________________________________ > >>>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 > > >=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: "Thomas D. Nadeau" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 09:12:49 -0500 Organization: Cisco Systems, inc. Lines: 151 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCFA@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Nov 13 15:14:07 2003 Return-path: To: "'Shahram Davari'" , 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 Importance: Normal In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCFA@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> 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 Did you have a different one in mind? :P I suppose we can play semantic games all day, which seems to be your m.o., but I would rather get some work done in this area if you don't mind. Several operators and vendors have joined in supporting the draft so it seems that there is a definite interest in doing this work, which you even admit to below. It seems to me that this draft is a good start for this work. --Tom >I think A document on OAM Interworking between PW and ATM/FR is needed. >Does that mean any draft with this title should be accepted? > >-Shahram > >>-----Original Message----- >>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>Sent: Wednesday, November 12, 2003 6:28 PM >>To: pwe3@ietf.org >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>WG draft? >> >> >> >> Although a valid point for discussion, the real question >>should be whether a document in question is useful to the WG >>or not. If it is, we can discuss the details on the list, >>as is normal IETF policy. >> >> --Tom >> >> >>>-----Original Message----- >>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>>Behalf Of Shahram Davari >>>Sent: Wednesday, November 12, 2003 12:04 PM >>>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>as PWE3 WG draft? >>> >>> >>>Right. So only AIS/FDI and Down state are mappable. The down >>>state of MPLS layer (using CV or periodic ping) is used to >>>generate AIS on the client layer (i.e., ATM, or FR). Also an >>>FDI in MPLS layer could be used to generate AIS on client >>>layer (ATM/FR). >>> >>>If the PEs don't support transport of ATM/FR AIS/RDI, then in >>>theory it is possible (although not architecturally clean) to >>>use some sort of signaling/message in MPLS network to inform >>>the egress PE to generate the AIS/RDI on the ATM/FR connections. >>> >>>-Shahram >>> >>> >>> >>>>-----Original Message----- >>>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>>>Sent: Wednesday, November 12, 2003 12:45 PM >>>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>>>Subject: RE: [PWE3] Adopt >>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>>WG draft? >>>> >>>> >>>>Hi Shahram.....to be strictly accurate here, in a >>>>client/server networking I/W case the only server->client OAM >>>>function mapping that is relevent is FDI (or AIS in old >>>>currency). RDI stays within the layer/trail it is relevant >>>>to.....it has no upwards mapping from server->client in a >>>>'backwards direction' (if you see what I mean) but terminates >>>>at the trail sink of the return direction (if one exists). >>>> >>>>Otherwise I agree with your remarks. >>>> >>>>regards, Neil >>>>> -----Original Message----- >>>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>>>> Sent: 12 November 2003 16:49 >>>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>>>> Subject: RE: [PWE3] Adopt >>>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>>> WG draft? >>>>> >>>>> >>>>> Hi, >>>>> >>>>> The only OAM function that is mappable in a network >>>>> interworking case (e.g., PW) >>>>> is AIS/RDI and up/down state. Any other type of mapping is >>>>> not only architecturally wrong, but not required. >>>>> >>>>> So I suggest that first we have a debate on the higher level >>>>> architectural issues >>>>> and requirements before accepting this draft. >>>>> >>>>> Yours, >>>>> -Shahram >>>>> >>>>> >>>>> >-----Original Message----- >>>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>>> >Sent: Monday, November 10, 2003 10:47 PM >>>>> >To: pwe3@ietf.org >>>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>>as PWE3 WG >>>>> >draft? >>>>> > >>>>> > >>>>> > >>>>> > The chairs requested that we take the >>>>> >matter of adoption of this draft to the >>>>> >list. Please comment. >>>>> > >>>>> > --Tom >>>>> > >>>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >>>>> ap-03.txt >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >>_______________________________________________ >>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 Kotrla Subject: RE: last call on control and ethernet drafts Date: Thu, 13 Nov 2003 07:08:45 -0700 Lines: 140 Sender: pwe3-admin@ietf.org References: <3FB33DEC.8060309@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Thu Nov 13 15:17:06 2003 Return-path: In-reply-to: <3FB33DEC.8060309@yahoo.com> To: m_seery@yahoo.com, "'Ali Sajassi'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Let me start by clarifying something that may be leading to some confusion. MCI is pushing for an end-to-end FCS in both 802.1ad and in Pseudowires. Think of stacked VLANs spokes running across a network of switches into a Pseudowire Core connected via a network of routers. I think we have agreed in PWE3 that carrying an end-to-end FCS should be a service provider option and the drafts will be modified accordingly. I have now moved on to pushing for the same option in 802.1ad. Since there were still discussions going on in PWE3 when I started posting to the 802.1 listserv earlier this week, I started copying 802.1 on my PWE3 replies since my response were valid to both groups. I completely agree that it is theoretically possible to construct switches that are not anymore likely to corrupt packets than a CRC32 is to not catch a corrupt packet. It is also possible to build a network that can never be misconfigured and that never has any problems. This argument could be used to wish away all OAM tools. If one builds the perfect network, a lot of things become a lot easier and a lot of tools would never be used. Being able to detect errors in switches is a requirement from MCI. However, MCI is not convinced that every piece of gear ever deployed in the network will always meet those requirements, even if the equipment providers promise that they do. Equipment has always had bugs and it will always have bugs. Even if the equipment design makes unknown packet corruption highly improbable, the reality of some implementations will be holes that permit unknown packet corruption. Convincing me that no equipment provider that claims to meet the requirement of unknown packet corruption could ever get a box into the network that doesn't meet that requirement will be very tough. There are too many variables. I completely agree with service provider rights to save 4 bytes and not turn the feature on, but I stand by my assertion that any service provider who understands the risks will be willing to sacrifice 4 bytes. Regarding hardware costs, 802.1ad interfaces are likely going to require new hardware. I am highly suspicious of the assertion that stacking 4 bytes on ingress and doing an extra CRC check on egress on new 802.1ad hardware will have any significant impact on cost. I agree that adding this feature on existing hardware might be cost prohibitive in some cases. As far as the importance of detecting end-to-end errors versus diagnosing where the errors are happening, I think I have stated this several times already. If I don't know that my network is running clean, how do I troubleshoot a customer call? I have to guarantee and be able to demonstrate beyond a reasonable doubt that my network is clean, and trying to walk the customer through the internal workings of a dozen boxes is much more difficult and less convincing than showing them egress FCS error counters. If I know there is a problem, I have a lot of tools at my disposal, depending on the seriousness of the problem. First of all, I can root cause my FCS errors to figure out which boxes/interfaces all affected customer traffic are going through. If enough customer packets are being corrupted that the service is unusable, I can do intrusive monitoring and loopbacks. If service is not being impacted so severely, I can diagnose the problem during a maintenance window. If the equipment is reliable as it should be, I shouldn't be doing this often anyway. Thanks, Scott -----Original Message----- From: mark seery [mailto:m_seery@yahoo.com] Sent: Thursday, November 13, 2003 1:17 AM To: Ali Sajassi Cc: Scott Kotrla; pwe3@ietf.org; stds-802-1@ieee.org Subject: Re: [PWE3] last call on control and ethernet drafts Ali, Sorry to see this is testing your endurance threshold (as measured by double !s), and anything I am doing to contribute to that. I understand your frustration at people throwing solutions at you and not requirements - this is obviously an oft-expressed angst by engineers in many different contexts. However, I think it is natural for experienced operators to offer their opinions on a solution, and can help sometimes to flush out the issues. I do agree that to deviate to far from a focus on the requirements is a dangerous path to travel in the long-term, so good to bring it back to that, but given the general scarcity of input from carriers, a little leeway might be constructive. As I stated in my last email, I do see how a single FCS can work, based on the draft from andy et el. I have seen you consistently suggest that solving the problems for all modes is desired - and I agree. I have seen others say this is not achieveable. Unfortunately I missed your proposal on how it is achieveable, and the technical critique from others on how it is not - I'll look back at the april/september entrails to re-educate myself. While I agree that solving for all modes is best, and ultimately the test of whether PW is a good layer - or at the least a consistent layer, if people seem to be focused heavily on the EPL case, that might be suggestive of where their interest lay. Personally, I think stating a requirement such as "like a transmission facility" is a good starting point, but ultimately does provide engineers anything constructive to design towards, it would be nice if someone could turn that general requirement in to something more specific, then all your comments like "probability of undetectable errors" would come more into focus. I am not sure I agree with your observations about loopbacks. It is not clear to me that it is impossible to construct non-intrusive tests with sufficient samples. I obviously missed that explanation as well. In addition, there is a distinction between the process of detecting an error and the process of diagnosing one - which is a point that has been made by others. I missed that distinction in your comments. I am not sure I understand your comments about IEEE 802.1ad compatibility. Even though I can see how one FCS might be sufficient, if a PW used two, I am not sure how this creates a compatibility problem as I don't forsee an "existing" bridge being in the middle of a PW. I do think the issue about cost is something I would have preferred the carrier representatives to have picked up on and commented on - but they probably can not give an intelligent response without a meaningful estimate of cost difference. If their answer is its your job to get the costs in line, we aint doing it with this functionality, well then I suggest that should probably spark a set of offline discussions. And the cost discussion is obviously not just pertinent to the double FCS case, the zero FCS case clearly provides for an interesting set of discussions between incumbent vendors and customers (one that is beyond me how I personally would gain by promoting, but it is clear to me how it is a worthy discussion for some set of agents in the value chain to have). From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 10:07:56 -0500 Lines: 144 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Thu Nov 13 16:23:09 2003 Return-path: To: "'Shahram Davari'" , "Busschbach, Peter B (Peter)" , "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 you read the draft, you must have noticed that it discusses predominantly how to map up and down states to FDI and RDI. Therefore, I don't understand what prompted your first email. Could you explain more explicitly what you think is wrong about the draft? Thanks, Peter > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Wednesday, November 12, 2003 11:54 PM > To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; > tnadeau@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? > > > No, I have actually read it. > > -Shahram > > >-----Original Message----- > >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > >Sent: Wednesday, November 12, 2003 4:08 PM > >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; > >pwe3@ietf.org > >Subject: RE: [PWE3] Adopt > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > >Sharam, > > > >Are you commenting on the draft, or are you just guessing what > >you might find in the draft if you actually read it? > > > >Peter > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: Wednesday, November 12, 2003 12:04 PM > >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >> Subject: RE: [PWE3] Adopt > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> WG draft? > >> > >> > >> Right. So only AIS/FDI and Down state are mappable. The down > >> state of MPLS layer (using CV or periodic ping) is used to > >> generate AIS on the client layer (i.e., ATM, or FR). Also an > >> FDI in MPLS layer could be used to generate AIS on client > >> layer (ATM/FR). > >> > >> If the PEs don't support transport of ATM/FR AIS/RDI, then in > >> theory it is possible (although not architecturally clean) to > >> use some sort of signaling/message in MPLS network to inform > >> the egress PE to generate the AIS/RDI on the ATM/FR connections. > >> > >> -Shahram > >> > >> > >> > >> >-----Original Message----- > >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >> >Sent: Wednesday, November 12, 2003 12:45 PM > >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >> >Subject: RE: [PWE3] Adopt > >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >WG draft? > >> > > >> > > >> >Hi Shahram.....to be strictly accurate here, in a > >> >client/server networking I/W case the only server->client OAM > >> >function mapping that is relevent is FDI (or AIS in old > >> >currency). RDI stays within the layer/trail it is relevant > >> >to.....it has no upwards mapping from server->client in a > >> >'backwards direction' (if you see what I mean) but terminates > >> >at the trail sink of the return direction (if one exists). > >> > > >> >Otherwise I agree with your remarks. > >> > > >> >regards, Neil > >> >> -----Original Message----- > >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >> Sent: 12 November 2003 16:49 > >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >> >> Subject: RE: [PWE3] Adopt > >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> WG draft? > >> >> > >> >> > >> >> Hi, > >> >> > >> >> The only OAM function that is mappable in a network > >> >> interworking case (e.g., PW) > >> >> is AIS/RDI and up/down state. Any other type of mapping is > >> >> not only architecturally wrong, but not required. > >> >> > >> >> So I suggest that first we have a debate on the higher level > >> >> architectural issues > >> >> and requirements before accepting this draft. > >> >> > >> >> Yours, > >> >> -Shahram > >> >> > >> >> > >> >> >-----Original Message----- > >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> >> >Sent: Monday, November 10, 2003 10:47 PM > >> >> >To: pwe3@ietf.org > >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt > >> >as PWE3 WG > >> >> >draft? > >> >> > > >> >> > > >> >> > > >> >> > The chairs requested that we take the > >> >> >matter of adoption of this draft to the > >> >> >list. Please comment. > >> >> > > >> >> > --Tom > >> >> > > >> >> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > >> >> ap-03.txt > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 07:31:27 -0800 Lines: 170 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain X-From: pwe3-admin@ietf.org Thu Nov 13 16:33:05 2003 Return-path: To: "'tnadeau@cisco.com'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 I said, I don't mind to start with this draft, but my experience tells me it is pretty difficult to substantially change a draft, while it is accepted as a WG draft. -Shahram >-----Original Message----- >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >Sent: Thursday, November 13, 2003 9:13 AM >To: Shahram Davari; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > > > Did you have a different one in mind? :P I suppose >we can play semantic games all day, which seems to be >your m.o., but I would rather get some work done in >this area if you don't mind. Several operators and vendors >have joined in supporting the draft so it seems that there >is a definite interest in doing this work, which you even admit >to below. It seems to me that this draft is a good start for >this work. > > --Tom > > > >>I think A document on OAM Interworking between PW and ATM/FR >is needed. >>Does that mean any draft with this title should be accepted? >> >>-Shahram >> >>>-----Original Message----- >>>From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>Sent: Wednesday, November 12, 2003 6:28 PM >>>To: pwe3@ietf.org >>>Subject: RE: [PWE3] Adopt >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>WG draft? >>> >>> >>> >>> Although a valid point for discussion, the real question >>>should be whether a document in question is useful to the WG >>>or not. If it is, we can discuss the details on the list, >>>as is normal IETF policy. >>> >>> --Tom >>> >>> >>>>-----Original Message----- >>>>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >>>>Behalf Of Shahram Davari >>>>Sent: Wednesday, November 12, 2003 12:04 PM >>>>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>>>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>>as PWE3 WG draft? >>>> >>>> >>>>Right. So only AIS/FDI and Down state are mappable. The down >>>>state of MPLS layer (using CV or periodic ping) is used to >>>>generate AIS on the client layer (i.e., ATM, or FR). Also an >>>>FDI in MPLS layer could be used to generate AIS on client >>>>layer (ATM/FR). >>>> >>>>If the PEs don't support transport of ATM/FR AIS/RDI, then in >>>>theory it is possible (although not architecturally clean) to >>>>use some sort of signaling/message in MPLS network to inform >>>>the egress PE to generate the AIS/RDI on the ATM/FR connections. >>>> >>>>-Shahram >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>>>>Sent: Wednesday, November 12, 2003 12:45 PM >>>>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>>>>Subject: RE: [PWE3] Adopt >>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>>>WG draft? >>>>> >>>>> >>>>>Hi Shahram.....to be strictly accurate here, in a >>>>>client/server networking I/W case the only server->client OAM >>>>>function mapping that is relevent is FDI (or AIS in old >>>>>currency). RDI stays within the layer/trail it is relevant >>>>>to.....it has no upwards mapping from server->client in a >>>>>'backwards direction' (if you see what I mean) but terminates >>>>>at the trail sink of the return direction (if one exists). >>>>> >>>>>Otherwise I agree with your remarks. >>>>> >>>>>regards, Neil >>>>>> -----Original Message----- >>>>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>>>>> Sent: 12 November 2003 16:49 >>>>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>>>>> Subject: RE: [PWE3] Adopt >>>>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>>>>> WG draft? >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> The only OAM function that is mappable in a network >>>>>> interworking case (e.g., PW) >>>>>> is AIS/RDI and up/down state. Any other type of mapping is >>>>>> not only architecturally wrong, but not required. >>>>>> >>>>>> So I suggest that first we have a debate on the higher level >>>>>> architectural issues >>>>>> and requirements before accepting this draft. >>>>>> >>>>>> Yours, >>>>>> -Shahram >>>>>> >>>>>> >>>>>> >-----Original Message----- >>>>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>>>>> >Sent: Monday, November 10, 2003 10:47 PM >>>>>> >To: pwe3@ietf.org >>>>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>>>>as PWE3 WG >>>>>> >draft? >>>>>> > >>>>>> > >>>>>> > >>>>>> > The chairs requested that we take the >>>>>> >matter of adoption of this draft to the >>>>>> >list. Please comment. >>>>>> > >>>>>> > --Tom >>>>>> > >>>>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m >>>>>> ap-03.txt >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> >>> >>> >>>_______________________________________________ >>>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: "Matt Squire" Subject: RE: last call on control and ethernet drafts Date: Thu, 13 Nov 2003 10:45:09 -0500 Lines: 31 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 Nov 13 16:46:05 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] last call on control and ethernet drafts Thread-Index: AcOp8N2U6WSgRBl9SMigT2Mt2TSphwACs2Ew To: "Scott Kotrla" , , "Ali Sajassi" 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 > Regarding hardware costs, 802.1ad interfaces are likely going=20 > to require > new hardware. I am highly suspicious of the assertion that stacking 4 > bytes on ingress and doing an extra CRC check on egress on new 802.1ad > hardware will have any significant impact on cost. I agree=20 > that adding > this feature on existing hardware might be cost prohibitive in some > cases. > I haven't really looked into detailed cost derivatives for such a = feature, however it does change the architectural model pretty = significantly. In all of the products on which I've worked in my life, = there has not been a way to do FCS checking on egress. The MAC performs = an FCS check on ingress and counts the FCS errors, often discarding the = errored frame for you (unless you configure the MAC to pass errored = frames).=20 On egress, the FCS may be recalculated depending if VLAN tags or = priority bits have been inserted/deleted/modified. In many cases, the = MAC or some other hardware computes the FCS for you and appends it. =20 =20 An architecture where FCS is checked at egress is a non-trivial = modification to how things work today. Not saying its not possible, but = the MAC, which does this for many people today, couldn't be used in the = way its designed and currently implemneted. =20 - Matt =20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 07:55:19 -0800 Lines: 178 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu Nov 13 16:56:05 2003 Return-path: To: "'Busschbach, Peter B (Peter)'" , "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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, There are 2 major things wrong with this draft: 1) The draft advocates extending ATM/FR across the PW and doing ATM-FR Service interworking at only one PE. Meaning that interworking between ATM/FR and MPLS (aka PW) is Network interworking, and interworking between ATM-FR is Service interworking. But it asks for ATM-PW-FR Service interworking at both PEs. This is architecturally wrong, because at one of the PEs you are doing Network interworking (between ATM/FR and PW) for the data-plane but doing Service interworking (between ATM/FR and PW) for the Management plane. 2) The draft advocates the mapping of CC and loopback between ATM/FR and MPLS in sections 4.7 and 4.8. Again, this is fundamentally wrong, since only the states and AIS needs mapping and not the CC or LB messages. Hope that answers yours question. Yours, -Shahram >-----Original Message----- >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >Sent: Thursday, November 13, 2003 10:08 AM >To: Shahram Davari; Busschbach, Peter B (Peter); >'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > >If you read the draft, you must have noticed that it discusses >predominantly how to map up and down states to FDI and RDI. >Therefore, I don't understand what prompted your first email. >Could you explain more explicitly what you think is wrong >about the draft? > >Thanks, > >Peter > >> -----Original Message----- >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> Sent: Wednesday, November 12, 2003 11:54 PM >> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; >> tnadeau@cisco.com; pwe3@ietf.org >> Subject: RE: [PWE3] Adopt >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> WG draft? >> >> >> No, I have actually read it. >> >> -Shahram >> >> >-----Original Message----- >> >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >> >Sent: Wednesday, November 12, 2003 4:08 PM >> >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; >> >pwe3@ietf.org >> >Subject: RE: [PWE3] Adopt >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> >WG draft? >> > >> > >> >Sharam, >> > >> >Are you commenting on the draft, or are you just guessing what >> >you might find in the draft if you actually read it? >> > >> >Peter >> > >> >> -----Original Message----- >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >> Sent: Wednesday, November 12, 2003 12:04 PM >> >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >> >> Subject: RE: [PWE3] Adopt >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> >> WG draft? >> >> >> >> >> >> Right. So only AIS/FDI and Down state are mappable. The down >> >> state of MPLS layer (using CV or periodic ping) is used to >> >> generate AIS on the client layer (i.e., ATM, or FR). Also an >> >> FDI in MPLS layer could be used to generate AIS on client >> >> layer (ATM/FR). >> >> >> >> If the PEs don't support transport of ATM/FR AIS/RDI, then in >> >> theory it is possible (although not architecturally clean) to >> >> use some sort of signaling/message in MPLS network to inform >> >> the egress PE to generate the AIS/RDI on the ATM/FR connections. >> >> >> >> -Shahram >> >> >> >> >> >> >> >> >-----Original Message----- >> >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >> >> >Sent: Wednesday, November 12, 2003 12:45 PM >> >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >> >> >Subject: RE: [PWE3] Adopt >> >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> >> >WG draft? >> >> > >> >> > >> >> >Hi Shahram.....to be strictly accurate here, in a >> >> >client/server networking I/W case the only server->client OAM >> >> >function mapping that is relevent is FDI (or AIS in old >> >> >currency). RDI stays within the layer/trail it is relevant >> >> >to.....it has no upwards mapping from server->client in a >> >> >'backwards direction' (if you see what I mean) but terminates >> >> >at the trail sink of the return direction (if one exists). >> >> > >> >> >Otherwise I agree with your remarks. >> >> > >> >> >regards, Neil >> >> >> -----Original Message----- >> >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >> >> >> Sent: 12 November 2003 16:49 >> >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org >> >> >> Subject: RE: [PWE3] Adopt >> >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >> >> >> WG draft? >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> The only OAM function that is mappable in a network >> >> >> interworking case (e.g., PW) >> >> >> is AIS/RDI and up/down state. Any other type of mapping is >> >> >> not only architecturally wrong, but not required. >> >> >> >> >> >> So I suggest that first we have a debate on the higher level >> >> >> architectural issues >> >> >> and requirements before accepting this draft. >> >> >> >> >> >> Yours, >> >> >> -Shahram >> >> >> >> >> >> >> >> >> >-----Original Message----- >> >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >> >> >> >Sent: Monday, November 10, 2003 10:47 PM >> >> >> >To: pwe3@ietf.org >> >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >> >> >as PWE3 WG >> >> >> >draft? >> >> >> > >> >> >> > >> >> >> > >> >> >> > The chairs requested that we take the >> >> >> >matter of adoption of this draft to the >> >> >> >list. Please comment. >> >> >> > >> >> >> > --Tom >> >> >> > >> >> >> >>http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg- m > >> >> ap-03.txt > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> 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: Scott Kotrla Subject: RE: [802.1] RE: last call on control and ethernet drafts Date: Thu, 13 Nov 2003 09:08:28 -0700 Lines: 65 Sender: pwe3-admin@ietf.org References: <8052E2EA753D144EB906B7A7AA399714E5F972@mailserv.hatteras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Thu Nov 13 17:14:05 2003 Return-path: In-reply-to: <8052E2EA753D144EB906B7A7AA399714E5F972@mailserv.hatteras.com> To: "'Matt Squire'" , m_seery@yahoo.com, "'Ali Sajassi'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Matt, I would think this would be a function that would occur between the frame manipulation of 802.1ad and passing the frame to the MAC. I assume that the MAC is not what does the 802.1ad VLAN stacking/swapping functionality. Is this assumption not true? I take from your message that doing the egress FCS check is the concern and not appending the new FCS at ingress? If so, you could make doing the egress FCS check optional. If turned off, the error detection wouldn't be confined to the service provider network, but at least the frames would all get tossed at the ingress to the customer network and it would be clear that there is a problem. 802.3ah OAM could potentially send an alarm message back to the service provider that there are excessive errors on the wire once customer CPE supports this feature. Maybe you have some insight into what MAC chips typically do with the FCS. How often is it tossed after the FCS check and how often is it passed through the system end-to-end, with recalculation only if their have been changes? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Matt Squire Sent: Thursday, November 13, 2003 8:45 AM To: Scott Kotrla; m_seery@yahoo.com; Ali Sajassi Cc: pwe3@ietf.org; stds-802-1@ieee.org Subject: [802.1] RE: [PWE3] last call on control and ethernet drafts > > Regarding hardware costs, 802.1ad interfaces are likely going > to require > new hardware. I am highly suspicious of the assertion that stacking 4 > bytes on ingress and doing an extra CRC check on egress on new 802.1ad > hardware will have any significant impact on cost. I agree > that adding > this feature on existing hardware might be cost prohibitive in some > cases. > I haven't really looked into detailed cost derivatives for such a feature, however it does change the architectural model pretty significantly. In all of the products on which I've worked in my life, there has not been a way to do FCS checking on egress. The MAC performs an FCS check on ingress and counts the FCS errors, often discarding the errored frame for you (unless you configure the MAC to pass errored frames). On egress, the FCS may be recalculated depending if VLAN tags or priority bits have been inserted/deleted/modified. In many cases, the MAC or some other hardware computes the FCS for you and appends it. An architecture where FCS is checked at egress is a non-trivial modification to how things work today. Not saying its not possible, but the MAC, which does this for many people today, couldn't be used in the way its designed and currently implemneted. - Matt From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Shahram Davari Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 08:22:35 -0800 Lines: 222 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Thu Nov 13 17:24:09 2003 Return-path: To: Shahram Davari , "'Busschbach, Peter B (Peter)'" , "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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, By mistake I omitted the OAM in the following text. Here is the correct text: There are 2 major things wrong with this draft: 1) The draft advocates extending ATM/FR across the PW and doing ATM-FR Service interworking at only one PE. Meaning that interworking between ATM/FR and MPLS (aka PW) is Network interworking, and interworking between ATM-FR is Service interworking. But it asks for ATM-PW-FR OAM Service interworking at both PEs. This is architecturally wrong, because at one of the PEs you are doing Network interworking (between ATM/FR and PW) for the data-plane but doing Service interworking (between ATM/FR and PW) for the Management plane. 2) The draft advocates the mapping of CC and loopback between ATM/FR and MPLS in sections 4.7 and 4.8. Again, this is fundamentally wrong, since only the states and AIS needs mapping and not the CC or LB messages. Hope that answers yours question. Yours, -Shahram >-----Original Message----- >From: Shahram Davari >Sent: Thursday, November 13, 2003 10:55 AM >To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; >tnadeau@cisco.com; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >WG draft? > > >Hi Peter, > >There are 2 major things wrong with this draft: > >1) The draft advocates extending ATM/FR across the PW and doing >ATM-FR Service interworking at only one PE. Meaning that >interworking between >ATM/FR and MPLS (aka PW) is Network interworking, and >interworking between >ATM-FR is Service interworking. But it asks for ATM-PW-FR >Service interworking at both PEs. This is architecturally >wrong, because at one of the PEs you are doing Network >interworking (between ATM/FR and PW) for the data-plane but >doing Service interworking (between ATM/FR and PW) for the >Management plane. > >2) The draft advocates the mapping of CC and loopback between >ATM/FR and MPLS in >sections 4.7 and 4.8. Again, this is fundamentally wrong, >since only the states and >AIS needs mapping and not the CC or LB messages. > >Hope that answers yours question. > >Yours, >-Shahram > >>-----Original Message----- >>From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >>Sent: Thursday, November 13, 2003 10:08 AM >>To: Shahram Davari; Busschbach, Peter B (Peter); >>'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>WG draft? >> >> >>If you read the draft, you must have noticed that it discusses >>predominantly how to map up and down states to FDI and RDI. >>Therefore, I don't understand what prompted your first email. >>Could you explain more explicitly what you think is wrong >>about the draft? >> >>Thanks, >> >>Peter >> >>> -----Original Message----- >>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> Sent: Wednesday, November 12, 2003 11:54 PM >>> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; >>> tnadeau@cisco.com; pwe3@ietf.org >>> Subject: RE: [PWE3] Adopt >>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> WG draft? >>> >>> >>> No, I have actually read it. >>> >>> -Shahram >>> >>> >-----Original Message----- >>> >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >>> >Sent: Wednesday, November 12, 2003 4:08 PM >>> >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; >>> >pwe3@ietf.org >>> >Subject: RE: [PWE3] Adopt >>> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >WG draft? >>> > >>> > >>> >Sharam, >>> > >>> >Are you commenting on the draft, or are you just guessing what >>> >you might find in the draft if you actually read it? >>> > >>> >Peter >>> > >>> >> -----Original Message----- >>> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> >> Sent: Wednesday, November 12, 2003 12:04 PM >>> >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>> >> Subject: RE: [PWE3] Adopt >>> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >> WG draft? >>> >> >>> >> >>> >> Right. So only AIS/FDI and Down state are mappable. The down >>> >> state of MPLS layer (using CV or periodic ping) is used to >>> >> generate AIS on the client layer (i.e., ATM, or FR). Also an >>> >> FDI in MPLS layer could be used to generate AIS on client >>> >> layer (ATM/FR). >>> >> >>> >> If the PEs don't support transport of ATM/FR AIS/RDI, then in >>> >> theory it is possible (although not architecturally clean) to >>> >> use some sort of signaling/message in MPLS network to inform >>> >> the egress PE to generate the AIS/RDI on the ATM/FR connections. >>> >> >>> >> -Shahram >>> >> >>> >> >>> >> >>> >> >-----Original Message----- >>> >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>> >> >Sent: Wednesday, November 12, 2003 12:45 PM >>> >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>> >> >Subject: RE: [PWE3] Adopt >>> >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >> >WG draft? >>> >> > >>> >> > >>> >> >Hi Shahram.....to be strictly accurate here, in a >>> >> >client/server networking I/W case the only server->client OAM >>> >> >function mapping that is relevent is FDI (or AIS in old >>> >> >currency). RDI stays within the layer/trail it is relevant >>> >> >to.....it has no upwards mapping from server->client in a >>> >> >'backwards direction' (if you see what I mean) but terminates >>> >> >at the trail sink of the return direction (if one exists). >>> >> > >>> >> >Otherwise I agree with your remarks. >>> >> > >>> >> >regards, Neil >>> >> >> -----Original Message----- >>> >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> >> >> Sent: 12 November 2003 16:49 >>> >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>> >> >> Subject: RE: [PWE3] Adopt >>> >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >> >> WG draft? >>> >> >> >>> >> >> >>> >> >> Hi, >>> >> >> >>> >> >> The only OAM function that is mappable in a network >>> >> >> interworking case (e.g., PW) >>> >> >> is AIS/RDI and up/down state. Any other type of mapping is >>> >> >> not only architecturally wrong, but not required. >>> >> >> >>> >> >> So I suggest that first we have a debate on the higher level >>> >> >> architectural issues >>> >> >> and requirements before accepting this draft. >>> >> >> >>> >> >> Yours, >>> >> >> -Shahram >>> >> >> >>> >> >> >>> >> >> >-----Original Message----- >>> >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>> >> >> >Sent: Monday, November 10, 2003 10:47 PM >>> >> >> >To: pwe3@ietf.org >>> >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>> >> >as PWE3 WG >>> >> >> >draft? >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > The chairs requested that we take the >>> >> >> >matter of adoption of this draft to the >>> >> >> >list. Please comment. >>> >> >> > >>> >> >> > --Tom >>> >> >> > >>> >> >> >>>http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg- >m >> >> >> ap-03.txt >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> >> >> > >> > >_______________________________________________ >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: "Matt Squire" Subject: RE: [802.1] RE: last call on control and ethernet drafts Date: Thu, 13 Nov 2003 11:45:26 -0500 Lines: 61 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 Nov 13 17:47:16 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Thread-Topic: [802.1] RE: [PWE3] last call on control and ethernet drafts Thread-Index: AcOqARA35hx5KBcBS4WouEJLFxBi5wAAp1jg To: "Scott Kotrla" , , "Ali Sajassi" 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 > I would think this would be a function that would occur between the > frame manipulation of 802.1ad and passing the frame to the MAC. I > assume that the MAC is not what does the 802.1ad VLAN=20 > stacking/swapping > functionality. Is this assumption not true? Thats certainly true. This functional block, which is pretty much HW, doesn't exist in most = product architectures. I'm not saying it can't be added, but its a new = egress HW block that doesn't cost much in C?COGS but which does change = the fundamental architecture of what happens where and why. =20 >=20 > I take from your message that doing the egress FCS check is=20 > the concern > and not appending the new FCS at ingress? If so, you could make doing > the egress FCS check optional. If turned off, the error detection > wouldn't be confined to the service provider network, but at least the > frames would all get tossed at the ingress to the customer network and > it would be clear that there is a problem. 802.3ah OAM could > potentially send an alarm message back to the service provider that > there are excessive errors on the wire once customer CPE supports this > feature. >=20 That's my primary concern from an implementation and architectural = perspective. Can't speak for anyone else. =20 On ingress, I can imagine how it could be done on non-ASIC = implementations. Of course how I imagine it happening might conflict = internal error detection mechanisms (e.g. if you treat a packet with an = FCS as not having an FCS, then its just data and you can add one at = egress, but then its difficult to use that FCS internally for detecting = internal corruption). =20 But all implementations are different and I can also see how it would = make life difficult for some. =20 Personally, I'm torn. I understand your concerns. But I also = understand Ali's reasoning that it may not buy you anything. Your basic = premise is that equipment can't be trusted:( As an equipment vendor, I = think I might cry... > Maybe you have some insight into what MAC chips typically do with the > FCS. How often is it tossed after the FCS check and how often is it > passed through the system end-to-end, with recalculation only if their > have been changes? >=20 >>=20 (based on recollection, haven't verified with spec reading) Officially, I believe the MAC discards FCS errored frames on ingress. = Unofficially, most MACs provide mechanisms to pass up FCS errored frame = (really needed in system debugging). =20 - Matt From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 11:45:45 -0500 Organization: Cisco Systems, inc. Lines: 207 Sender: pwe3-admin@ietf.org References: <4B6D09F3B826D411A67300D0B706EFDE0115CCFD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Nov 13 17:47:19 2003 Return-path: To: 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 Importance: Normal In-Reply-To: <4B6D09F3B826D411A67300D0B706EFDE0115CCFD@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> 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 >-----Original Message----- >From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >Sent: Thursday, November 13, 2003 10:55 AM >To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; >tnadeau@cisco.com; pwe3@ietf.org >Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >as PWE3 WG draft? > > >Hi Peter, > >There are 2 major things wrong with this draft: > >1) The draft advocates extending ATM/FR across the PW and doing >ATM-FR Service interworking at only one PE. Meaning that >interworking between >ATM/FR and MPLS (aka PW) is Network interworking, and >interworking between >ATM-FR is Service interworking. But it asks for ATM-PW-FR >Service interworking at both PEs. This is architecturally >wrong, because at one of the PEs you are doing Network >interworking (between ATM/FR and PW) for the data-plane but >doing Service interworking (between ATM/FR and PW) for the >Management plane. Actually I mentioned that I will be removing the any-to-any interworking stuff from the draft during the meeting, as this is out of scope of the current charter. --Tom >2) The draft advocates the mapping of CC and loopback between >ATM/FR and MPLS in >sections 4.7 and 4.8. Again, this is fundamentally wrong, >since only the states and >AIS needs mapping and not the CC or LB messages. > >Hope that answers yours question. > >Yours, >-Shahram > >>-----Original Message----- >>From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >>Sent: Thursday, November 13, 2003 10:08 AM >>To: Shahram Davari; Busschbach, Peter B (Peter); >>'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>WG draft? >> >> >>If you read the draft, you must have noticed that it discusses >>predominantly how to map up and down states to FDI and RDI. >>Therefore, I don't understand what prompted your first email. >>Could you explain more explicitly what you think is wrong >>about the draft? >> >>Thanks, >> >>Peter >> >>> -----Original Message----- >>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> Sent: Wednesday, November 12, 2003 11:54 PM >>> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; >>> tnadeau@cisco.com; pwe3@ietf.org >>> Subject: RE: [PWE3] Adopt >>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> WG draft? >>> >>> >>> No, I have actually read it. >>> >>> -Shahram >>> >>> >-----Original Message----- >>> >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] >>> >Sent: Wednesday, November 12, 2003 4:08 PM >>> >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; >>> >pwe3@ietf.org >>> >Subject: RE: [PWE3] Adopt >>> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >WG draft? >>> > >>> > >>> >Sharam, >>> > >>> >Are you commenting on the draft, or are you just guessing what >>> >you might find in the draft if you actually read it? >>> > >>> >Peter >>> > >>> >> -----Original Message----- >>> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> >> Sent: Wednesday, November 12, 2003 12:04 PM >>> >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org >>> >> Subject: RE: [PWE3] Adopt >>> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >> WG draft? >>> >> >>> >> >>> >> Right. So only AIS/FDI and Down state are mappable. The down >>> >> state of MPLS layer (using CV or periodic ping) is used to >>> >> generate AIS on the client layer (i.e., ATM, or FR). Also an >>> >> FDI in MPLS layer could be used to generate AIS on client >>> >> layer (ATM/FR). >>> >> >>> >> If the PEs don't support transport of ATM/FR AIS/RDI, then in >>> >> theory it is possible (although not architecturally clean) to >>> >> use some sort of signaling/message in MPLS network to inform >>> >> the egress PE to generate the AIS/RDI on the ATM/FR connections. >>> >> >>> >> -Shahram >>> >> >>> >> >>> >> >>> >> >-----Original Message----- >>> >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] >>> >> >Sent: Wednesday, November 12, 2003 12:45 PM >>> >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org >>> >> >Subject: RE: [PWE3] Adopt >>> >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >> >WG draft? >>> >> > >>> >> > >>> >> >Hi Shahram.....to be strictly accurate here, in a >>> >> >client/server networking I/W case the only server->client OAM >>> >> >function mapping that is relevent is FDI (or AIS in old >>> >> >currency). RDI stays within the layer/trail it is relevant >>> >> >to.....it has no upwards mapping from server->client in a >>> >> >'backwards direction' (if you see what I mean) but terminates >>> >> >at the trail sink of the return direction (if one exists). >>> >> > >>> >> >Otherwise I agree with your remarks. >>> >> > >>> >> >regards, Neil >>> >> >> -----Original Message----- >>> >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] >>> >> >> Sent: 12 November 2003 16:49 >>> >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org >>> >> >> Subject: RE: [PWE3] Adopt >>> >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 >>> >> >> WG draft? >>> >> >> >>> >> >> >>> >> >> Hi, >>> >> >> >>> >> >> The only OAM function that is mappable in a network >>> >> >> interworking case (e.g., PW) >>> >> >> is AIS/RDI and up/down state. Any other type of mapping is >>> >> >> not only architecturally wrong, but not required. >>> >> >> >>> >> >> So I suggest that first we have a debate on the higher level >>> >> >> architectural issues >>> >> >> and requirements before accepting this draft. >>> >> >> >>> >> >> Yours, >>> >> >> -Shahram >>> >> >> >>> >> >> >>> >> >> >-----Original Message----- >>> >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] >>> >> >> >Sent: Monday, November 10, 2003 10:47 PM >>> >> >> >To: pwe3@ietf.org >>> >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt >>> >> >as PWE3 WG >>> >> >> >draft? >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > The chairs requested that we take the >>> >> >> >matter of adoption of this draft to the >>> >> >> >list. Please comment. >>> >> >> > >>> >> >> > --Tom >>> >> >> > >>> >> >> >>>http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg- >m >> >> >> ap-03.txt >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> 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: neil.2.harrison@bt.com Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 18:28:50 -0000 Lines: 29 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 Thu Nov 13 19:30:06 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Content-Class: urn:content-classes:message Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? thread-index: AcOqBd0B7IVYC97+QQSaJ0ObJWCA/QAZH1ng To: , X-OriginalArrivalTime: 13 Nov 2003 18:28:50.0649 (UTC) FILETIME=[FC0FA490:01C3AA13] 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 Tom, 1 question below for clarification....though perhaps George = should answer. regards, Neil > > > >Hi Peter, > > > >There are 2 major things wrong with this draft: > > > >1) The draft advocates extending ATM/FR across the PW and doing > >ATM-FR Service interworking at only one PE. Meaning that=20 > >interworking between > >ATM/FR and MPLS (aka PW) is Network interworking, and=20 > >interworking between > >ATM-FR is Service interworking. But it asks for ATM-PW-FR=20 > >Service interworking at both PEs. This is architecturally=20 > >wrong, because at one of the PEs you are doing Network=20 > >interworking (between ATM/FR and PW) for the data-plane but=20 > >doing Service interworking (between ATM/FR and PW) for the=20 > >Management plane. >=20 > Actually I mentioned that I will be removing the=20 > any-to-any interworking stuff from the draft during the meeting, > as this is out of scope of the current charter. >=20 > --Tom NH=3D> Does this mean = http://www.ietf.org/internet-drafts/draft-swallow-pwe3-spvc-iw-00.txt is = also now out of scope?....signalling I/W is for sure a major component = of service I/W and is only valid under these terms. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "mIck_seaman@ieee.org" Subject: (no subject) Date: Thu, 13 Nov 2003 11:54:33 -0500 Lines: 17 Sender: pwe3-admin@ietf.org Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Nov 13 23:12:05 2003 Return-path: To: stds-802-1@ieee.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 One of the things we had to be very clear about when we passed the 802.1ad PAR was that there would be no new interface parameters to the ISS and no new major entities/processes within the MAC Relay Entity. I believe that means that this "two FCSes" suggestion falls under the heading of new work and should be considered as such. As noted by others it could have very significant effects on bridge implementation architectures, and obsoleting bridge architecture is well outside the intent and discussion of the PAR. Separately it has been noted that use of MACsec to provide integrity (without necessarily requiring confidentiality) would provide significantly greater guarantee of no changes having been made to the frame. Mick From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Sinicrope" Subject: RE: CE-to-CE PWs, Hierarchical VPLS and Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt Date: Wed, 12 Nov 2003 11:07:38 -0500 Organization: Ericsson IPI Lines: 258 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "'Alik Shimelmits'" , "'Stewart Bryant \(E-mail\)'" , "'Prayson Pate \(E-mail\)'" , "'PWE3 WG \(E-mail\)'" , "'Yaakov Stein \(E-mail\)'" X-From: pwe3-admin@ietf.org Thu Nov 13 23:12:14 2003 Return-path: To: "'Sasha Vainshtein'" , "'Busschbach, Peter B \(Peter\)'" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 The MPLS UNI that Sasha is referring to is on the MPLS&FR Alliance website: http://www.mplsforum.org/tech/MPLS_FR202.0.1.pdf It allows a provider network to present multiple TE LSPs to a CE device over one interface. Essentially these can be used as the transport tunnels for the PWs. The UNI provides LSPs for transport in a way similar to Frame Relay PVCs and ATM PVCCs. Currently the transport LSPs are "PVC-like" in that they are provisioned between two CEs. Similar to the FR UNI, there is no routing information/protocol passed on the CE-PE interface, so the provider topology and routing information is not exposed to the CE. In addition to the transport LSPs there is a LSP status protocol that is based on LDP. It provides information about the transport LSPs that are available on the CE-PE interface. The transport LSP information can be provisioned in the CEs and verified with the status protocol or learned from the status protocol. After hearing Yaakov's presentation Monday night, it seemed to me that the UNI might be a good solution. =20 -David ------------------------------------------------------- David Sinicrope Ericsson IPI Email: david.sinicrope@ericsson.com Phone: +1 919 472 9967 Fax: +1 919 472 9999 ECN: 802 29967 > -----Original Message----- > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 > Sent: Tuesday, November 11, 2003 6:57 PM > To: 'Busschbach, Peter B (Peter)' > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate=20 > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail); Yaakov=20 > Stein (E-mail) > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and=20 > Pseudowire Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt >=20 >=20 > Peter, > Thank you for a prompt response. >=20 > I'll check your reference to hierarchical VPLS in=20 > draft-ietf-l2vpn-signaling-00.txt > However, I do not think that Option 3 is really identical to=20 > hierarchical VPLS because the PSF is service-agnostic > and does not look at any part of the native frame. > I would say it sounds like a hierarchical VPWS. >=20 > I would appreciate references to multi-hop LSPs if you can=20 > provide them. >=20 > Wrt interest - or lack thereof - based on Yaakov's draft, the=20 > crucial question, IMO, is: what justifies support of Option 3=20 > when Option 2 does the same job as well? Saving one label=20 > stack entry on the CE-PE packet clearly does not. And, from=20 > little I know about MPLS UNI (David is the expert here), it=20 > allows you to obtain a valid transport label without the need=20 > to learn the core topology. It is also a clear-cut control=20 > plane solution, without the need for a new function (PSF) in=20 > the high-speed data plane. >=20 > Please note that I do not reject Option 3 out of hand. I=20 > simply try to understand its advantages (and disadvantages:-). >=20 > At the same time I feel pretty sure that Option 1 is a dead-end. >=20 > -------------------------------------------------------------- > -------------- > -------- > With best regards, > Sasha Vainshtein > email: sasha@axerra.com =20 > phone: +972-3-7659993 (office) > +972-8-9254948 (home) > +972-58-674833 (cellular) >=20 >=20 > > -----Original Message----- > > From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > > Sent: Wednesday, November 12, 2003 1:01 AM > > To: Sasha Vainshtein; Yaakov Stein (E-mail) > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate=20 > (E-mail);=20 > > PWE3 WG (E-mail); David Sinicrope (E-mail) > > Subject: RE: [PWE3] CE-to-CE PWs, Hierarchical VPLS and Pseudowire=20 > > Stitchi ng Function in draft-stein-pwe3-pwce2e-00.txt > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Sasha Vainshtein [mailto:Sasha@AXERRA.com] > > > Sent: Tuesday, November 11, 2003 3:02 PM > > > To: Yaakov Stein (E-mail) > > > Cc: Alik Shimelmits; Stewart Bryant (E-mail); Prayson Pate > > > (E-mail); PWE3 WG (E-mail); David Sinicrope (E-mail) > > > Subject: [PWE3] CE-to-CE PWs, Hierarchical VPLS and=20 > > > Pseudowire Stitching Function in draft-stein-pwe3-pwce2e-00.txt > > >=20 > > >=20 > > > Yaakov and all, > > > I'd like to present the technical problem I have with the > > > current text of draft-stein-pwe3-pwce2e-00.txt and options=20 > > > for solving this problem. > > >=20 > > > My problem is with the following para in Section 3: > > >=20 > > > > > > The ideal way of handling a PWCE2E packet is to=20 > > > have the CE perform the service specific encapsulation=20 > > > and to prepend the (inner) PW label, but no (outer) MPLS=20 > > > transport labels. The PE, which participates in the provider=20 > > > network signaling, then adds the appropriate MPLS labels=20 > > > as required. > > > > > >=20 > > > IMO, it is easy to see why this will not work as written. > > >=20 > > > Please consider the following use case: > > >=20 > > > 1. There are three CEs (CE-1, CE-2 and CE-3) attached=20 > > > to 3 PEs (PE-1, PE-2 and PE3 respectively). > > > 2. In each case the link between CE-i and PE-i is a=20 > > > "single-hop" link (i.e., there are no LSRs in the=20 > > > path, but there may be L2 switches - Ethernet, FR/ATM etc). 3.=20 > > > You want to run two PWs: > > > a) PW-12 runs between CE-1 and CE-2=20 > > > b)PW-13 runs between CE-1 and CE-3. > > >=20 > > > How can PE-1 (which both these PWs have to cross on their ways > > > to their peer CEs) know which transport labels to add to packets=20 > > > received from CE-1? > > >=20 > > > This decision CANNOT be based on the PW labels in these packets, > > > because these labels are independently allocated by CE-2 and CE-3=20 > > > respectively, so that nothing prevents them from being equal=20 > > > (accidentally or else).=20 > > > And inspection of the encapsulated data will not help either. > > >=20 > > > (BTW, this is exactly the difference between MPLS and, say, > > > FR or ATM: in the latter cases, DLCI or VCI/VPI values are=20 > > > unique on the attachment link and known to the PE,=20 > > > in the former case they are not.) > > >=20 > > > How can this be fixed? > > >=20 > > > I see three ways to do so. > > >=20 > > > 1. Limit this case to one PW per CE. IMO, this is > > > a very problematic limitation (one could say, that > > > it is ultimately non-scalable!) and does not=20 > > > justify any action wrt the existing documents. > > >=20 > > > 2. Allow the CE to push both the PW and transport labels > > > on top of the payload and PWE3 control info. > > > This would make it equivalent to the "normal" PW,and no > > > technical changes in the architecture doc are required. > > > The transport label can be obtained in many different ways, > > > including usage of the MPLS UNI (as suggested by David=20 > > > Sinicrope). > > >=20 > > > 3. Use PW stitching. This would introduce a new element=20 > > > in the PWE3 architecture - the Pseudo-Wire > > > Stitching Function (PSF) - located in the PEs.=20 > > > The PSF would operate like following: > > > a) Terminate a "usual" PW running between two PEs=20 > > > adjacent to the CEs in question.=20 > > > Note that the PEs must exchange their incoming > > > PW labels for this PW just as in the "normal" case > > > b) Terminate the "spoke" PW between the CE and its adjacent PE. > > > This PW would not require transport labels because > > the CE<-->PE > > > transport LSPs are just one hop, and PHP can be applied > > > to them.=20 > > > The PW labels for the spoke PWs would be exchanged=20 > > > between the CE and > > > its adjacent PE in the usual way. > > > c) Stitch the spoke PW with the PE-PE PW. Such a=20 > stitching would: > > > * Leave the PW packet payload and control info (if=20 > any) intact > > > * Swap the inner label=20 > > > * In one direction (CE-->PE), push the transport > > > label(s) required for the PE-PE PW.=20 > > > Opposite to the PW IWFs, one and only one PSF type is required. > > > The resulting architecture resembles the Hierarchical VPLS=20 > > > defined in > > > draft-ietf-l2vln-vpls-ldp-01.txt (hence the term=20 > "Spoke PW"). Its > > > advantage > > > stems from moving the service-specific IWF functionality=20 > > > towards the CE > > > (and hence > > > may be of special importance for TDM PWs), while possibility of > > > misconfiguration=20 > > > (e.g., connection of IWFs with different service=20 > types) should be > > > considered=20 > > > as a disadvantage. Another disadvantage, of course, is=20 > > > introduction of a > > > new=20 > > > (albeit simple) architectural element in the high-speed=20 > > data plane. > > > =20 > > > IMO, any technical changes in the architecture document > > > should be considered > > > only if we reach a conclusion that advantages of the PW=20 > > > stitching option > > > outweigh its disadvantages.=20 > >=20 > > Sasha, > >=20 > > I believe that option 3 is identical to the Distributed VPLS > > model described in section 5.5 of draft-ietf-l2vpn-signaling-00.txt. > >=20 > > IMO, CE-CE PWs is just one example of situations that require > > multi-hop PWs.=20 > >=20 > > draft-ietf-l2vpn-signaling-00.txt talks about splicing PWs. > > You talk about stitching PWs. In both cases the solution=20 > > sounds kludgy, to say the least. However, if you look at=20 > > these multi-hop PWs as regular LSPs established along a=20 > > multi-hop path, everything is pretty much straightforward.=20 > > Setup of such multi-hop LSPs would require a protocol like=20 > > CR-LDP or RSVP. RSVP is in my view the preferred solution,=20 > > but CR-LDP would be closer to the current control draft. > >=20 > > In any case, as I said in another email, I would prefer it if > > we would solve the multi-hop issue before progressing the=20 > > control draft. The response to that email was that it is not=20 > > clear that people are interested in the multi-hop solution. I=20 > > would argue that Yaakov's contribution shows that there is interest. > >=20 > > Peter > >=20 > > > =20 > > > Hope these notes would be helpful. > > > -------------------------------------------------------------- > > > -------------- > > > -------- > > > With best regards, > > > Sasha Vainshtein > > > email: sasha@axerra.com > > > phone: +972-3-7659993 (office) > > > +972-8-9254948 (home) > > > +972-58-674833 (cellular) > > >=20 > > > _______________________________________________ > > > pwe3 mailing list > > > pwe3@ietf.org > > > https://www1.ietf.org/mailman/listinfo/pwe3 > > >=20 > >=20 >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Pugaczewski, Jack" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Thu, 13 Nov 2003 06:49:48 -0600 Lines: 177 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 Nov 13 23:12:16 2003 Return-path: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Thread-Index: AcOpxSBG7vBOhoUoQCCMMLKtwMu+zAAHuDew To: , , , X-OriginalArrivalTime: 13 Nov 2003 12:49:48.0499 (UTC) FILETIME=[9F31E230:01C3A9E4] 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 >From a carrier's perspective I believe it is important to extend the existing model. For example in SONET and ATM there is a mapping between F1, F2, F3, F4 and F5. In the case of Frame Relay to ATM Interworking FRF.8 provides a mapping for fault management between F5 AIS/RDI and LMI. =20 -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of neil.2.harrison@bt.com Sent: Thursday, November 13, 2003 3:02 AM To: Shahram_Davari@pmc-sierra.com; tnadeau@cisco.com; pwe3@ietf.org Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? As Dave Allan pointed out earlier, there is a document on ATM and MPLS peer OAM I/W....it is Y.1712. Its simple and complete. This should not be ignored. regards, Neil > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: 13 November 2003 06:03 > To: 'tnadeau@cisco.com'; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? >=20 >=20 > I think A document on OAM Interworking between PW and ATM/FR > is needed. > Does that mean any draft with this title should be accepted? >=20 > -Shahram >=20 > >-----Original Message----- > >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >Sent: Wednesday, November 12, 2003 6:28 PM > >To: pwe3@ietf.org > >Subject: RE: [PWE3] Adopt > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > > > > Although a valid point for discussion, the real question > >should be whether a document in question is useful to the WG=20 > >or not. If it is, we can discuss the details on the list, > >as is normal IETF policy. =20 > > > > --Tom > > > > > >>-----Original Message----- > >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > >>Behalf Of Shahram Davari > >>Sent: Wednesday, November 12, 2003 12:04 PM > >>To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >>Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >>as PWE3 WG draft? > >> > >> > >>Right. So only AIS/FDI and Down state are mappable. The down > >>state of MPLS layer (using CV or periodic ping) is used to=20 > >>generate AIS on the client layer (i.e., ATM, or FR). Also an=20 > >>FDI in MPLS layer could be used to generate AIS on client=20 > >>layer (ATM/FR). > >> > >>If the PEs don't support transport of ATM/FR AIS/RDI, then in > >>theory it is possible (although not architecturally clean) to=20 > >>use some sort of signaling/message in MPLS network to inform=20 > >>the egress PE to generate the AIS/RDI on the ATM/FR connections. > >> > >>-Shahram > >> > >> > >> > >>>-----Original Message----- > >>>From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >>>Sent: Wednesday, November 12, 2003 12:45 PM > >>>To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >>>Subject: RE: [PWE3] Adopt > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>>WG draft? > >>> > >>> > >>>Hi Shahram.....to be strictly accurate here, in a > >>>client/server networking I/W case the only server->client OAM=20 > >>>function mapping that is relevent is FDI (or AIS in old=20 > >>>currency). RDI stays within the layer/trail it is relevant=20 > >>>to.....it has no upwards mapping from server->client in a=20 > >>>'backwards direction' (if you see what I mean) but terminates=20 > >>>at the trail sink of the return direction (if one exists). > >>> > >>>Otherwise I agree with your remarks. > >>> > >>>regards, Neil > >>>> -----Original Message----- > >>>> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >>>> Sent: 12 November 2003 16:49 > >>>> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >>>> Subject: RE: [PWE3] Adopt > >>>draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >>>> WG draft? > >>>>=20 > >>>>=20 > >>>> Hi, > >>>>=20 > >>>> The only OAM function that is mappable in a network > >>>> interworking case (e.g., PW) > >>>> is AIS/RDI and up/down state. Any other type of mapping is=20 > >>>> not only architecturally wrong, but not required. > >>>>=20 > >>>> So I suggest that first we have a debate on the higher level > >>>> architectural issues > >>>> and requirements before accepting this draft. > >>>>=20 > >>>> Yours, > >>>> -Shahram > >>>>=20 > >>>>=20 > >>>> >-----Original Message----- > >>>> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >>>> >Sent: Monday, November 10, 2003 10:47 PM > >>>> >To: pwe3@ietf.org > >>>> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt > >>>as PWE3 WG > >>>> >draft? > >>>> > > >>>> > > >>>> > > >>>> > The chairs requested that we take the > >>>> >matter of adoption of this draft to the > >>>> >list. Please comment. > >>>> > > >>>> > --Tom > >>>> > > >>>> >http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-m > >>>> ap-03.txt > >>>>=20 > >>>>=20 > >>>>=20 > >>>> _______________________________________________ > >>>> pwe3 mailing list > >>>> pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>=20 > >>>> _______________________________________________ > >>>> pwe3 mailing list > >>>> pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 > >>>>=20 > >>> > >> > >>_______________________________________________ > >>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 > > >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ 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: ITU-T FR draft Date: Thu, 13 Nov 2003 16:12:04 -0700 Organization: Cisco Systems Lines: 43 Sender: pwe3-admin@ietf.org References: <27A0F290348F8E45AEF79889DDE65A5201860E95@exrad2.ad.rad.co.il> <3878F46C-1583-11D8-B269-000393D54EA6@tcb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Danny McPherson , pwe3@ietf.org, Jon Peterson X-From: pwe3-admin@ietf.org Fri Nov 14 00:13:06 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721 X-Accept-Language: en-us, en To: Yaakov Stein In-Reply-To: <3878F46C-1583-11D8-B269-000393D54EA6@tcb.net> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 My understanding is that Claude ( FR editor ) is making sure this is the case today. What is the problem Yakov ? Luca Danny McPherson wrote: > > I think this is fine, so long as the IETF document is aligned > with the goals and consensus of the WG and the IETF. Do you > foresee any potential reasons why this might not be the case? > > -danny > > > On Nov 11, 2003, at 6:49 PM, Yaakov Stein wrote: > >> Dear WG chairs and everyone, >> >> I would like to re-iterate my suggestion that the IETF and >> ITU-T SG17 work together to produce a single harmonized >> FR draft. >> >> Since SG17 has adopted the PWE3 terminology, >> and there is great overlap in authors of the PWE and ITU drafts, >> it should be possible to make the documents precisely identical. >> >> This has been done before (e.g. Megaco/H.248) >> and has the advantage of ensuring that there can be >> no minor issues that can later crop up due to different >> wording. >> >> Y(J)S >> > > > _______________________________________________ > 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: [802.1] RE: last call on control and ethernet drafts Date: Thu, 13 Nov 2003 16:58:13 -0700 Organization: Cisco Systems Lines: 95 Sender: pwe3-admin@ietf.org References: <8052E2EA753D144EB906B7A7AA399714E5F974@mailserv.hatteras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Scott Kotrla , m_seery@yahoo.com, Ali Sajassi , pwe3@ietf.org, stds-802-1@ieee.org, "Andrew G. Malis" X-From: pwe3-admin@ietf.org Fri Nov 14 00:59:02 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.2.1) Gecko/20030721 X-Accept-Language: en-us, en To: Matt Squire In-Reply-To: <8052E2EA753D144EB906B7A7AA399714E5F974@mailserv.hatteras.com> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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, First of all I have to say that your requirement seem to invalidate the 10s of gigabit of IP traffic that is forwarded today without operational issues and end to end layer2 FCS. I also believe that requiring ans FCS end to end will result in major architectural changes for the routers that would ultimately have to perform FCS calculations on the hole packet. Egress FCS check would require the routing engine to have access to the hole packet. I can safely say that none of the routing engines can do this today , and new hardware would have to be built and inserted in the data path just before the output MAC. This would in turn significantly raise the cost of transporting the PW and ultimately make the service non-economical. I still believe that the end to end FCS is the application layer task, however all network elements should have means to guarantee that data does not get corrupted while transiting the box. Please consider also the fact vlan re-write would no longer be easily achieved. I have not seen consensus on this issue yes, but there is a lot of arguing about it. I propose that since this is going to be a major change we look at having a PW FCS that would be optional , and would work for all PWs. This would allow the current design to progress as is , and yet would meet your requirements for all types of PWs. Luca Matt Squire wrote: > > >>I would think this would be a function that would occur between the >>frame manipulation of 802.1ad and passing the frame to the MAC. I >>assume that the MAC is not what does the 802.1ad VLAN >>stacking/swapping >>functionality. Is this assumption not true? >> >> > >Thats certainly true. > >This functional block, which is pretty much HW, doesn't exist in most product architectures. I'm not saying it can't be added, but its a new egress HW block that doesn't cost much in C?COGS but which does change the fundamental architecture of what happens where and why. > > > >>I take from your message that doing the egress FCS check is >>the concern >>and not appending the new FCS at ingress? If so, you could make doing >>the egress FCS check optional. If turned off, the error detection >>wouldn't be confined to the service provider network, but at least the >>frames would all get tossed at the ingress to the customer network and >>it would be clear that there is a problem. 802.3ah OAM could >>potentially send an alarm message back to the service provider that >>there are excessive errors on the wire once customer CPE supports this >>feature. >> >> >> > >That's my primary concern from an implementation and architectural perspective. Can't speak for anyone else. > >On ingress, I can imagine how it could be done on non-ASIC implementations. Of course how I imagine it happening might conflict internal error detection mechanisms (e.g. if you treat a packet with an FCS as not having an FCS, then its just data and you can add one at egress, but then its difficult to use that FCS internally for detecting internal corruption). > >But all implementations are different and I can also see how it would make life difficult for some. > >Personally, I'm torn. I understand your concerns. But I also understand Ali's reasoning that it may not buy you anything. Your basic premise is that equipment can't be trusted:( As an equipment vendor, I think I might cry... > > > >>Maybe you have some insight into what MAC chips typically do with the >>FCS. How often is it tossed after the FCS check and how often is it >>passed through the system end-to-end, with recalculation only if their >>have been changes? >> >> >> > >(based on recollection, haven't verified with spec reading) > >Officially, I believe the MAC discards FCS errored frames on ingress. Unofficially, most MACs provide mechanisms to pass up FCS errored frame (really needed in system debugging). > >- Matt > >_______________________________________________ >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: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Thu, 13 Nov 2003 17:59:18 -0800 Lines: 50 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ali Sajassi , Scott Kotrla , stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 14 03:00:06 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Norman Finn In-Reply-To: <3FB407D0.3080803@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 Norman. I certainly appreciate people with 802 experience chiming in. Matt's comments were very good, and you have provided much good background as well. In your long note, I got the impression that your central argument is that a PW is not Ethernet grade unless it provides 32-bit CRC or better. I understand 802 wanting to define what meets it standard of goodness. By mandating this you are suggesting that a range of existing systems, and potentially chipsets, do not support this requirement - I'll assume that is a considered judgement from you having weighed all the implications. You are also suggesting that the things that we once did to support less sophisticated and reliable media must always be done, once again I'll assume you hve considered this and you remain convinced of this necessity. And lastly as Luca states, you are suggesting that you did not receive this email ;-) All joking aside, I am all for strong integrity checks, there are these other nagging issues. If the standards are driven in such a way that a new class of equipment is required, then that's OK with me too, because I am more likely to benefit from that, than if not. Perhaps inherent in your comments is the thought that service providers will deploy a new class of specialized provider bridges that do only that functionality. Perhaps that is possible as well, though that is unlikely the intent of the IETF PW group, but understand 802s right to pursue creating this opportunity. On your desire to impress of your real world experience with PW and bridges, I don't doubt it and I am not sure what I said to inspire that reaction. As far as I recall all I have said is that I didn't believe "existing" bridges would be in the middle of a PW [because they don't speak PW]. On the assumption 802 makes that 802 is everywhere, I have no problem with that as it has served 802 so well, but I would observe that IP/IETF has thrived by assuming the complete opposite - such is life.... Once last comment to the group, I was forced to stay away from my computer to do some travel today which led me to recall that this industry has thrived precisely by adhering to some basic principles. One of which is if you a terminating a layer, you through away the lower-layer headers and trailers, and if you are not terminating a layer, you leave them alone. While I realize that observation leads to rat-holes about what is a layer (which the group has previously expressed a desire not to go down), the principle is powerful and useful (IMHO). On this, I have a feeling we *might* agree, but this of course brings up all the ugly issues, that your requirements do, as stated in the first paragraph. best, and thanks for your feedback. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Thu, 13 Nov 2003 18:59:16 -0800 Lines: 42 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 14 04:00:07 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Norman Finn In-Reply-To: <3FB407D0.3080803@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 Norman Finn wrote: > End-to-end > preservation of the Customer's original FCS is an interesting > proposition, but is > not relevant to this formulation of the problem. Norman I disagree. First of all I don't think I stated it that way, I talked about was payload integrity. In an X over Y situation, if X is assuming that Y is maintaining the integrity of X's PDUs, and it does not, then that is a problem. X then processes its PDUs assuming they are not corrupt. This becomes a problem even with two bridges exchanging BPDUs over a PW, and is certainly a problem with a service provider making guarantees to subscribers. The problem I suggested of X's PDUs being corrupted as Y removed a FCS and added a new one, is at least on the same theoretical plane as suggesting that modern facilities introduce errors at some significant level requiring a 32 bit FCS. Both might actually be false claims most of the time, but we protect for the times when it is not false. So this gets back to the issue of transport vs relay vs routing, and the principles of terminating a layer or not, if adhered to would suggest that X's PDUs do not get changed because they are being transported over Y. X wanted Y to mess with its PDUs, it probably would have signed up for a routed service (where the layers below IP are terminated in every possible sense) rather than a transport service. This is an issue that PW should be dealing with as well, but in the interest of time..... So the draft from malis et el. address my particular concerns, but I respect the right of operators to assert they want certain layering principles adhered to, if in their opinion that is the solution they need, because they have certain architectural precepts they believe good operations are built on. As in so much of technology it is not always the point issue that is the driving, it is everything else that is being leveraged based on certain assumptions. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: claude.kawa@sympatico.ca Subject: Re: Re: ITU-T FR draft Date: Fri, 14 Nov 2003 10:01:25 -0500 Lines: 61 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Cc: Danny McPherson , , Jon Peterson X-From: pwe3-admin@ietf.org Fri Nov 14 16:02:14 2003 Return-path: To: Luca Martini , Yaakov Stein 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 The objective of the contributors to ITU-T SG17 draft Recommendation on frame relay/MPLS (X.84) is to ensure that it is aligned with regard to the terminolgy and capabilities with PWE3 draft. Claude > > From: Luca Martini > Date: 2003/11/13 Thu PM 06:12:04 EST > To: Yaakov Stein > CC: Danny McPherson , pwe3@ietf.org, > Jon Peterson > Subject: Re: [PWE3] ITU-T FR draft > > My understanding is that Claude ( FR editor ) is making sure this is the > case today. > > What is the problem Yakov ? > > Luca > > Danny McPherson wrote: > > > > > I think this is fine, so long as the IETF document is aligned > > with the goals and consensus of the WG and the IETF. Do you > > foresee any potential reasons why this might not be the case? > > > > -danny > > > > > > On Nov 11, 2003, at 6:49 PM, Yaakov Stein wrote: > > > >> Dear WG chairs and everyone, > >> > >> I would like to re-iterate my suggestion that the IETF and > >> ITU-T SG17 work together to produce a single harmonized > >> FR draft. > >> > >> Since SG17 has adopted the PWE3 terminology, > >> and there is great overlap in authors of the PWE and ITU drafts, > >> it should be possible to make the documents precisely identical. > >> > >> This has been done before (e.g. Megaco/H.248) > >> and has the advantage of ensuring that there can be > >> no minor issues that can later crop up due to different > >> wording. > >> > >> Y(J)S > >> > > > > > > _______________________________________________ > > 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: Heiles Juergen Subject: AW: last call on control and ethernet drafts Date: Fri, 14 Nov 2003 17:15:33 +0100 Lines: 239 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Fri Nov 14 17:17:24 2003 Return-path: To: "'Scott Kotrla'" , m_seery@yahoo.com, "'Ali Sajassi'" X-Mailer: Internet Mail Service (5.5.2656.59) 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, I agree that a network operator needs a end-to-end supervision of the service. For the pwe3 case I therefore understood the proposal to include the FCS as the original definition didn't support it. For the 802.1ad case I have problem to understand the need for an additional FCS as I think the existing FCS can be used for the end-to-end service supervision. May be it is as misunderstanding of the Ethernet process on my side. The Ethernet frame from the customer has a FCS. At the ingress UNI all frames with wrong FCS are dropped. So you forward only frames with correct FCS into the network. When you add now an additional FCS it is not different from the already existing FCS, both indicate good frames. 802.1ad now manipulates the frame by adding the provider tag. This is similar to what .1q bridges are already doing today. These changes have to be reflected in the FCS. 802.1q says the following: NOTE-There are two possibilities for recreating a valid FCS. The first is to generate a new FCS by algorithmically modifying the received FCS, based on knowledge of the FCS algorithm and the transformations that the frame has undergone between reception and transmission. The second is to rely on the normal MAC procedures to recalculate the FCS for the outgoing frame. The former approach may be preferable in terms of its ability to protect against increased levels of undetected frame errors. ISO/IEC 15802-3, Annex G, discusses these possibilities in more detail. The frame_check_sequence parameter of the Enhanced Internal Sublayer Service (7.1) is able to signal the validity, or otherwise, of the FCS; an unspecified value in this parameter in a data request indicates to the transmitting MAC that the received FCS is no longer valid, and the FCS must therefore be recalculated. For a end-to-end supervision the first approach has to be used. It means that for the outgoing FCS the incoming FCS is used and it is modified according to the frame modifications. This means that errors that occur within the bridge are covered and will be detected. 802.1d Annex G provides examples on how this can be achieved. One question to the Ethernet community: What is the usual FCS procedure for .1q bridges modification or new calculation? What would it be for .1ad bridges? The frame now passes through the network and comes to the egress UNI or may be dropped before due to a FCS error. Both, the original and the new FCS have the same coverage as they start with a no error value at he ingress UNI and are checked at the egress UNI. So the additional FCS provides no additional information in my view, as the standard FCS also covers internal errors of a bridge. Only in case incoming customer frames with wrong FCS are not dropped at the ingress UNI and forward into the provider network the additional FCS is useful as in this case the network coverage of both FCS would be different. Scott you mentioned that the egress counter tells you if the service provider network corrupted the packet. This counter will not give you the whole picture as Ethernet frames could be dropped at intermediate nodes in case of wrong FCS. The egress counter tells you only the frames with wrong FCS on the last link or you have to disable drop in case of wrong FCS at the intermediate notes. Regards Juergen > -----Ursprungliche Nachricht----- > Von: Scott Kotrla [mailto:scott.kotrla@mci.com] > Gesendet: Donnerstag, 13. November 2003 15:09 > An: m_seery@yahoo.com; 'Ali Sajassi' > Cc: pwe3@ietf.org; stds-802-1@ieee.org > Betreff: RE: [PWE3] last call on control and ethernet drafts > > > Let me start by clarifying something that may be leading to some > confusion. MCI is pushing for an end-to-end FCS in both > 802.1ad and in > Pseudowires. Think of stacked VLANs spokes running across a > network of > switches into a Pseudowire Core connected via a network of routers. I > think we have agreed in PWE3 that carrying an end-to-end FCS > should be a > service provider option and the drafts will be modified > accordingly. I > have now moved on to pushing for the same option in 802.1ad. Since > there were still discussions going on in PWE3 when I started > posting to > the 802.1 listserv earlier this week, I started copying 802.1 > on my PWE3 > replies since my response were valid to both groups. > > I completely agree that it is theoretically possible to construct > switches that are not anymore likely to corrupt packets than > a CRC32 is > to not catch a corrupt packet. > > It is also possible to build a network that can never be misconfigured > and that never has any problems. This argument could be used to wish > away all OAM tools. If one builds the perfect network, a lot > of things > become a lot easier and a lot of tools would never be used. > > Being able to detect errors in switches is a requirement from MCI. > However, MCI is not convinced that every piece of gear ever > deployed in > the network will always meet those requirements, even if the equipment > providers promise that they do. > > Equipment has always had bugs and it will always have bugs. > Even if the > equipment design makes unknown packet corruption highly > improbable, the > reality of some implementations will be holes that permit > unknown packet > corruption. Convincing me that no equipment provider that claims to > meet the requirement of unknown packet corruption could ever get a box > into the network that doesn't meet that requirement will be > very tough. > There are too many variables. I completely agree with > service provider > rights to save 4 bytes and not turn the feature on, but I stand by my > assertion that any service provider who understands the risks will be > willing to sacrifice 4 bytes. > > Regarding hardware costs, 802.1ad interfaces are likely going > to require > new hardware. I am highly suspicious of the assertion that stacking 4 > bytes on ingress and doing an extra CRC check on egress on new 802.1ad > hardware will have any significant impact on cost. I agree > that adding > this feature on existing hardware might be cost prohibitive in some > cases. > > As far as the importance of detecting end-to-end errors versus > diagnosing where the errors are happening, I think I have stated this > several times already. If I don't know that my network is running > clean, how do I troubleshoot a customer call? I have to guarantee and > be able to demonstrate beyond a reasonable doubt that my network is > clean, and trying to walk the customer through the internal > workings of > a dozen boxes is much more difficult and less convincing than showing > them egress FCS error counters. If I know there is a > problem, I have a > lot of tools at my disposal, depending on the seriousness of the > problem. First of all, I can root cause my FCS errors to figure out > which boxes/interfaces all affected customer traffic are > going through. > If enough customer packets are being corrupted that the service is > unusable, I can do intrusive monitoring and loopbacks. If service is > not being impacted so severely, I can diagnose the problem during a > maintenance window. If the equipment is reliable as it should be, I > shouldn't be doing this often anyway. > > Thanks, > > Scott > > > -----Original Message----- > From: mark seery [mailto:m_seery@yahoo.com] > Sent: Thursday, November 13, 2003 1:17 AM > To: Ali Sajassi > Cc: Scott Kotrla; pwe3@ietf.org; stds-802-1@ieee.org > Subject: Re: [PWE3] last call on control and ethernet drafts > > Ali, > > Sorry to see this is testing your endurance threshold (as measured by > double !s), and anything I am doing to contribute to that. > > I understand your frustration at people throwing solutions at you and > not requirements - this is obviously an oft-expressed angst > by engineers > > in many different contexts. However, I think it is natural for > experienced operators to offer their opinions on a solution, and can > help sometimes to flush out the issues. I do agree that to deviate to > far from a focus on the requirements is a dangerous path to travel in > the long-term, so good to bring it back to that, but given > the general > scarcity of input from carriers, a little leeway might be > constructive. > > As I stated in my last email, I do see how a single FCS can > work, based > on the draft from andy et el. I have seen you consistently > suggest that > solving the problems for all modes is desired - and I agree. > I have seen > > others say this is not achieveable. Unfortunately I missed > your proposal > > on how it is achieveable, and the technical critique from > others on how > it is not - I'll look back at the april/september entrails to > re-educate > > myself. > > While I agree that solving for all modes is best, and ultimately the > test of whether PW is a good layer - or at the least a > consistent layer, > > if people seem to be focused heavily on the EPL case, that might be > suggestive of where their interest lay. > > Personally, I think stating a requirement such as "like a > transmission > facility" is a good starting point, but ultimately does provide > engineers anything constructive to design towards, it would > be nice if > someone could turn that general requirement in to something more > specific, then all your comments like "probability of undetectable > errors" would come more into focus. > > I am not sure I agree with your observations about loopbacks. > It is not > clear to me that it is impossible to construct non-intrusive > tests with > sufficient samples. I obviously missed that explanation as well. In > addition, there is a distinction between the process of detecting an > error and the process of diagnosing one - which is a point > that has been > > made by others. I missed that distinction in your comments. > > I am not sure I understand your comments about IEEE 802.1ad > compatibility. Even though I can see how one FCS might be > sufficient, if > > a PW used two, I am not sure how this creates a compatibility > problem as > > I don't forsee an "existing" bridge being in the middle of a PW. > > I do think the issue about cost is something I would have > preferred the > carrier representatives to have picked up on and commented on > - but they > > probably can not give an intelligent response without a meaningful > estimate of cost difference. If their answer is its your job > to get the > costs in line, we aint doing it with this functionality, well then I > suggest that should probably spark a set of offline > discussions. And the > > cost discussion is obviously not just pertinent to the double > FCS case, > the zero FCS case clearly provides for an interesting set of > discussions > > between incumbent vendors and customers (one that is beyond me how I > personally would gain by promoting, but it is clear to me how it is a > worthy discussion for some set of agents in the value chain to have). > > > > > > _______________________________________________ > 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: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Thu, 13 Nov 2003 15:38:08 -0700 Lines: 89 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ali Sajassi , Scott Kotrla , stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 14 17:23:04 2003 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, fr, de, ru, ja, zh To: Mark Seery 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 Mark, In order to find out what PWE3 does or doesn't need to do, I'd like to restate the problem. Ethernet networks, consisting of IEEE 802 media and IEEE 802 bridges, today offer a service that delivers a certain level data integrity assurance. This is necessarily the minimum level of assurance that we want Metro Ethernet to supply. Any less would violate the unstated and unknown assumptions made by any number of protocols that will be using a Metro Ethernet Service. I take as a given (having sold them) that networks consisting of IEEE P802.1ad Provider Bridges, Ethernets, and Pseudowires will be built. To put it another way, P802.1ad Provider Bridges will be an important "user" of Pseudowires. Provider Bridges will be almost identical from IEEE 802.1Q bridges. In particular, they will not introduce any new mechanism, such as carrying a customer frame's encapsulated FCS inside an outer FCS. That would require more changes to the IEEE 802.1Q spec that 802.1 is willing to make on this pass. Therefore, the only model available to P802.1ad Metro Ethernets for preserving data integrity is exactly that employed today by 802.1Q. This model makes the extremely important assumption that the world consists solely of 802 media and 802 bridges. In particular: 1. All 802 media provide the same 32-bit Frame Check Sequence (FRC == CRC, Cyclic Redundancy Check). 2. Bridges are prohibited from introducing undetected errors at a rate significantly greater than that of a single hop over an 802 medium. There are a number of techniques by which a bridge can handle requirement 2. They've been mentioned in this thread and don't need to be gone over again. End-to-end preservation of the Customer's original FCS is an interesting proposition, but is not relevant to this formulation of the problem. What is important is that, unless a Pseudowire can make at least as good a guarantee about data integrity as a physical Ethernet can make, then it cannot be of any use to a P802.1ad Provider Bridge. Now, while one can argue that a Pseudowire *might* be carried only over Ethernet physical media, that is clearly insufficient. The only solution is for there to be a version of Pseudowires that incorporate the IEEE 32-bit CRC, or something even stronger, with every Ethernet frame. This requirement has nothing to do with whether end-to-end CRC is employed; it depends simply on the fact that a Pseudowire is not useful to a major class of devices, namely bridges, unless it carries at least an Ethernet CRC. -- Norm Mark Seery wrote: > Hi Ali, > > */Ali Sajassi /* wrote: > > > a) If they don't detect, then they basically violate the basic > requirement > of "keeping the integrity of FCS" > > > Ultimately, the issue may not be the integrity of FCS but the integrity > of the payload. If the payload and a FCS become separated, and the > payload gets corrupted before/while a new FCS is being generated, what > has protected the integrity of the payload. Serious concern for people > doing financial transactions as an example. > > While I personally believe networks should be build so the layer that > creates the PDU does the end-to-end check (so that service providers can > do interworking for example without worrying about essentially the same > issue and remembering that Ethernet is in some people's minds a link > layer), it might be that service providers do not have control over > their subscribers, and it might be that technologies built historically > relying on link layer checks are at risk; and I suppose it could be > argued that a PW is a virtual link layer - though I think that is debatable. > > So while I personally believe that we should not try to solve a PWE > integrity problem (perceived or otherwise) by making use of an Ethernet > FCS, if there is an integrity of the payload problem, that might be a > different issue. > > >> b) If they introduce an error and they cannot detect it and > the end-point detects it, then how do you know where the error occurred > and how do you trouble shoot << > > Historically, service providers have used sectionalized (section, path, > segment, end-to-end, near end, far end,.....) OAM mechanisms within the > transport layer to achieve ongoing measurements, and theoretically > recorded for retroactive inspection, to achieve such insights (not > wishing to ignite another round of OAM discussions , just an observation). > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Keith Knightson Subject: Re: [802.1] RE: last call on control and ethernet drafts Date: Fri, 14 Nov 2003 10:28:38 -0500 Lines: 31 Sender: pwe3-admin@ietf.org References: <8052E2EA753D144EB906B7A7AA399714E5F974@mailserv.hatteras.com> <3FB41A95.9060203@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Scott Kotrla , m_seery@yahoo.com, Ali Sajassi , pwe3@ietf.org, stds-802-1@ieee.org, "Andrew G. Malis" X-From: pwe3-admin@ietf.org Fri Nov 14 17:48:07 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <3FB41A95.9060203@cisco.com> To: Luca Martini , Matt Squire X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.72.56] using ID at Fri, 14 Nov 2003 11:46:35 -0500 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 4:58 PM -0700 13/11/03, Luca Martini wrote: >Scott, > >I still believe that the end to end FCS is the application layer >task, however all network elements should have means to guarantee >that data does not get corrupted while transiting the box. Luca, This is a key point... What assumptions are people making about what is being carried as payload?. If IP/TCP is carried as 802 payload then maybe FCS is not so important. If something else is being carried, it may be on the assumption that no extra error checking was necessary because the FCS (was thought to be) end-to-end. If people are saying that this never was really the case, because FCS's were never end-to-end anyway (when via bridges, etc), then nothing needs to be done. Applications were already operating under a false illusion but so what, nothing has really changed. However, if applications operating over 802 (without IP/TCP) really need error checks, then either it has to be done at the 802 level or at the application level as you say. So either applications have to change or PWE has to change. Which is it to be? Regards Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: [802.1] RE: last call on control and ethernet drafts Date: Fri, 14 Nov 2003 10:09:18 -0800 Lines: 42 Sender: pwe3-admin@ietf.org References: <8052E2EA753D144EB906B7A7AA399714E5F974@mailserv.hatteras.com> <3FB41A95.9060203@cisco.com> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Fri Nov 14 19:10:07 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Keith Knightson 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 Keith Knightson wrote: > > If something else is being carried, it may be on the assumption that > no extra error checking was necessary because the FCS (was thought to > be) end-to-end. If people are saying that this never was really the > case, because FCS's were never end-to-end anyway (when via bridges, > etc), then nothing needs to be done. Applications were already > operating under a false illusion but so what, nothing has really changed. Keith, the technical issues you and Heiles are raising are very good. there are non-technical issues to be considered whether in this forum or another. the process of problem determination in any network, using any technology, is essentially: isolate, isolate, isolate, gotcha (having had to do it may times) when one network manager has a financial relationship with another, then the first level of isolation is: is the problem in my network or yours. the expediancy with which a subscriber can say, well you didn't give me back what I gave you, greatly improves this process. if there is any doubt whatsoever about what happened within the service provider's network, then this process becomes more difficult. so while I see the technical merits of approaches being suggested, and wanted to confine my comments to that, these kinds of issues are also floating around. in addition, in the U.S., some large LECs would not put a PE at a customer premise for regulatory reasons, some would. It comes down to how conservative the LEC is at interpretating out dated and imprecise regulation, and uncertainty about how that regulation might be changed, or not, in the near future. I realise the PE being at the customer site might not be the usual case, but thought I would bring it up for consideration anyway. a traditional transport approach should get around such regulatory concerns, but things like QoS treatment get to be a problem as well sometimes (not relevant to this discussion, just an FYI). best, mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Sat, 15 Nov 2003 22:24:17 -0500 Lines: 213 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Sun Nov 16 04:26:07 2003 Return-path: To: "'Shahram Davari'" , "Busschbach, Peter B (Peter)" , "'neil.2.harrison@bt.com'" , tnadeau@cisco.com, pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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 Thanks, Sharam. This helps. Please see in-line for further comments. Peter > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, November 13, 2003 10:55 AM > To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; > tnadeau@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? > > > Hi Peter, > > There are 2 major things wrong with this draft: > > 1) The draft advocates extending ATM/FR across the PW and doing > ATM-FR Service interworking at only one PE. Meaning that > interworking between > ATM/FR and MPLS (aka PW) is Network interworking, and > interworking between > ATM-FR is Service interworking. But it asks for ATM-PW-FR > Service interworking at both PEs. This is architecturally > wrong, because at one of the PEs you are doing Network > interworking (between ATM/FR and PW) for the data-plane but > doing Service interworking (between ATM/FR and PW) for the > Management plane. The document mentions both Network Interworking (figures 3 and 4) and Service Interworking (figure 5). I think that much of the text was indeed written with Service Interworking in mind. Tom already mentioned that this would be straightened out in the next version of the paper. > > 2) The draft advocates the mapping of CC and loopback between > ATM/FR and MPLS in > sections 4.7 and 4.8. Again, this is fundamentally wrong, > since only the states and > AIS needs mapping and not the CC or LB messages. Same comment: the text makes sense for Service Interworking. You are right that it does not belong in a document that discusses Network Interworking. > > Hope that answers yours question. > > Yours, > -Shahram > > >-----Original Message----- > >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > >Sent: Thursday, November 13, 2003 10:08 AM > >To: Shahram Davari; Busschbach, Peter B (Peter); > >'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >Subject: RE: [PWE3] Adopt > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > >If you read the draft, you must have noticed that it discusses > >predominantly how to map up and down states to FDI and RDI. > >Therefore, I don't understand what prompted your first email. > >Could you explain more explicitly what you think is wrong > >about the draft? > > > >Thanks, > > > >Peter > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: Wednesday, November 12, 2003 11:54 PM > >> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; > >> tnadeau@cisco.com; pwe3@ietf.org > >> Subject: RE: [PWE3] Adopt > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> WG draft? > >> > >> > >> No, I have actually read it. > >> > >> -Shahram > >> > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > >> >Sent: Wednesday, November 12, 2003 4:08 PM > >> >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; > >> >pwe3@ietf.org > >> >Subject: RE: [PWE3] Adopt > >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >WG draft? > >> > > >> > > >> >Sharam, > >> > > >> >Are you commenting on the draft, or are you just guessing what > >> >you might find in the draft if you actually read it? > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >> Sent: Wednesday, November 12, 2003 12:04 PM > >> >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >> >> Subject: RE: [PWE3] Adopt > >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> WG draft? > >> >> > >> >> > >> >> Right. So only AIS/FDI and Down state are mappable. The down > >> >> state of MPLS layer (using CV or periodic ping) is used to > >> >> generate AIS on the client layer (i.e., ATM, or FR). Also an > >> >> FDI in MPLS layer could be used to generate AIS on client > >> >> layer (ATM/FR). > >> >> > >> >> If the PEs don't support transport of ATM/FR AIS/RDI, then in > >> >> theory it is possible (although not architecturally clean) to > >> >> use some sort of signaling/message in MPLS network to inform > >> >> the egress PE to generate the AIS/RDI on the ATM/FR connections. > >> >> > >> >> -Shahram > >> >> > >> >> > >> >> > >> >> >-----Original Message----- > >> >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >> >> >Sent: Wednesday, November 12, 2003 12:45 PM > >> >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >> >> >Subject: RE: [PWE3] Adopt > >> >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> >WG draft? > >> >> > > >> >> > > >> >> >Hi Shahram.....to be strictly accurate here, in a > >> >> >client/server networking I/W case the only server->client OAM > >> >> >function mapping that is relevent is FDI (or AIS in old > >> >> >currency). RDI stays within the layer/trail it is relevant > >> >> >to.....it has no upwards mapping from server->client in a > >> >> >'backwards direction' (if you see what I mean) but terminates > >> >> >at the trail sink of the return direction (if one exists). > >> >> > > >> >> >Otherwise I agree with your remarks. > >> >> > > >> >> >regards, Neil > >> >> >> -----Original Message----- > >> >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >> >> Sent: 12 November 2003 16:49 > >> >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >> >> >> Subject: RE: [PWE3] Adopt > >> >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> >> WG draft? > >> >> >> > >> >> >> > >> >> >> Hi, > >> >> >> > >> >> >> The only OAM function that is mappable in a network > >> >> >> interworking case (e.g., PW) > >> >> >> is AIS/RDI and up/down state. Any other type of mapping is > >> >> >> not only architecturally wrong, but not required. > >> >> >> > >> >> >> So I suggest that first we have a debate on the higher level > >> >> >> architectural issues > >> >> >> and requirements before accepting this draft. > >> >> >> > >> >> >> Yours, > >> >> >> -Shahram > >> >> >> > >> >> >> > >> >> >> >-----Original Message----- > >> >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> >> >> >Sent: Monday, November 10, 2003 10:47 PM > >> >> >> >To: pwe3@ietf.org > >> >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt > >> >> >as PWE3 WG > >> >> >> >draft? > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > The chairs requested that we take the > >> >> >> >matter of adoption of this draft to the > >> >> >> >list. Please comment. > >> >> >> > > >> >> >> > --Tom > >> >> >> > > >> >> >> > >>http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg- > m > > >> >> ap-03.txt > > >> >> > > >> >> > > >> >> > > >> >> _______________________________________________ > > >> >> 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 > > >> > > > > > > > _______________________________________________ > 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: Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Date: Sun, 16 Nov 2003 13:43:34 +0100 Lines: 249 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: "Shahram Davari" , , "Tom Nadeau (tnadeau)" , X-From: pwe3-admin@ietf.org Sun Nov 16 13:45:12 2003 Return-path: Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 WG draft? Thread-Index: AcOr8ZzA3eCbxMThT0ao1Zbx/IbAFAAQCCjg To: "Busschbach, Peter B (Peter)" X-OriginalArrivalTime: 16 Nov 2003 12:43:35.0486 (UTC) FILETIME=[4019DDE0:01C3AC3F] 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 Belated response to this thread as I have been in travel mode: "Same comment: the text makes sense for Service Interworking. You are = right that it does not belong in a document that discusses Network = Interworking." Correct -- we will align draft text in the next revision . Also, as far as service interworking is concerned, and ITU-T SG 13 = activity, Q.5 has not yet produced a definition, and therefore is work = under progress. /m -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = Busschbach, Peter B (Peter) Sent: 16 November 2003 04:24 To: 'Shahram Davari'; Busschbach, Peter B (Peter); = 'neil.2.harrison@bt.com'; Tom Nadeau (tnadeau); pwe3@ietf.org Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 = WG draft? Thanks, Sharam. This helps. Please see in-line for further comments. Peter > -----Original Message----- > From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > Sent: Thursday, November 13, 2003 10:55 AM > To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; > tnadeau@cisco.com; pwe3@ietf.org > Subject: RE: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > WG draft? >=20 >=20 > Hi Peter, >=20 > There are 2 major things wrong with this draft: >=20 > 1) The draft advocates extending ATM/FR across the PW and doing > ATM-FR Service interworking at only one PE. Meaning that=20 > interworking between > ATM/FR and MPLS (aka PW) is Network interworking, and=20 > interworking between > ATM-FR is Service interworking. But it asks for ATM-PW-FR=20 > Service interworking at both PEs. This is architecturally=20 > wrong, because at one of the PEs you are doing Network=20 > interworking (between ATM/FR and PW) for the data-plane but=20 > doing Service interworking (between ATM/FR and PW) for the=20 > Management plane. The document mentions both Network Interworking (figures 3 and 4) and = Service Interworking (figure 5). I think that much of the text was = indeed written with Service Interworking in mind. Tom already mentioned = that this would be straightened out in the next version of the paper. >=20 > 2) The draft advocates the mapping of CC and loopback between=20 > ATM/FR and MPLS in > sections 4.7 and 4.8. Again, this is fundamentally wrong,=20 > since only the states and > AIS needs mapping and not the CC or LB messages. Same comment: the text makes sense for Service Interworking. You are = right that it does not belong in a document that discusses Network = Interworking. >=20 > Hope that answers yours question. >=20 > Yours, > -Shahram >=20 > >-----Original Message----- > >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > >Sent: Thursday, November 13, 2003 10:08 AM > >To: Shahram Davari; Busschbach, Peter B (Peter); > >'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >Subject: RE: [PWE3] Adopt=20 > draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >WG draft? > > > > > >If you read the draft, you must have noticed that it discusses=20 > >predominantly how to map up and down states to FDI and RDI.=20 > >Therefore, I don't understand what prompted your first email.=20 > >Could you explain more explicitly what you think is wrong=20 > >about the draft? > > > >Thanks, > > > >Peter > > > >> -----Original Message----- > >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> Sent: Wednesday, November 12, 2003 11:54 PM > >> To: 'Busschbach, Peter B (Peter)'; 'neil.2.harrison@bt.com'; > >> tnadeau@cisco.com; pwe3@ietf.org > >> Subject: RE: [PWE3] Adopt=20 > >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> WG draft? > >>=20 > >>=20 > >> No, I have actually read it. > >>=20 > >> -Shahram > >>=20 > >> >-----Original Message----- > >> >From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] > >> >Sent: Wednesday, November 12, 2003 4:08 PM > >> >To: Shahram Davari; 'neil.2.harrison@bt.com'; tnadeau@cisco.com; > >> >pwe3@ietf.org > >> >Subject: RE: [PWE3] Adopt=20 > >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >WG draft? > >> > > >> > > >> >Sharam, > >> > > >> >Are you commenting on the draft, or are you just guessing what=20 > >> >you might find in the draft if you actually read it? > >> > > >> >Peter > >> > > >> >> -----Original Message----- > >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >> Sent: Wednesday, November 12, 2003 12:04 PM > >> >> To: 'neil.2.harrison@bt.com'; tnadeau@cisco.com; pwe3@ietf.org > >> >> Subject: RE: [PWE3] Adopt=20 > >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> WG draft? > >> >>=20 > >> >>=20 > >> >> Right. So only AIS/FDI and Down state are mappable. The down=20 > >> >> state of MPLS layer (using CV or periodic ping) is used to=20 > >> >> generate AIS on the client layer (i.e., ATM, or FR). Also an=20 > >> >> FDI in MPLS layer could be used to generate AIS on client=20 > >> >> layer (ATM/FR). > >> >>=20 > >> >> If the PEs don't support transport of ATM/FR AIS/RDI, then in=20 > >> >> theory it is possible (although not architecturally clean) to=20 > >> >> use some sort of signaling/message in MPLS network to inform=20 > >> >> the egress PE to generate the AIS/RDI on the ATM/FR connections. > >> >>=20 > >> >> -Shahram > >> >>=20 > >> >>=20 > >> >>=20 > >> >> >-----Original Message----- > >> >> >From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > >> >> >Sent: Wednesday, November 12, 2003 12:45 PM > >> >> >To: Shahram Davari; tnadeau@cisco.com; pwe3@ietf.org > >> >> >Subject: RE: [PWE3] Adopt=20 > >> >> draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> >WG draft? > >> >> > > >> >> > > >> >> >Hi Shahram.....to be strictly accurate here, in a=20 > >> >> >client/server networking I/W case the only server->client OAM=20 > >> >> >function mapping that is relevent is FDI (or AIS in old=20 > >> >> >currency). RDI stays within the layer/trail it is relevant=20 > >> >> >to.....it has no upwards mapping from server->client in a=20 > >> >> >'backwards direction' (if you see what I mean) but terminates=20 > >> >> >at the trail sink of the return direction (if one exists). > >> >> > > >> >> >Otherwise I agree with your remarks. =20 > >> >> > > >> >> >regards, Neil > >> >> >> -----Original Message----- > >> >> >> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com] > >> >> >> Sent: 12 November 2003 16:49 > >> >> >> To: 'tnadeau@cisco.com'; pwe3@ietf.org > >> >> >> Subject: RE: [PWE3] Adopt=20 > >> >> >draft-nadeau-pwe3-oam-msg-map-03.txt as PWE3 > >> >> >> WG draft? > >> >> >>=20 > >> >> >>=20 > >> >> >> Hi, > >> >> >>=20 > >> >> >> The only OAM function that is mappable in a network=20 > >> >> >> interworking case (e.g., PW) > >> >> >> is AIS/RDI and up/down state. Any other type of mapping is=20 > >> >> >> not only architecturally wrong, but not required. > >> >> >>=20 > >> >> >> So I suggest that first we have a debate on the higher level=20 > >> >> >> architectural issues > >> >> >> and requirements before accepting this draft. > >> >> >>=20 > >> >> >> Yours, > >> >> >> -Shahram > >> >> >>=20 > >> >> >>=20 > >> >> >> >-----Original Message----- > >> >> >> >From: Thomas D. Nadeau [mailto:tnadeau@cisco.com] > >> >> >> >Sent: Monday, November 10, 2003 10:47 PM > >> >> >> >To: pwe3@ietf.org > >> >> >> >Subject: [PWE3] Adopt draft-nadeau-pwe3-oam-msg-map-03.txt=20 > >> >> >as PWE3 WG > >> >> >> >draft? > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > The chairs requested that we take the > >> >> >> >matter of adoption of this draft to the > >> >> >> >list. Please comment. > >> >> >> > > >> >> >> > --Tom > >> >> >> > > >> >> >>=20 > >>http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg- > m > > >> >> ap-03.txt > > >> >>=20 > > >> >>=20 > > >> >>=20 > > >> >> _______________________________________________ > > >> >> pwe3 mailing list > > >> >> pwe3@ietf.org > > >> >> https://www1.ietf.org/mailman/listinfo/pwe3 > > >> >>=20 > > >> >> _______________________________________________ > > >> >> pwe3 mailing list > > >> >> 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 > > >>=20 > > > > >=20 >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 >=20 _______________________________________________ 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: "Mick Seaman" Subject: 802.1 specification of a bridge - FCS being an example Date: Fri, 14 Nov 2003 23:04:01 -0800 Lines: 129 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Sun Nov 16 23:27:04 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 For anyone new to the style of, and self-imposed limits upon, 802.1 specifications, the following may be useful (and not just as it applies to the FCS discussion - see email extract below (which by the way I think is an entirely sensible question). 802.1 contains a fairly detailed model of a bridge, necessary to express its observed external behavior. However it contains (in clause 7.3) the following text: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." This principle - that a specification only describes external behavior and not how a particular item of equipment is built - was a very strongly held belief amongst the members of the committee at the time 802.1D was first developed, and I would note that some of them are still round the committee, most are still around the industry, and many are IEEE SA members fully entitled to vote on sponsor ballots. I would therefore rate the chance of successfully amending this clause (or the similar one in 802.1Q) whether directly or by stealth (by mandating implementation internals elsewhere in the spec) in any future 802.1 amendment or revision as negligible. [It took me (personally) a very considerable effort to get the treatment of FCS as far as it is. Considerable opposition came from those who were using MAC chips that could not take the FCS as a transmission parameter and there was much argument as to the plausibility of conformance verification by testing, but it was established that the requirement could be verified. We didn't at the time go as far as I would have liked, but I accepted the limits of the outcome, and in common with some other arguments which I have somewhat lost, I do feel honor bound to respect and use my energies to preserve this outcome (not least because if all outcomes are up for grabs all the time the spec would flap around like a fish, which is bad for all outcomes not just ones I would personally like to tweak).] The consequence of the "may adopt any internal model of operation compatible with the externally visible behavior" might not be readily apparent to all in the context of this FCS discussion, so let me spell it out. It means that if the chance/frequency of undetected errors being introduced in frame stored within a particular bridge implementation is no more likely than such errors arising in the transmission medium, that any spec to carry the received FCS through the bridge and append an additional FCS to the transmitted frame could be validly achieved on transmission by calculating both those FCSes at transmission time, i.e. calculating both the "original" and the "new complete frame". Given that 802.1ad allows a number of different interfaces to a provider bridge network for any service instance (for example a provider router might service multiplex by "customer VLAN" a number of service instances that are to be delivered at individual ports to specific customers without the tagging) there is some doubt as to what the "original frame" comprises when it is final delivered. The obvious way out of that bind would be to decide on some definition of the "essential frame" for the inner FCS, whether that is the frame once the provider stuff has been removed at any point in the net or not. This becomes easier if you spec the "inner" FCS over some specific data fields and calculate both "inner" and "outer" at transmission time on or near the final hop to the customer. Of course you could always try to tell the originating interface what the final form of the frame was going to be :-) so the input interface could calculate the right one (if the destination doesn't move). The two FCSes look pretty much in specification terms like a new MAC to the bridge. It is not so trivial to cover services that are not just point to point wires with new "end to end" requirements. Given that, it is sure tempting just to fix the newly invented substandard parts of the network. Then the frame errors can be localized because the frame will get dropped by the bridge receiving from the new inferior media. To answer the question in the attached email as best I can. As per the above, the .1ad spec cannot mandate where in the implementation values are calculated. Obviously frames with bad FCS on receipt are discarded, and the chance of incorrectly changed data being sent with a valid FCS should be verifiably low (given enough test systems and time). Early bridges spanned the range of permissiveness and paranoia. Some bridges used chips which would not accept the FCS on transmission, and had average cheap memories. The early DEC Ethernet-FDDI bridges were very cautious and paranoid. While not calculating FCS differences as per Annex G, they overlapped FCS coverage as the frames passed through the format conversion chips i.e. the FCS received (call it FCS-R) was recalculated over the fields that should contribute to FCS-R after the frame modifications were made and the FCS to be used for transmission (call it FCS-T) has been calculated and associated with the frame. The circuit design takes some care and verification, but the method can be very good. Nowadays I believe most bridges from reputable suppliers use memories whose characteristics are such that the frame data is just as likely to have been corrupted in the originating end-stations transmission queue before the very first FCS has been added or the receiving destinations receive queue after the FCS has been verified for the very last time. Mick -----Original Message----- Extract from a message sent by Heiles Juergen ....... 802.1q says the following: NOTE-There are two possibilities for recreating a valid FCS. The first is to generate a new FCS by algorithmically modifying the received FCS, based on knowledge of the FCS algorithm and the transformations that the frame has undergone between reception and transmission. The second is to rely on the normal MAC procedures to recalculate the FCS for the outgoing frame. The former approach may be preferable in terms of its ability to protect against increased levels of undetected frame errors. ISO/IEC 15802-3, Annex G, discusses these possibilities in more detail. The frame_check_sequence parameter of the Enhanced Internal Sublayer Service (7.1) is able to signal the validity, or otherwise, of the FCS; an unspecified value in this parameter in a data request indicates to the transmitting MAC that the received FCS is no longer valid, and the FCS must therefore be recalculated. For a end-to-end supervision the first approach has to be used. It means that for the outgoing FCS the incoming FCS is used and it is modified according to the frame modifications. This means that errors that occur within the bridge are covered and will be detected. 802.1d Annex G provides examples on how this can be achieved. One question to the Ethernet community: What is the usual FCS procedure for .1q bridges modification or new calculation? What would it be for .1ad bridges? From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 08:06:09 -0800 Lines: 31 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> <3FB89971.8030609@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 17:14:05 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Norman Finn In-Reply-To: <3FB89971.8030609@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 Norman Finn wrote: > Mark, > > Sorry for the lag in my reply -- poor 802.11 on an airliner. :) > See in-line Yeah, we really got to extend the range of 802.11 ;-) I guess the bottom line to me is ("philisophically" speaking), if a bridge is merely a user of a PW, then what is the difference between saying a PW has to have a CRC and saying a strand of fiber or copper cable has to have a CRC? If the bridges simply do what they have always done, using their own link layer, and simply use PW as a transport, then seems you maintain the maximum interoperability, are not reliant on other standards bodies (not saying bodies can't work together as 802 and IETF often do very well), and simply treat PW as a "media". If you disagree with this point, then I understand all your other points. I say this of course WRT the way 802 might look at it. Scott's point of view might be that any link has to meet his requirements because like you, he might feel the operator should determine whether something meets his company's definition of grade. While on the subject, with respect to your response to Scott, it might be instructive to know that operators have already had bad experiences with another product class that supported Ethernet, without any tools for doing problem determination, so there might be some sensitivities here on this issue - we are all nothing, if but human ;-) Best, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 08:11:33 -0800 Lines: 17 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> <3FB89971.8030609@cisco.com> <3FB8E4BA.3030101@yahoo.com> <3FB8F0AC.7040906@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 17:20:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Norman Finn In-Reply-To: <3FB8F0AC.7040906@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 Norman Finn wrote: > > In other words, routers pass about $0.93 of the data integrity buck to > bridges, > and bridges pass about $0.75 of that to the data links. The buck has > to stop > somewhere, and the data link is where it stops. The PW has to take > the same > hit as the physical media. > > -- Norm but a PW will be running over a physical media itself already, possibly even SONET............. mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 10:49:14 +0100 Lines: 30 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB44504.20900@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 23:19:05 2003 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, fr, de, ru, ja, zh To: m_seery@yahoo.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 mark seery wrote: > Norman Finn wrote: > >> End-to-end >> preservation of the Customer's original FCS is an interesting >> proposition, but is >> not relevant to this formulation of the problem. > > Norman I disagree. You can't disagree with my assertion about my own formulation of the problem. :) > First of all I don't think I stated it that way, I talked about was > payload integrity. In an X over Y situation, if X is assuming that Y is > maintaining the integrity of X's PDUs, and it does not, then that is a > problem... Mark, I appreciate the lecture on IP philosophy, and I have no argument with the IP philosophy. But you're trying to apply it where it doesn't belong. You're exactly right that it is up to the endpoints to maintain the PDU integrity. What you're missing is where the ends of the PW are. As far as PW are concerned, the endpoints of the Layer 3 service are the ends of the PW, not the Customer's ends over the Provider's Metro Ether. The users of the PW are the bridges, not the Customers. And bridges require a 32-bit CRC on their links in order to do their job properly. -- Norm From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 17:00:44 +0100 Lines: 44 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> <3FB89971.8030609@cisco.com> <3FB8E4BA.3030101@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ali Sajassi , Scott Kotrla , stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 23:19:06 2003 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, fr, de, ru, ja, zh To: m_seery@yahoo.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 Mark, I agree with this point, but it leads me to opposite conclusion. PW is just another medium to a bridge. However, *all* media known to bridges, at least as far as IEEE 802.1 are concerned, are 802 media, and all 802 media have 32-bit CRCs. If you connect a medium that doesn't have at least a 32-bit CRC to a bridge, then the resultant bridged LAN will suffer a significant degradation in its ability to transport frames without error, because bridges depend on reliable media. And then the routers on top of the bridges don't work so well. Routers can get away with their liberal assumptions about reliability only because links and bridges take it very seriously. Right now, the routers depend on the links and the bridges for reliability, and router people sometimes forget that they're taking this reliability for granted. I've used systems where the link-layer CRC was not working, and data dependent errors resulted. IP doesn't work for beans in that environment. In other words, routers pass about $0.93 of the data integrity buck to bridges, and bridges pass about $0.75 of that to the data links. The buck has to stop somewhere, and the data link is where it stops. The PW has to take the same hit as the physical media. -- Norm mark seery wrote: > Hi Norman. > > I guess the bottom line to me is (philisophically speaking), if a bridge > is merely a user of a PW, then what is the difference between saying a > PW has to have a CRC and saying a strand of fiber or copper cable has to > have a CRC? If the bridges simply do what they have always done, using > their own link layer, and simply use PW as a transport, then seems you > maintain the maximum interoperability, are not reliant on other > standards bodies (not saying bodies can't work together as 802 and IETF > often do very well), and simply treat PW as a "media". If you disagree > with this point, then I understand all your other points. > > Best, > Mark > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 07:09:46 -0800 Lines: 14 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> <3FB89971.8030609@cisco.com> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ali Sajassi , Scott Kotrla , stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 23:19:07 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Norman Finn In-Reply-To: <3FB89971.8030609@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 Norman. I guess the bottom line to me is (philisophically speaking), if a bridge is merely a user of a PW, then what is the difference between saying a PW has to have a CRC and saying a strand of fiber or copper cable has to have a CRC? If the bridges simply do what they have always done, using their own link layer, and simply use PW as a transport, then seems you maintain the maximum interoperability, are not reliant on other standards bodies (not saying bodies can't work together as 802 and IETF often do very well), and simply treat PW as a "media". If you disagree with this point, then I understand all your other points. Best, Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Norman Finn Subject: Re: [802.1] RE: last call on control and ethernet drafts Date: Mon, 17 Nov 2003 10:58:13 +0100 Lines: 160 Sender: pwe3-admin@ietf.org References: <000001c3a9ef$abac0080$e28732a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: m_seery@yahoo.com, "'Ali Sajassi'" , pwe3@ietf.org, stds-802-1@ieee.org X-From: pwe3-admin@ietf.org Mon Nov 17 23:19:10 2003 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, fr, de, ru, ja, zh To: Scott Kotrla 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, I conclude from your arguments that bridges live in a fantasy world, and don't actually work. You're clearly wrong. Had you said simply, "Bridges don't work like routers," you'd have been correct. The reason that routers get away with poor error control is they they mostly run over bridges and physical Ethernets, which have excellent error detection. When you run routers over bridges over PW without 32-bit CRCs, the circle is removed one further layer from reality, and threatens to fail. -- Norm Scott Kotrla wrote: > Let me start by clarifying something that may be leading to some > confusion. MCI is pushing for an end-to-end FCS in both 802.1ad and in > Pseudowires. Think of stacked VLANs spokes running across a network of > switches into a Pseudowire Core connected via a network of routers. I > think we have agreed in PWE3 that carrying an end-to-end FCS should be a > service provider option and the drafts will be modified accordingly. I > have now moved on to pushing for the same option in 802.1ad. Since > there were still discussions going on in PWE3 when I started posting to > the 802.1 listserv earlier this week, I started copying 802.1 on my PWE3 > replies since my response were valid to both groups. > > I completely agree that it is theoretically possible to construct > switches that are not anymore likely to corrupt packets than a CRC32 is > to not catch a corrupt packet. > > It is also possible to build a network that can never be misconfigured > and that never has any problems. This argument could be used to wish > away all OAM tools. If one builds the perfect network, a lot of things > become a lot easier and a lot of tools would never be used. > > Being able to detect errors in switches is a requirement from MCI. > However, MCI is not convinced that every piece of gear ever deployed in > the network will always meet those requirements, even if the equipment > providers promise that they do. > > Equipment has always had bugs and it will always have bugs. Even if the > equipment design makes unknown packet corruption highly improbable, the > reality of some implementations will be holes that permit unknown packet > corruption. Convincing me that no equipment provider that claims to > meet the requirement of unknown packet corruption could ever get a box > into the network that doesn't meet that requirement will be very tough. > There are too many variables. I completely agree with service provider > rights to save 4 bytes and not turn the feature on, but I stand by my > assertion that any service provider who understands the risks will be > willing to sacrifice 4 bytes. > > Regarding hardware costs, 802.1ad interfaces are likely going to require > new hardware. I am highly suspicious of the assertion that stacking 4 > bytes on ingress and doing an extra CRC check on egress on new 802.1ad > hardware will have any significant impact on cost. I agree that adding > this feature on existing hardware might be cost prohibitive in some > cases. > > As far as the importance of detecting end-to-end errors versus > diagnosing where the errors are happening, I think I have stated this > several times already. If I don't know that my network is running > clean, how do I troubleshoot a customer call? I have to guarantee and > be able to demonstrate beyond a reasonable doubt that my network is > clean, and trying to walk the customer through the internal workings of > a dozen boxes is much more difficult and less convincing than showing > them egress FCS error counters. If I know there is a problem, I have a > lot of tools at my disposal, depending on the seriousness of the > problem. First of all, I can root cause my FCS errors to figure out > which boxes/interfaces all affected customer traffic are going through. > If enough customer packets are being corrupted that the service is > unusable, I can do intrusive monitoring and loopbacks. If service is > not being impacted so severely, I can diagnose the problem during a > maintenance window. If the equipment is reliable as it should be, I > shouldn't be doing this often anyway. > > Thanks, > > Scott > > > -----Original Message----- > From: mark seery [mailto:m_seery@yahoo.com] > Sent: Thursday, November 13, 2003 1:17 AM > To: Ali Sajassi > Cc: Scott Kotrla; pwe3@ietf.org; stds-802-1@ieee.org > Subject: Re: [PWE3] last call on control and ethernet drafts > > Ali, > > Sorry to see this is testing your endurance threshold (as measured by > double !s), and anything I am doing to contribute to that. > > I understand your frustration at people throwing solutions at you and > not requirements - this is obviously an oft-expressed angst by engineers > > in many different contexts. However, I think it is natural for > experienced operators to offer their opinions on a solution, and can > help sometimes to flush out the issues. I do agree that to deviate to > far from a focus on the requirements is a dangerous path to travel in > the long-term, so good to bring it back to that, but given the general > scarcity of input from carriers, a little leeway might be constructive. > > As I stated in my last email, I do see how a single FCS can work, based > on the draft from andy et el. I have seen you consistently suggest that > solving the problems for all modes is desired - and I agree. I have seen > > others say this is not achieveable. Unfortunately I missed your proposal > > on how it is achieveable, and the technical critique from others on how > it is not - I'll look back at the april/september entrails to re-educate > > myself. > > While I agree that solving for all modes is best, and ultimately the > test of whether PW is a good layer - or at the least a consistent layer, > > if people seem to be focused heavily on the EPL case, that might be > suggestive of where their interest lay. > > Personally, I think stating a requirement such as "like a transmission > facility" is a good starting point, but ultimately does provide > engineers anything constructive to design towards, it would be nice if > someone could turn that general requirement in to something more > specific, then all your comments like "probability of undetectable > errors" would come more into focus. > > I am not sure I agree with your observations about loopbacks. It is not > clear to me that it is impossible to construct non-intrusive tests with > sufficient samples. I obviously missed that explanation as well. In > addition, there is a distinction between the process of detecting an > error and the process of diagnosing one - which is a point that has been > > made by others. I missed that distinction in your comments. > > I am not sure I understand your comments about IEEE 802.1ad > compatibility. Even though I can see how one FCS might be sufficient, if > > a PW used two, I am not sure how this creates a compatibility problem as > > I don't forsee an "existing" bridge being in the middle of a PW. > > I do think the issue about cost is something I would have preferred the > carrier representatives to have picked up on and commented on - but they > > probably can not give an intelligent response without a meaningful > estimate of cost difference. If their answer is its your job to get the > costs in line, we aint doing it with this functionality, well then I > suggest that should probably spark a set of offline discussions. And the > > cost discussion is obviously not just pertinent to the double FCS case, > the zero FCS case clearly provides for an interesting set of discussions > > between incumbent vendors and customers (one that is beyond me how I > personally would gain by promoting, but it is clear to me how it is a > worthy discussion for some set of agents in the value chain to have). > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 10:48:33 +0100 Lines: 60 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ali Sajassi , Scott Kotrla , stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 23:19:12 2003 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, fr, de, ru, ja, zh To: m_seery@yahoo.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 Mark, Sorry for the lag in my reply -- poor 802.11 on an airliner. :) See in-line. mark seery wrote: > > In your long note, I got the impression that your central argument is > that a PW is not Ethernet grade unless it provides 32-bit CRC or better. Exactly right. > I understand 802 wanting to define what meets it standard of goodness. > By mandating this you are suggesting that a range of existing systems, > and potentially chipsets, do not support this requirement - I'll assume > that is a considered judgement from you having weighed all the > implications. I do not make any judgments on what requirements that various non-bridge Ethernet endstations place on Ethernets. That's not my concern. What I am very concerned with is what requirements bridges make on Ethernets. Those requirements are very firm, and a PW that does not have error detection as good as the IEEE 32-bit CDC fails to meet them. To proceed without that ability is therefore risky. > If the standards > are driven in such a way that a new class of equipment is required, then > that's OK with me too, because I am more likely to benefit from that, > than if not. Perhaps inherent in your comments is the thought that > service providers will deploy a new class of specialized provider > bridges that do only that functionality. Perhaps that is possible as > well, though that is unlikely the intent of the IETF PW group, but > understand 802s right to pursue creating this opportunity. You've got it exactly backwards, If I read your comments correctly, Mark. A PW that does not provide a 32-bit CRC would force bridges to behave completely differently than they do now (e.g. end-to-end CRC), which is exactly what is not wanted. There are far more bridges and bridge ports out there than there are routers and router ports. You don't change all the bridge ports to make up for a single new type of "Ethernet" that is lame in the error detection department. You fix the lame "Ethernet": PWs. > On your desire to impress of your real world experience with PW and > bridges, I don't doubt it and I am not sure what I said to inspire that > reaction. As far as I recall all I have said is that I didn't believe > "existing" bridges would be in the middle of a PW [because they don't > speak PW]. Of course not. They'd be at the ends. Also, I wasn't arguing with you in my original mail -- only using your message as a launching point for making the case for CRC in PW. > On the assumption 802 makes that 802 is everywhere, I have no problem > with that as it has served 802 so well, but I would observe that IP/IETF > has thrived by assuming the complete opposite - such is life.... And I'm sure IP will continue to do so. As will 802. -- Norm From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Nick DelRegno Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 16:22:26 -0600 Lines: 60 Sender: pwe3-admin@ietf.org References: <3FB8F335.4040905@interflect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 17 23:25:05 2003 Return-path: In-reply-to: <3FB8F335.4040905@interflect.com> To: "'mark seery'" , "'Norman Finn'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 If the PW transits only the physical media, then the discussion is moot. However, since PWs will likely span multiple physical media, multiple devices, and at the end of the day looks to the 802 bridges like a = physical media, it needs to held to the reliability/tolerance standards = associated with physical media. At the extreme, a PW FCS would provide this functionality. But pragmatically, reuse of the Ethernet/FR/PPP FCS provides similar functionality without major overhaul to the standard. A similar example would seem to be that of SONET Section/Line/Path = overhead and the PM enabled by such segmentation. Why have a path level if we = have a bunch of serial line PMs. Wouldn't that be good enough? Or does it make sense to have a path level check to ensure the integrity of the path? The problem with tunneling of any sort is the loss of visibility within = the tunnel. This makes troubleshooting difficult, but it shouldn't prevent end-to-end tunnel fault detection. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of mark seery Sent: Monday, November 17, 2003 10:12 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman Finn wrote: > > In other words, routers pass about $0.93 of the data integrity buck to = > bridges, > and bridges pass about $0.75 of that to the data links. The buck has=20 > to stop > somewhere, and the data link is where it stops. The PW has to take=20 > the same > hit as the physical media. > > -- Norm but a PW will be running over a physical media itself already, possibly=20 even SONET............. mark _______________________________________________ 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: mark seery Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 17 Nov 2003 18:47:48 -0500 (EST) Lines: 41 Sender: pwe3-admin@ietf.org References: <025b01c3ad59$4833e140$6b01a8c0@nick> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Tue Nov 18 00:48:02 2003 Return-path: To: Nick DelRegno In-Reply-To: <025b01c3ad59$4833e140$6b01a8c0@nick> from Nick DelRegno on Mon, 17 Nov 2003 16:22:26 -0600 Content-Disposition: inline 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 Nick, good comments. See in-line. Regards, Mark ---- Nick DelRegno wrote: > If the PW transits only the physical media, then the discussion is moot. > However, since PWs will likely span multiple physical media, multiple > devices, and at the end of the day looks to the 802 bridges like a > physical media, it needs to held to the reliability/tolerance standards > associated > with physical media. If it is your, and others, opinion that a PW running over a reliable media does not meet those standards, then I accept your judgement. If it is your opinion that we can not predict what a PW will run over, then that is a valid argument as well. If we accept the argument that routers always pass the buck to someone else, then the question has to be asked what has changed here (not withstanding Scott's comments on the merge of transmission and switching which were both insightful and relevant). There is a larger architectural discussion about whether PW is a multiplexing construct or a separate layer which plays into this issue - but that discussion has proven to be one the group has not enjoyed having and therefore remains one of those unlanced boils (with perhaps only a small minority - agreed). > At the extreme, a PW FCS would provide this functionality. But > pragmatically, reuse of the Ethernet/FR/PPP FCS provides similar > functionality without major overhaul to the standard. I am on record as supporting the draft from Malis et el. so no argument on this point. > A similar example would seem to be that of SONET Section/Line/Path overhead and the PM enabled by such segmentation. < Section/line/path discussions have proven to be difficult both in this organization and by the sounds of it (large inferring warning) in the IEEE based on comments made about not wanting to pursue additional overhead (in the form of multiple MAC layers - which would mean painful changes). It could be argued that 802.3ah OAM is a tool which will deal with this problem (and I do agree it has some good capabilities), but ultimately, I am not sure it is the same. At any rate, I understand what it does for you, and I understand why you mention it. > Why have a path level if we have a > bunch of serial line PMs. Wouldn't that be good enough? Or does it make > sense to have a path level check to ensure the integrity of the path? It does indeed make sense to have a path integrity check. Please see my earlier comments on e2e payload integrity. > The problem with tunneling of any sort is the loss of visibility within the tunnel. This makes troubleshooting difficult, but it shouldn't prevent end-to-end tunnel fault detection. < If I thought agreeing with Norman would give you the section/line/path capability you desire, then I would shout "Uncle" in a picosecond, but while I will acknowledge my response to Norman was also not consistent with what you would like (and what I have agreed to support previously), IMHO, until we can separate our thinking into transport layers, services layers, and multiplexing functions, all these discussions become somewhat complex (accept within the group of people who have already agreed on a "path" forward). Using this kind of vocabulary usally invokes an immune response - for both good and bad reasons, IMO. So either we say PW is a service layer similar to IP and leverages the underlying media in the way Norman suggested with his cost model analogy, or we pursue a layered approach which gets us closer to PW being a transmission facility was merely the kind of thinking I was trying to tease out (perhaps I was not skilled I agree). This is of course the kind of interesting discussion you have when you move into a new problem domain, such as transporting a layer 2 protocol over a layer ? (higher than 1) protocol. Not saying we shouldn't do it, just saying that it is entirely understandable why these kinds of discussions are occurring, and ceratinly trust that the various "E's" in IEEE and IETF will work through the issues, well-guided by prospective users of the technology. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 09:56:06 +0100 Lines: 42 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> <3FB89971.8030609@cisco.com> <3FB8E4BA.3030101@yahoo.com> <3FB8F0AC.7040906@cisco.com> <3FB8F335.4040905@interflect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 18 11:45:07 2003 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, fr, de, ru, ja, zh To: mark seery 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 Mark, You say below, > but a PW will be running over a physical media itself already, possibly > even SONET............. Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW is running over known Ethernet links, then I can get away without the CRC in the PW. I have no problem whatsoever with the current definition of PWs without CRC. But, if I don't have tight control over the physical media over which the PW runs, then I really need a CRC on the PW for the bridge to be able to trust the "wire" and thus provide the same level of data integrity that bridges offer over physical Ethernets. So, I claim that bridges need a CRC option on PWs. -- Norm mark seery wrote: > > Norman Finn wrote: > >> >> In other words, routers pass about $0.93 of the data integrity buck to >> bridges, >> and bridges pass about $0.75 of that to the data links. The buck has >> to stop >> somewhere, and the data link is where it stops. The PW has to take >> the same >> hit as the physical media. >> >> -- Norm > > > but a PW will be running over a physical media itself already, possibly > even SONET............. > > mark > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 11:15:35 -0500 (EST) Lines: 25 Sender: pwe3-admin@ietf.org References: <20031112000352.23554.qmail@web13509.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Tue Nov 18 17:17:13 2003 Return-path: To: Norman Finn In-Reply-To: <20031112000352.23554.qmail@web13509.mail.yahoo.com> <3FB407D0.3080803@cisco.com> <3FB436F6.9010600@yahoo.com> <3FB89971.8030609@cisco.com> <3FB8E4BA.3030101@yahoo.com> <3FB8F0AC.7040906@cisco.com> <3FB8F335.4040905@interflect.com> from Norman Finn on Tue, 18 Nov 2003 09:56:06 +0100 Content-Disposition: inline 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 Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 14:22:02 -0600 Lines: 51 Sender: pwe3-admin@ietf.org References: <200311181615.LAA22141@linus.bcentralhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org, "'mark seery'" X-From: pwe3-admin@ietf.org Tue Nov 18 21:23:11 2003 Return-path: In-reply-to: <200311181615.LAA22141@linus.bcentralhost.com> To: "'Norman Finn'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 14:12:00 -0800 Lines: 96 Sender: pwe3-admin@ietf.org References: <000801c3ae11$a0b995e0$338c23a6@acer4wc5zk5t43> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Tue Nov 18 23:08:10 2003 Return-path: To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000801c3ae11$a0b995e0$338c23a6@acer4wc5zk5t43> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Let's be clear here. I believe Norm is saying that the service provided to a bridge by whatever media needs to provide the same integrity as is provided by Ethernet today. This may be accomplished by a CRC-32/integrity check with Hamming distance of 5/whatever is needed to cover the particular faults of the media. In this sense bridges may need a CRC option on some PW. This is not a CRC transported through the bridge, and whatever the media in question is or locally appears to the bridge to be, if it requires a CRC additional to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. This is true even if the new MAC is partially constructed out of 802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes (documenting discussion with the 802.3 leadership), and in the liaison to the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay function required 'inside' such a new media is not an 802.1 bridge. For an 802.1 Bridge to use new media/MAC it requires a mapping of the procedures etc. provided by the media to the Internal Sublayer Service (ISS) used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5, FDDI, and 802.11. These mappings are developed in close cooperation with the group responsible for the MAC, and are usually written by that group, so it is not in 802.1's gift to arbitrarily add to any existing mapping. There is no restriction on such mappings being exclusively developed by IEEE 802, the FDDI mapping was developed with the ANSI committee responsible for FDDI (I've forgotten its name). I am currently confused by the different answers I am getting on the CRC question that Scott is posing. In discussion at the meeting Scott told me that the proposed PW was using a perfectly adequate CRC, but hinted at some other source of faults (badly implemented bridge? thing that looks like a bridge to those not familiar with the bridging standards and what they require?). Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 12:22 PM To: 'Norman Finn' Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 22:44:42 -0000 Lines: 88 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 Tue Nov 18 23:47:05 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOtwSO9itR9CCl+TOexj1B6w2eeqwATWLxw To: , X-OriginalArrivalTime: 18 Nov 2003 22:44:43.0272 (UTC) FILETIME=[8F00C080:01C3AE25] 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 Norm....As per our discussion today face-face. I don't really see what = the problem is here. The client layer network should not care about the = server layer network (and vice versa)....we need this layer independence = for lots of reasons. An ethernet traffic unit has a FCS. This should = simply be transported transparently in the payload area of whatever the = server layer is....and the server layer should use its own (OAM) = 'integrity mechanisms' irrespective of the client. Problems arise when = people start doing things like client layer compression and thus forming = inter-layer dependencies. Further, as we agreed today and as I posted on an earlier mail to this = thread, the ethernet FCS is a CRC that can be linerarly updated for = adaptation function changes (eg VLAN ID change) on each link-connection = (as provided by some server layer trail technology) whilst preserving = its end-end intergrity check of the rest of the ethernet traffic unit = between its trail termination points. regards, Neil > -----Original Message----- > From: Norman Finn [mailto:nfinn@cisco.com] > Sent: 18 November 2003 08:56 > To: mark seery > Cc: stds-802-1@ieee.org; pwe3@ietf.org > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 > Mark, >=20 > You say below, >=20 > > but a PW will be running over a physical media itself=20 > already, possibly > > even SONET............. >=20 > Exactly! Here, the trail gets a bit murky. If I'm in total=20 > control, and the PW > is running over known Ethernet links, then I can get away=20 > without the CRC in the > PW. I have no problem whatsoever with the current definition=20 > of PWs without CRC. >=20 > But, if I don't have tight control over the physical media=20 > over which the PW runs, > then I really need a CRC on the PW for the bridge to be able=20 > to trust the "wire" > and thus provide the same level of data integrity that=20 > bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. >=20 > -- Norm >=20 > mark seery wrote: > >=20 > > Norman Finn wrote: > >=20 > >> > >> In other words, routers pass about $0.93 of the data=20 > integrity buck to=20 > >> bridges, > >> and bridges pass about $0.75 of that to the data links. =20 > The buck has=20 > >> to stop > >> somewhere, and the data link is where it stops. The PW=20 > has to take=20 > >> the same > >> hit as the physical media. > >> > >> -- Norm > >=20 > >=20 > > but a PW will be running over a physical media itself=20 > already, possibly=20 > > even SONET............. > >=20 > > mark > >=20 > >=20 > >=20 > >=20 >=20 >=20 >=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: Scott Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 17:08:57 -0600 Lines: 171 Sender: pwe3-admin@ietf.org References: <002601c3ae20$ffa84470$210110ac@corp.telseon.com> 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 Wed Nov 19 00:15:09 2003 Return-path: In-reply-to: <002601c3ae20$ffa84470$210110ac@corp.telseon.com> To: mick_seaman@ieee.org, stds-802-1@ieee.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Let me attempt to clarify why I brought up Pseudowires in the first place. Pseudowire/Ethernet transport of Ethernet services(protocol stack is Customer Tagged Ethernet/Pseudowire/Carrier Untagged Ethernet, note the Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like Stacked VLAN transport of Ethernet services (protocol stack is Customer Tagged Ethernet/Carrier VLAN). In the Pseudowire model, the customer FCS (originally tossed in the PWE3 specs but now optionally maintained) is an end-to-end Path FCS, while the carrier FCS (always present for Ethernet over Dark Fiber implementations as part of the underlying L2 transport of the L2.5 PW frame) is a Link/Line FCS. In the stacked VLAN transport, the customer FCS is tossed/overwritten, just like it was in the PWE3 spec originally. The newly calculated FCS is a Link/Line FCS. Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1. As Norm stated, router guys take the underlying error correcting capabilities that bridges provide for granted, so it should take less work to convince bridge guys (who understand the importance of error detection) than it did to convince router guys, which by the way was a very long and grueling process. I plan to put some drawing together showing the protocol stack similarities as well as the functions required at each point in each switch for these various scenarios when time permits. Hope this textual explanation provides some clarification. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mick Seaman Sent: Tuesday, November 18, 2003 4:12 PM To: stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let's be clear here. I believe Norm is saying that the service provided to a bridge by whatever media needs to provide the same integrity as is provided by Ethernet today. This may be accomplished by a CRC-32/integrity check with Hamming distance of 5/whatever is needed to cover the particular faults of the media. In this sense bridges may need a CRC option on some PW. This is not a CRC transported through the bridge, and whatever the media in question is or locally appears to the bridge to be, if it requires a CRC additional to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. This is true even if the new MAC is partially constructed out of 802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes (documenting discussion with the 802.3 leadership), and in the liaison to the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay function required 'inside' such a new media is not an 802.1 bridge. For an 802.1 Bridge to use new media/MAC it requires a mapping of the procedures etc. provided by the media to the Internal Sublayer Service (ISS) used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5, FDDI, and 802.11. These mappings are developed in close cooperation with the group responsible for the MAC, and are usually written by that group, so it is not in 802.1's gift to arbitrarily add to any existing mapping. There is no restriction on such mappings being exclusively developed by IEEE 802, the FDDI mapping was developed with the ANSI committee responsible for FDDI (I've forgotten its name). I am currently confused by the different answers I am getting on the CRC question that Scott is posing. In discussion at the meeting Scott told me that the proposed PW was using a perfectly adequate CRC, but hinted at some other source of faults (badly implemented bridge? thing that looks like a bridge to those not familiar with the bridging standards and what they require?). Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 12:22 PM To: 'Norman Finn' Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm _______________________________________________ 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: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 15:46:16 -0800 Lines: 208 Sender: pwe3-admin@ietf.org References: <000001c3ae28$f2154170$338c23a6@acer4wc5zk5t43> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Wed Nov 19 00:42:06 2003 Return-path: To: "'Scott Kotrla'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <000001c3ae28$f2154170$338c23a6@acer4wc5zk5t43> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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, I thoroughly disagree with your statement "Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1." The similarity in drawing pictures should not obscure the fact that no value would be provided in current bridged networks by retaining the additional FCS, as the existing mechanisms have been shown to provide the level of integrity required. The addition of the option would in contrast introduce new scenarios for failure of network connectivity and new work for all, to no purpose. Modelling your "customer FCS" as part of the a "new MAC" that you are creating, and thus purely applicable to the service provided between a pair of bridges is sufficient to explain its role in the architecture. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 3:09 PM To: mick_seaman@ieee.org; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let me attempt to clarify why I brought up Pseudowires in the first place. Pseudowire/Ethernet transport of Ethernet services(protocol stack is Customer Tagged Ethernet/Pseudowire/Carrier Untagged Ethernet, note the Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like Stacked VLAN transport of Ethernet services (protocol stack is Customer Tagged Ethernet/Carrier VLAN). In the Pseudowire model, the customer FCS (originally tossed in the PWE3 specs but now optionally maintained) is an end-to-end Path FCS, while the carrier FCS (always present for Ethernet over Dark Fiber implementations as part of the underlying L2 transport of the L2.5 PW frame) is a Link/Line FCS. In the stacked VLAN transport, the customer FCS is tossed/overwritten, just like it was in the PWE3 spec originally. The newly calculated FCS is a Link/Line FCS. Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1. As Norm stated, router guys take the underlying error correcting capabilities that bridges provide for granted, so it should take less work to convince bridge guys (who understand the importance of error detection) than it did to convince router guys, which by the way was a very long and grueling process. I plan to put some drawing together showing the protocol stack similarities as well as the functions required at each point in each switch for these various scenarios when time permits. Hope this textual explanation provides some clarification. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mick Seaman Sent: Tuesday, November 18, 2003 4:12 PM To: stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let's be clear here. I believe Norm is saying that the service provided to a bridge by whatever media needs to provide the same integrity as is provided by Ethernet today. This may be accomplished by a CRC-32/integrity check with Hamming distance of 5/whatever is needed to cover the particular faults of the media. In this sense bridges may need a CRC option on some PW. This is not a CRC transported through the bridge, and whatever the media in question is or locally appears to the bridge to be, if it requires a CRC additional to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. This is true even if the new MAC is partially constructed out of 802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes (documenting discussion with the 802.3 leadership), and in the liaison to the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay function required 'inside' such a new media is not an 802.1 bridge. For an 802.1 Bridge to use new media/MAC it requires a mapping of the procedures etc. provided by the media to the Internal Sublayer Service (ISS) used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5, FDDI, and 802.11. These mappings are developed in close cooperation with the group responsible for the MAC, and are usually written by that group, so it is not in 802.1's gift to arbitrarily add to any existing mapping. There is no restriction on such mappings being exclusively developed by IEEE 802, the FDDI mapping was developed with the ANSI committee responsible for FDDI (I've forgotten its name). I am currently confused by the different answers I am getting on the CRC question that Scott is posing. In discussion at the meeting Scott told me that the proposed PW was using a perfectly adequate CRC, but hinted at some other source of faults (badly implemented bridge? thing that looks like a bridge to those not familiar with the bridging standards and what they require?). Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 12:22 PM To: 'Norman Finn' Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm _______________________________________________ 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: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 21:14:09 -0600 Lines: 244 Sender: pwe3-admin@ietf.org References: <002b01c3ae2e$29a4f130$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 19 04:20:11 2003 Return-path: In-reply-to: <002b01c3ae2e$29a4f130$210110ac@corp.telseon.com> To: mick_seaman@ieee.org, "'Scott Kotrla'" , stds-802-1@ieee.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Maybe I have a far too simplistic view of the world, but... Anytime you = are tunneling L2 across anything other than a link, I see merit in a path = FCS. This is as true for Stacked VLANs as it is for Ethernet pseudowires. Fortunately, I see only a very limited life for Stacked VLANs with my network. As soon as I have the FCS retention on Ethernet pseudowires, I will not deploy a single additional stacked VLAN. In the interim, I'll deploy proprietary solutions which allow me to leave the customer FCS untouched and allow the appending of a provider FCS on the end. These = exist today... Nick -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mick Seaman Sent: Tuesday, November 18, 2003 5:46 PM To: 'Scott Kotrla'; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Scott, I thoroughly disagree with your statement "Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1." The similarity in drawing pictures should not obscure the fact that no = value would be provided in current bridged networks by retaining the = additional FCS, as the existing mechanisms have been shown to provide the level of integrity required. The addition of the option would in contrast = introduce new scenarios for failure of network connectivity and new work for all, = to no purpose. Modelling your "customer FCS" as part of the a "new MAC" that you are creating, and thus purely applicable to the service provided between a = pair of bridges is sufficient to explain its role in the architecture. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 3:09 PM To: mick_seaman@ieee.org; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let me attempt to clarify why I brought up Pseudowires in the first place. Pseudowire/Ethernet transport of Ethernet services(protocol stack is Customer Tagged Ethernet/Pseudowire/Carrier Untagged Ethernet, note the Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like Stacked VLAN transport of Ethernet services (protocol stack is Customer Tagged Ethernet/Carrier VLAN). In the Pseudowire model, the customer FCS (originally tossed in the PWE3 specs but now optionally maintained) is an end-to-end Path FCS, while the carrier FCS (always present for Ethernet over Dark Fiber implementations as part of the underlying L2 transport of the L2.5 PW frame) is a Link/Line FCS. In the stacked VLAN transport, the customer FCS is tossed/overwritten, just like it was in the PWE3 spec originally. The newly calculated FCS is a Link/Line FCS. Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1. As Norm stated, router guys take the underlying error correcting capabilities that bridges provide for granted, so it should take less work to convince bridge guys (who understand the importance of error detection) than it did to convince router guys, which by the way was a very long and grueling process. I plan to put some drawing together showing the protocol stack similarities as well as the functions required at each point in each switch for these various scenarios when time permits. Hope this textual explanation provides some clarification. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mick Seaman Sent: Tuesday, November 18, 2003 4:12 PM To: stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let's be clear here. I believe Norm is saying that the service provided to a bridge by whatever media needs to provide the same integrity as is provided by Ethernet today. This may be accomplished by a CRC-32/integrity check with Hamming distance of 5/whatever is needed to cover the particular faults of the media. In this sense bridges may need a CRC option on some PW. This is not a CRC transported through the bridge, and whatever the media in question is or locally appears to the bridge to be, if it requires a CRC additional to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. This is true even if the new MAC is partially constructed out of 802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes (documenting discussion with the 802.3 leadership), and in the liaison to the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay function required 'inside' such a new media is not an 802.1 bridge. For an 802.1 Bridge to use new media/MAC it requires a mapping of the procedures etc. provided by the media to the Internal Sublayer Service (ISS) used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5, FDDI, and 802.11. These mappings are developed in close cooperation with the group responsible for the MAC, and are usually written by that group, so it is not in 802.1's gift to arbitrarily add to any existing mapping. There is no restriction on such mappings being exclusively developed by IEEE 802, the FDDI mapping was developed with the ANSI committee responsible for FDDI (I've forgotten its name). I am currently confused by the different answers I am getting on the CRC question that Scott is posing. In discussion at the meeting Scott told me that the proposed PW was using a perfectly adequate CRC, but hinted at some other source of faults (badly implemented bridge? thing that looks like a bridge to those not familiar with the bridging standards and what they require?). Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 12:22 PM To: 'Norman Finn' Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm _______________________________________________ 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: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 22:54:11 -0800 Lines: 267 Sender: pwe3-admin@ietf.org References: <044701c3ae4b$3395ee70$6b01a8c0@nick> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: X-From: pwe3-admin@ietf.org Wed Nov 19 07:50:07 2003 Return-path: To: "'Nick DelRegno'" , "'Scott Kotrla'" , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <044701c3ae4b$3395ee70$6b01a8c0@nick> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 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 Consider the following in stacked VLANs - Customer VLANs over Service VLANs (once called Provider VLANs). The provider bridges that support the S-VLANs run configuration protocols to organize and operate the S-VLAN topology. These protocols use nothing more than the naked service between those provider bridges. Therefore that service has to provide a level of integrity comensurate with Ethernet as is today, otherwise the network is going to fall apart in odd ways. Once you have that necessary level of service and a decent bridge, you have the service level necessary to support the customers. Feel free to deploy your proprietary solutions if you must, there is an amazing array of choices out there and IEEE standards are voluntary, but don't push up the cost and complexity for everyone for what has to be infinitesimal benefit. Would you like to put some numbers on the increased level of reliability you expect from the additional FCS? Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Nick DelRegno Sent: Tuesday, November 18, 2003 7:14 PM To: mick_seaman@ieee.org; 'Scott Kotrla'; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Maybe I have a far too simplistic view of the world, but... Anytime you are tunneling L2 across anything other than a link, I see merit in a path FCS. This is as true for Stacked VLANs as it is for Ethernet pseudowires. Fortunately, I see only a very limited life for Stacked VLANs with my network. As soon as I have the FCS retention on Ethernet pseudowires, I will not deploy a single additional stacked VLAN. In the interim, I'll deploy proprietary solutions which allow me to leave the customer FCS untouched and allow the appending of a provider FCS on the end. These exist today... Nick -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mick Seaman Sent: Tuesday, November 18, 2003 5:46 PM To: 'Scott Kotrla'; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Scott, I thoroughly disagree with your statement "Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1." The similarity in drawing pictures should not obscure the fact that no value would be provided in current bridged networks by retaining the additional FCS, as the existing mechanisms have been shown to provide the level of integrity required. The addition of the option would in contrast introduce new scenarios for failure of network connectivity and new work for all, to no purpose. Modelling your "customer FCS" as part of the a "new MAC" that you are creating, and thus purely applicable to the service provided between a pair of bridges is sufficient to explain its role in the architecture. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 3:09 PM To: mick_seaman@ieee.org; stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let me attempt to clarify why I brought up Pseudowires in the first place. Pseudowire/Ethernet transport of Ethernet services(protocol stack is Customer Tagged Ethernet/Pseudowire/Carrier Untagged Ethernet, note the Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like Stacked VLAN transport of Ethernet services (protocol stack is Customer Tagged Ethernet/Carrier VLAN). In the Pseudowire model, the customer FCS (originally tossed in the PWE3 specs but now optionally maintained) is an end-to-end Path FCS, while the carrier FCS (always present for Ethernet over Dark Fiber implementations as part of the underlying L2 transport of the L2.5 PW frame) is a Link/Line FCS. In the stacked VLAN transport, the customer FCS is tossed/overwritten, just like it was in the PWE3 spec originally. The newly calculated FCS is a Link/Line FCS. Keeping the customer FCS in PWE3 (when there is already an underlying Link/Line FCS) is exactly the same as keeping the customer FCS in a Stacked VLAN model and appending a new Link/Line FCS (instead of overwriting the customer's FCS). If we can get consensus on this, then we should also be able to get consensus that the same functionality should optionally be available in either architecture. This consensus has already been reached in PWE3, and my goal is to reach the same consensus in 802.1. As Norm stated, router guys take the underlying error correcting capabilities that bridges provide for granted, so it should take less work to convince bridge guys (who understand the importance of error detection) than it did to convince router guys, which by the way was a very long and grueling process. I plan to put some drawing together showing the protocol stack similarities as well as the functions required at each point in each switch for these various scenarios when time permits. Hope this textual explanation provides some clarification. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Mick Seaman Sent: Tuesday, November 18, 2003 4:12 PM To: stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let's be clear here. I believe Norm is saying that the service provided to a bridge by whatever media needs to provide the same integrity as is provided by Ethernet today. This may be accomplished by a CRC-32/integrity check with Hamming distance of 5/whatever is needed to cover the particular faults of the media. In this sense bridges may need a CRC option on some PW. This is not a CRC transported through the bridge, and whatever the media in question is or locally appears to the bridge to be, if it requires a CRC additional to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. This is true even if the new MAC is partially constructed out of 802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes (documenting discussion with the 802.3 leadership), and in the liaison to the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay function required 'inside' such a new media is not an 802.1 bridge. For an 802.1 Bridge to use new media/MAC it requires a mapping of the procedures etc. provided by the media to the Internal Sublayer Service (ISS) used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5, FDDI, and 802.11. These mappings are developed in close cooperation with the group responsible for the MAC, and are usually written by that group, so it is not in 802.1's gift to arbitrarily add to any existing mapping. There is no restriction on such mappings being exclusively developed by IEEE 802, the FDDI mapping was developed with the ANSI committee responsible for FDDI (I've forgotten its name). I am currently confused by the different answers I am getting on the CRC question that Scott is posing. In discussion at the meeting Scott told me that the proposed PW was using a perfectly adequate CRC, but hinted at some other source of faults (badly implemented bridge? thing that looks like a bridge to those not familiar with the bridging standards and what they require?). Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 12:22 PM To: 'Norman Finn' Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm _______________________________________________ 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: "Yaakov Stein" Subject: RE: Re: ITU-T FR draft Date: Wed, 19 Nov 2003 10:59:48 +0200 Lines: 225 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AE7B.7C0F8C30" Cc: "Danny McPherson" , , "Jon Peterson" X-From: pwe3-admin@ietf.org Wed Nov 19 10:01:17 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: Re: [PWE3] ITU-T FR draft Thread-Index: AcOqwC+2Y/0x/MjATcmP4wmVVlzZnQDuwRWA To: , "Luca Martini" 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_01C3AE7B.7C0F8C30 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable >From Claude's answer we see the problem. I agree that the terminology used in X.84 is the same as that we use in PWE3, but the document I have seen is in form and wording quite different from the IETF one. My fear is that two similar but not identical documents may hide subtle differences which will haunt us later. Y(J)S -----Original Message----- From: claude.kawa@sympatico.ca [mailto:claude.kawa@sympatico.ca] Sent: =E5 14/11/2003 17:01 To: Luca Martini; Yaakov Stein Cc: Danny McPherson; pwe3@ietf.org; Jon Peterson Subject: Re: Re: [PWE3] ITU-T FR draft The objective of the contributors to ITU-T SG17 draft Recommendation on = frame relay/MPLS (X.84) is to ensure that it is aligned with regard to = the terminolgy and capabilities with PWE3 draft. Claude >=20 > From: Luca Martini > Date: 2003/11/13 Thu PM 06:12:04 EST > To: Yaakov Stein > CC: Danny McPherson , pwe3@ietf.org,=20 > Jon Peterson > Subject: Re: [PWE3] ITU-T FR draft >=20 > My understanding is that Claude ( FR editor ) is making sure this is = the=20 > case today. >=20 > What is the problem Yakov ? >=20 > Luca >=20 > Danny McPherson wrote: >=20 > > > > I think this is fine, so long as the IETF document is aligned > > with the goals and consensus of the WG and the IETF. Do you > > foresee any potential reasons why this might not be the case? > > > > -danny > > > > > > On Nov 11, 2003, at 6:49 PM, Yaakov Stein wrote: > > > >> Dear WG chairs and everyone, > >> > >> I would like to re-iterate my suggestion that the IETF and > >> ITU-T SG17 work together to produce a single harmonized > >> FR draft. > >> > >> Since SG17 has adopted the PWE3 terminology, > >> and there is great overlap in authors of the PWE and ITU drafts, > >> it should be possible to make the documents precisely identical. > >> > >> This has been done before (e.g. Megaco/H.248) > >> and has the advantage of ensuring that there can be > >> no minor issues that can later crop up due to different > >> wording. > >> > >> Y(J)S > >> > > > > > > _______________________________________________ > > pwe3 mailing list > > 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 >=20 ------_=_NextPart_001_01C3AE7B.7C0F8C30 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: Re: [PWE3] ITU-T FR draft

From Claude's answer we see the problem.

I agree that the terminology used in X.84 is the same
as that we use in PWE3, but the document I have seen
is in form and wording quite different from the IETF
one.

My fear is that two similar but not identical documents
may hide subtle differences which will haunt us later.

Y(J)S


-----Original Message-----
From:   claude.kawa@sympatico.ca [mailto:claude.kawa@sympatico.ca<= /A>]
Sent:   =E5 14/11/2003 17:01
To:     Luca Martini; Yaakov Stein
Cc:     Danny McPherson; pwe3@ietf.org; Jon = Peterson
Subject:        Re: Re: [PWE3] ITU-T = FR draft

The objective of the contributors to ITU-T SG17 draft Recommendation on = frame relay/MPLS (X.84) is to ensure that it is aligned with regard to = the terminolgy and capabilities with PWE3 draft.

Claude
>
> From: Luca Martini <lmartini@cisco.com>
> Date: 2003/11/13 Thu PM 06:12:04 EST
> To: Yaakov Stein <yaakov_s@rad.com>
> CC: Danny McPherson <danny@tcb.net>,  pwe3@ietf.org,
>         Jon Peterson = <jon.peterson@neustar.biz>
> Subject: Re: [PWE3] ITU-T FR draft
>
> My understanding is that Claude ( FR editor ) is making sure this = is the
> case today.
>
> What is the problem Yakov ?
>
> Luca
>
> Danny McPherson wrote:
>
> >
> > I think this is fine, so long as the IETF document is = aligned
> > with the goals and consensus of the WG and the IETF.  Do = you
> > foresee any potential reasons why this might not be the = case?
> >
> > -danny
> >
> >
> > On Nov 11, 2003, at 6:49 PM, Yaakov Stein wrote:
> >
> >> Dear WG chairs and everyone,
> >>
> >> I would like to re-iterate my suggestion that the IETF = and
> >> ITU-T SG17 work together to produce a single = harmonized
> >> FR draft.
> >>
> >> Since SG17 has adopted the PWE3 terminology,
> >> and there is great overlap in authors of the PWE and ITU = drafts,
> >> it should be possible to make the documents precisely = identical.
> >>
> >> This has been done before (e.g. Megaco/H.248)
> >> and has the advantage of ensuring that there can be
> >> no minor issues that can later crop up due to = different
> >> wording.
> >>
> >> Y(J)S
> >>
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.or= g/mailman/listinfo/pwe3
> >
>
>
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.or= g/mailman/listinfo/pwe3
>

------_=_NextPart_001_01C3AE7B.7C0F8C30-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: Re: ITU-T FR draft Date: Wed, 19 Nov 2003 11:09:03 +0200 Lines: 307 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-23fc8370-6d72-4c2f-a7a0-0b61560a2212" Cc: Danny McPherson , pwe3@ietf.org, Jon Peterson , Luca Martini X-From: pwe3-admin@ietf.org Wed Nov 19 10:11:06 2003 Return-path: To: "'Yaakov Stein'" , 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 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-23fc8370-6d72-4c2f-a7a0-0b61560a2212 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AE7C.C6ED3D00" ------_=_NextPart_001_01C3AE7C.C6ED3D00 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Yaakov, Claude and all, My understanding of the situation (which can be incomplete or even incorrect) is that the present X.84 text fixes at least one bug that = has been found in draft-ietf-pwe3-frame-relay-01.txt (the packet lenth definition), and the intention is to synchronize the PWE3 FR draft with = X.84 once the latter is finalized (to avoid multiple intermediate = revisions). If this understanding is correct, IMO, the two documents have a very = good chance to define exactly the same "on the wire" behavior. In fact, = skipping intermediate revisions of the PWE3 FR draft can be even seen as = facilitating this objective. Hopefully these nores will be helpful. ------------------------------------------------------------------------= ---- -------- With best regards, Sasha Vainshtein email: sasha@axerra.com =20 phone: +972-3-7659993 (office) +972-8-9254948 (home) +972-58-674833 (cellular) -----Original Message----- From: Yaakov Stein [mailto:yaakov_s@rad.com] Sent: Wednesday, November 19, 2003 11:00 AM To: claude.kawa@sympatico.ca; Luca Martini Cc: Danny McPherson; pwe3@ietf.org; Jon Peterson Subject: RE: Re: [PWE3] ITU-T FR draft >From Claude's answer we see the problem. I agree that the terminology used in X.84 is the same as that we use in PWE3, but the document I have seen is in form and wording quite different from the IETF one. My fear is that two similar but not identical documents may hide subtle differences which will haunt us later. Y(J)S -----Original Message----- From: claude.kawa@sympatico.ca [ mailto:claude.kawa@sympatico.ca ] Sent: =E5 14/11/2003 17:01 To: Luca Martini; Yaakov Stein Cc: Danny McPherson; pwe3@ietf.org; Jon Peterson Subject: Re: Re: [PWE3] ITU-T FR draft The objective of the contributors to ITU-T SG17 draft Recommendation on frame relay/MPLS (X.84) is to ensure that it is aligned with regard to = the terminolgy and capabilities with PWE3 draft. Claude > > From: Luca Martini > Date: 2003/11/13 Thu PM 06:12:04 EST > To: Yaakov Stein > CC: Danny McPherson , pwe3@ietf.org, > Jon Peterson > Subject: Re: [PWE3] ITU-T FR draft > > My understanding is that Claude ( FR editor ) is making sure this is = the > case today. > > What is the problem Yakov ? > > Luca > > Danny McPherson wrote: > > > > > I think this is fine, so long as the IETF document is aligned > > with the goals and consensus of the WG and the IETF. Do you > > foresee any potential reasons why this might not be the case? > > > > -danny > > > > > > On Nov 11, 2003, at 6:49 PM, Yaakov Stein wrote: > > > >> Dear WG chairs and everyone, > >> > >> I would like to re-iterate my suggestion that the IETF and > >> ITU-T SG17 work together to produce a single harmonized > >> FR draft. > >> > >> Since SG17 has adopted the PWE3 terminology, > >> and there is great overlap in authors of the PWE and ITU drafts, > >> it should be possible to make the documents precisely identical. > >> > >> This has been done before (e.g. Megaco/H.248) > >> and has the advantage of ensuring that there can be > >> no minor issues that can later crop up due to different > >> wording. > >> > >> Y(J)S > >> > > > > > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 =20 > > > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 =20 > ------_=_NextPart_001_01C3AE7C.C6ED3D00 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: Re: [PWE3] ITU-T FR draft
Yaakov, Claude and all,
My=20 understanding of the situation (which can be incomplete or even = incorrect) is=20 that the present X.84 text fixes at least one bug that has been found = in=20 draft-ietf-pwe3-frame-relay-01.txt (the packet lenth definition), and = the=20 intention is to synchronize the PWE3 FR draft with X.84 once the latter = is=20 finalized (to avoid multiple intermediate = revisions).
If=20 this understanding is correct, IMO, the two documents have a very good = chance to=20 define exactly the same "on the wire" behavior. In fact, skipping = intermediate=20 revisions of the PWE3 FR draft can be even seen as facilitating this=20 objective.
Hopefully these nores will be helpful.
---------------------------------------------------------------= ---------------------
With best regards,
          &nb= sp;           &nb= sp;  =20 Sasha Vainshtein
email:   sasha@axerra.com
phone: =20 +972-3-7659993 (office)
          &nb= sp;=20 +972-8-9254948 (home)
          &nb= sp;=20 +972-58-674833 (cellular)
-----Original Message-----
From: Yaakov Stein=20 [mailto:yaakov_s@rad.com]
Sent: Wednesday, November 19, = 2003 11:00=20 AM
To: claude.kawa@sympatico.ca; Luca Martini
Cc: = Danny=20 McPherson; pwe3@ietf.org; Jon Peterson
Subject: RE: Re: = [PWE3] ITU-T=20 FR draft


From Claude's answer we see the problem.

I = agree that=20 the terminology used in X.84 is the same
as that we use in PWE3, = but the=20 document I have seen
is in form and wording quite different from = the=20 IETF
one.

My fear is that two similar but not identical=20 documents
may hide subtle differences which will haunt us=20 later.

Y(J)S


-----Original = Message-----
From:  =20 claude.kawa@sympatico.ca [mailto:claude.kawa@sympatico.ca= ]
Sent:  =20 =E5 14/11/2003 17:01
To:     Luca Martini; = Yaakov=20 Stein
Cc:     Danny McPherson; pwe3@ietf.org; = Jon=20 Peterson
Subject:        Re: = Re: [PWE3]=20 ITU-T FR draft

The objective of the contributors to ITU-T SG17 = draft=20 Recommendation on frame relay/MPLS (X.84) is to ensure that it is = aligned with=20 regard to the terminolgy and capabilities with PWE3=20 draft.

Claude
>
> From: Luca Martini=20 <lmartini@cisco.com>
> Date: 2003/11/13 Thu PM 06:12:04=20 EST
> To: Yaakov Stein <yaakov_s@rad.com>
> CC: = Danny=20 McPherson <danny@tcb.net>, =20 = pwe3@ietf.org,
>         = Jon=20 Peterson <jon.peterson@neustar.biz>
> Subject: Re: [PWE3] = ITU-T FR=20 draft
>
> My understanding is that Claude ( FR editor ) = is making=20 sure this is the
> case today.
>
> What is the = problem Yakov=20 ?
>
> Luca
>
> Danny McPherson = wrote:
>
>=20 >
> > I think this is fine, so long as the IETF document = is=20 aligned
> > with the goals and consensus of the WG and the=20 IETF.  Do you
> > foresee any potential reasons why = this might=20 not be the case?
> >
> > -danny
> = >
>=20 >
> > On Nov 11, 2003, at 6:49 PM, Yaakov Stein = wrote:
>=20 >
> >> Dear WG chairs and everyone,
> = >>
>=20 >> I would like to re-iterate my suggestion that the IETF = and
>=20 >> ITU-T SG17 work together to produce a single = harmonized
>=20 >> FR draft.
> >>
> >> Since SG17 has = adopted=20 the PWE3 terminology,
> >> and there is great overlap in = authors=20 of the PWE and ITU drafts,
> >> it should be possible to = make the=20 documents precisely identical.
> >>
> >> This = has been=20 done before (e.g. Megaco/H.248)
> >> and has the = advantage of=20 ensuring that there can be
> >> no minor issues that can = later=20 crop up due to different
> >> wording.
> = >>
>=20 >> Y(J)S
> >>
> >
> >
> = >=20 _______________________________________________
> > pwe3 = mailing=20 list
> > pwe3@ietf.org
> > https://www1.ietf.o= rg/mailman/listinfo/pwe3
>=20 >
>
>
>=20 _______________________________________________
> pwe3 mailing=20 list
> pwe3@ietf.org
> https://www1.ietf.o= rg/mailman/listinfo/pwe3
>



------_=_NextPart_001_01C3AE7C.C6ED3D00-- ------=_NextPartTM-000-23fc8370-6d72-4c2f-a7a0-0b61560a2212-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: richard.spencer@bt.com Subject: RE: Re: ITU-T FR draft Date: Wed, 19 Nov 2003 10:33:39 -0000 Lines: 15 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 Wed Nov 19 11:35:05 2003 Return-path: x-mimeole: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message Thread-Topic: Re: [PWE3] ITU-T FR draft Thread-Index: AcOufVCa/M5OkLxwTFSkyfnpiOc2cQABXTOl To: , , X-OriginalArrivalTime: 19 Nov 2003 10:33:39.0848 (UTC) FILETIME=[98C72880:01C3AE88] 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 PiBJZiB0aGlzIHVuZGVyc3RhbmRpbmcgaXMgY29ycmVjdCwgSU1PLCB0aGUgdHdvIGRvY3VtZW50 cyBoYXZlIGEgdmVyeQ0KDQo+IGdvb2QgY2hhbmNlIHRvIGRlZmluZSBleGFjdGx5IHRoZSBzYW1l ICJvbiB0aGUgd2lyZSIgYmVoYXZpb3IuDQoNCiANCg0KSWYgdGhlIGludGVudGlvbiBpcyB0byBt YWtlIGJvdGggZG9jdW1lbnRzIGVzc2VudGlhbGx5IGlkZW50aWNhbCAodGhvdWdoIHRoZXkgbWF5 IGhhdmUgc2xpZ2h0bHkgZGlmZmVyZW50IHdvcmRpbmcpLCB3aHkgZG8gd2UgbmVlZCB0aGVtIGJv dGg/IFdoeSBub3QganVzdCBzdGFuZGFyZGlzZSBvbmUgKHdoZXJlIGlzbid0IGltcG9ydGFudCkg YW5kIGNyb3NzLXJlZmVyZW5jZSBpdCB3aGVyZSBuZWNlc3Nhcnk/DQoNCiANCg0KPiBUaGUgb2Jq ZWN0aXZlIG9mIHRoZSBjb250cmlidXRvcnMgdG8gSVRVLVQgU0cxNyBkcmFmdCBSZWNvbW1lbmRh dGlvbg0KDQo+IG9uIGZyYW1lIHJlbGF5L01QTFMgKFguODQpIGlzIHRvIGVuc3VyZSB0aGF0IGl0 IGlzIGFsaWduZWQgd2l0aA0KDQo+IHJlZ2FyZCB0byB0aGUgdGVybWlub2xneSBhbmQgY2FwYWJp bGl0aWVzIHdpdGggUFdFMyBkcmFmdC4NCg0KIA0KDQpFcXVhbGx5IHRoZW4sIGlzIHRoZSBvYmpl Y3RpdmUgb2YgdGhlIGNvbnRyaWJ1dG9ycyB0byB0aGUgUFdFMyBmcmFtZSByZWxheS9NUExTIGRy YWZ0IHRvIGVuc3VyZSB0aGF0IGl0IGlzIGFsaWduZWQgd2l0aCB0ZXJtaW5vbG9neSB1c2VkIGJ5 IHRoZSBJVFU/IGUuZy4gdGhlIHRlcm1pbm9sb2d5IHVzZWQgaW4gRy44MDUgdG8gZGVzY3JpYmUg dHJhbnNwb3J0IG5ldHdvcmtzPw0KDQogDQoNClJpY2hhcmQNCg0K From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Heiles Juergen Subject: AW: RE: [802.1] 802.1ad Customer FCS Retention Date: Wed, 19 Nov 2003 11:38:46 +0100 Lines: 190 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 19 11:40:04 2003 Return-path: To: pat_thaler@agilent.com, mick_seaman@ieee.org, stds-802-1@ieee.org X-Mailer: Internet Mail Service (5.5.2653.19) 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 Pat, we are talking about Ethernet services which are for example = transported over IP. In this case the Ethernet MAC frame is a payload = of the IP frame. This IP frame may again be transported over Ethernet = so we have the following stack: Ethernet MAC service | IP | Ethernet MAC transport Any changes to the IP header or the transport MAC header have no = influence on the Ethernet MAC service frame and its FCS.=20 Regards Juergen > -----Urspr=FCngliche Nachricht----- > Von: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com] > Gesendet: Mittwoch, 19. November 2003 00:39 > An: mick_seaman@ieee.org; stds-802-1@ieee.org > Cc: pwe3@ietf.org > Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 >=20 > I am also confused about the same point. Some people such as=20 > Norm seem to be concerned about a CRC over the media and some=20 > seem to be concerned about an end to end CRC to protect=20 > against errors during CRC regeneration in bridges. >=20 > Of course as long as all the media are using the same CRC=20 > polynomial, the bridges could adjust the original CRC for any=20 > packet changes rather than regenerate. Personally, I think=20 > 802.1 Appendix G makes this look more complicated than it is. >=20 > Attempting an end-to-end MAC layer CRC isn't worthwhile. As=20 > soon as one goes through a higher layer device such as a=20 > router, it will get tossed and regenerated anyway (unless=20 > they do CRC adjustment for IP and MAC header changes which=20 > seems unlikely). If real end-to-end protection against=20 > corruption is desired, then the place to do it is in=20 > transport or above. >=20 > Pat >=20 > P.S. the CRC-32 provides Hamming distance of 4 - it detects=20 > all 3 bit errors up to something larger than 8 K. >=20 > -----Original Message----- > From: Mick Seaman [mailto:mick_seaman@ieee.org] > Sent: Tuesday, November 18, 2003 2:12 PM > To: stds-802-1@ieee.org > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 >=20 >=20 > Let's be clear here. I believe Norm is saying that the=20 > service provided to a > bridge by whatever media needs to provide the same integrity=20 > as is provided > by Ethernet today. This may be accomplished by a=20 > CRC-32/integrity check with > Hamming distance of 5/whatever is needed to cover the=20 > particular faults of > the media. In this sense bridges may need a CRC option on=20 > some PW. This is > not a CRC transported through the bridge, and whatever the=20 > media in question > is or locally appears to the bridge to be, if it requires a=20 > CRC additional > to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. >=20 > This is true even if the new MAC is partially constructed out of > 802.3/Ethernet technology, and is documented in the 802.1=20 > July 2003 minutes > (documenting discussion with the 802.3 leadership), and in=20 > the liaison to > the ITU agreed at last week's 802.1 meeting. Any packet=20 > buffering/relay > function required 'inside' such a new media is not an 802.1 bridge. >=20 > For an 802.1 Bridge to use new media/MAC it requires a mapping of the > procedures etc. provided by the media to the Internal=20 > Sublayer Service (ISS) > used by the bridge. See 802.1D Clause 6.5 for mappings for=20 > 802.3, 802.5, > FDDI, and 802.11. These mappings are developed in close=20 > cooperation with the > group responsible for the MAC, and are usually written by=20 > that group, so it > is not in 802.1's gift to arbitrarily add to any existing=20 > mapping. There is > no restriction on such mappings being exclusively developed=20 > by IEEE 802, the > FDDI mapping was developed with the ANSI committee=20 > responsible for FDDI > (I've forgotten its name). >=20 > I am currently confused by the different answers I am getting=20 > on the CRC > question that Scott is posing. In discussion at the meeting=20 > Scott told me > that the proposed PW was using a perfectly adequate CRC, but=20 > hinted at some > other source of faults (badly implemented bridge? thing that=20 > looks like a > bridge to those not familiar with the bridging standards and what = they > require?). >=20 > Mick >=20 > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla > Sent: Tuesday, November 18, 2003 12:22 PM > To: 'Norman Finn' > Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 >=20 > Norman, >=20 > What media are bridges going to be running PW over that does=20 > not have a > CRC? Are you talking about a CRC of the PW payload or a CRC of the = PW > packet including both payload and header? >=20 > Thanks, >=20 > Scott >=20 > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery > Sent: Tuesday, November 18, 2003 10:16 AM > To: Norman Finn > Cc: stds-802-1@ieee.org; pwe3@ietf.org > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 > Hi Norman, >=20 > This is a good formulation of the problem. >=20 > thanks, > mark >=20 > ---- Norman Finn wrote: > > Mark, > > > > You say below, > > > > > but a PW will be running over a physical media itself already, > possibly > > > even SONET............. > > > > Exactly! Here, the trail gets a bit murky. If I'm in=20 > total control, > and the PW > > is running over known Ethernet links, then I can get away=20 > without the > CRC in the > > PW. I have no problem whatsoever with the current definition of = PWs > without CRC. > > > > But, if I don't have tight control over the physical media=20 > over which > the PW runs, > > then I really need a CRC on the PW for the bridge to be=20 > able to trust > the "wire" > > and thus provide the same level of data integrity that bridges = offer > over physical > > Ethernets. So, I claim that bridges need a CRC option on PWs. > > > > -- Norm >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Heiles Juergen Subject: AW: RE: [802.1] 802.1ad Customer FCS Retention Date: Wed, 19 Nov 2003 11:50:51 +0100 Lines: 241 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 19 11:52:07 2003 Return-path: To: "'Scott Kotrla'" , mick_seaman@ieee.org, stds-802-1@ieee.org X-Mailer: Internet Mail Service (5.5.2656.59) 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, the pseudo wire and stacked VLAN case are different in my view. Lets start with the Ethernet pseudo wire case: The client is the Ethernet MAC signal. This could be a untagged frame, a .1Q tagged frame, a .1ad provider tagged frame or even a proprietary .1Q in .1Q tagged frame. The pseudo wire should not care about it. It is mapped into MPLS or IP using the pwe3 mapping. If the pseudo wire is a layer of its own or only a mapping is not relevant for this discussion. So we have the following basic network layering: Ethernet MAC ETH client | | MPLS LSP server client | | xyz server MPLS is a server layer for ETH and MPLS itself is again supported by server layers. MPLS switching, supervision and OAM is independent of the ETH client layer. MPLS can not touch or modify the MAC frame. It is a real tunnel case. With the original pwe3 definitions the MAC FCS would be stripped when the frame was mapped and a end-to-end FCS check of the ETH link over the pseudo wire was not possible. With the optional inclusion of the FCS it is possible. This is the issue Norm is talking about I think. The ETH link over a pseudo wire should provide the same functionality as over a physical Ethernet or as for example over SONET/SDH (using GFP or LAPS). Note that even with the inclusion of the FCS it doesn't always mean that this is the original customer FCS. This is only the case when the Ethernet UNI is directly forwarded to the pseudo wire without any Ethernet bridging in between. In case of a multiplexed access link (service services on the access link separated by VLAN tags) or in the VPLS case (MAC switching) a Ethernet bridge function is located between the UNI and the pseudo wire which does the normal Ethernet FCS processing. Stacked VLAN: With the stacked VLAN we do not introduce new layer. The VLAN provides a method to fragment/part ion an ETH network in several smaller ETH networks (see ITU G.8010 Ethernet Network Architecture which is in the approval process). Connectivity is only possible within the specific VLAN. Forwarding decisions are still based on the MAC addresses. Switching, supervision and OAM is/will be based on the MAC frame and the MAC frame can/will be modified including the FCS. So it is not a real tunnel. Even in this case preserving the customer FCS is useful when errored customer frames would be forwarded through the network and not dropped at the ingress. This is for example the case in SONET/SDH Tandem Connection Monitoring as we do not drop frames with wrong FCS in circuit switched networks. As stated in my earlier mail Ethernet drops frames with wrong FCS. So we have only customer frames with correct FCS forwarded at the ingress UNI. If the normal MAC FCS is not recalculated at each bridge but instead is modified according to the changes to the frame it provides the UNI-to-UNI coverage for the customer frames Scott is looking for without the need to tunnel the customer FCS. Regards Juergen > -----Ursprungliche Nachricht----- > Von: Scott Kotrla [mailto:scott.kotrla@mci.com] > Gesendet: Mittwoch, 19. November 2003 00:09 > An: mick_seaman@ieee.org; stds-802-1@ieee.org > Cc: pwe3@ietf.org > Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Let me attempt to clarify why I brought up Pseudowires in the first > place. > > Pseudowire/Ethernet transport of Ethernet services(protocol stack is > Customer Tagged Ethernet/Pseudowire/Carrier Untagged > Ethernet, note the > Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like > Stacked VLAN transport of Ethernet services (protocol stack > is Customer > Tagged Ethernet/Carrier VLAN). In the Pseudowire model, the customer > FCS (originally tossed in the PWE3 specs but now optionally > maintained) > is an end-to-end Path FCS, while the carrier FCS (always present for > Ethernet over Dark Fiber implementations as part of the underlying L2 > transport of the L2.5 PW frame) is a Link/Line FCS. In the > stacked VLAN > transport, the customer FCS is tossed/overwritten, just like it was in > the PWE3 spec originally. The newly calculated FCS is a > Link/Line FCS. > > > Keeping the customer FCS in PWE3 (when there is already an underlying > Link/Line FCS) is exactly the same as keeping the customer FCS in a > Stacked VLAN model and appending a new Link/Line FCS (instead of > overwriting the customer's FCS). If we can get consensus on > this, then > we should also be able to get consensus that the same functionality > should optionally be available in either architecture. This consensus > has already been reached in PWE3, and my goal is to reach the same > consensus in 802.1. > > As Norm stated, router guys take the underlying error correcting > capabilities that bridges provide for granted, so it should take less > work to convince bridge guys (who understand the importance of error > detection) than it did to convince router guys, which by the way was a > very long and grueling process. > > I plan to put some drawing together showing the protocol stack > similarities as well as the functions required at each point in each > switch for these various scenarios when time permits. > > Hope this textual explanation provides some clarification. > > Thanks, > > Scott > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > Behalf Of Mick > Seaman > Sent: Tuesday, November 18, 2003 4:12 PM > To: stds-802-1@ieee.org > Cc: pwe3@ietf.org > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Let's be clear here. I believe Norm is saying that the > service provided > to a > bridge by whatever media needs to provide the same integrity as is > provided > by Ethernet today. This may be accomplished by a > CRC-32/integrity check > with > Hamming distance of 5/whatever is needed to cover the > particular faults > of > the media. In this sense bridges may need a CRC option on > some PW. This > is > not a CRC transported through the bridge, and whatever the media in > question > is or locally appears to the bridge to be, if it requires a CRC > additional > to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. > > This is true even if the new MAC is partially constructed out of > 802.3/Ethernet technology, and is documented in the 802.1 July 2003 > minutes > (documenting discussion with the 802.3 leadership), and in the liaison > to > the ITU agreed at last week's 802.1 meeting. Any packet > buffering/relay > function required 'inside' such a new media is not an 802.1 bridge. > > For an 802.1 Bridge to use new media/MAC it requires a mapping of the > procedures etc. provided by the media to the Internal Sublayer Service > (ISS) > used by the bridge. See 802.1D Clause 6.5 for mappings for > 802.3, 802.5, > FDDI, and 802.11. These mappings are developed in close > cooperation with > the > group responsible for the MAC, and are usually written by > that group, so > it > is not in 802.1's gift to arbitrarily add to any existing > mapping. There > is > no restriction on such mappings being exclusively developed > by IEEE 802, > the > FDDI mapping was developed with the ANSI committee > responsible for FDDI > (I've forgotten its name). > > I am currently confused by the different answers I am getting > on the CRC > question that Scott is posing. In discussion at the meeting Scott told > me > that the proposed PW was using a perfectly adequate CRC, but hinted at > some > other source of faults (badly implemented bridge? thing that > looks like > a > bridge to those not familiar with the bridging standards and what they > require?). > > Mick > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla > Sent: Tuesday, November 18, 2003 12:22 PM > To: 'Norman Finn' > Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > Norman, > > What media are bridges going to be running PW over that does > not have a > CRC? Are you talking about a CRC of the PW payload or a CRC of the PW > packet including both payload and header? > > Thanks, > > Scott > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery > Sent: Tuesday, November 18, 2003 10:16 AM > To: Norman Finn > Cc: stds-802-1@ieee.org; pwe3@ietf.org > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Hi Norman, > > This is a good formulation of the problem. > > thanks, > mark > > ---- Norman Finn wrote: > > Mark, > > > > You say below, > > > > > but a PW will be running over a physical media itself already, > possibly > > > even SONET............. > > > > Exactly! Here, the trail gets a bit murky. If I'm in > total control, > and the PW > > is running over known Ethernet links, then I can get away > without the > CRC in the > > PW. I have no problem whatsoever with the current definition of PWs > without CRC. > > > > But, if I don't have tight control over the physical media > over which > the PW runs, > > then I really need a CRC on the PW for the bridge to be > able to trust > the "wire" > > and thus provide the same level of data integrity that bridges offer > over physical > > Ethernets. So, I claim that bridges need a CRC option on PWs. > > > > -- Norm > > > > > > _______________________________________________ > 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: pat_thaler@agilent.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 18 Nov 2003 16:38:52 -0700 Lines: 115 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 Nov 19 14:58:11 2003 Return-path: To: mick_seaman@ieee.org, stds-802-1@ieee.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 am also confused about the same point. Some people such as Norm seem to be concerned about a CRC over the media and some seem to be concerned about an end to end CRC to protect against errors during CRC regeneration in bridges. Of course as long as all the media are using the same CRC polynomial, the bridges could adjust the original CRC for any packet changes rather than regenerate. Personally, I think 802.1 Appendix G makes this look more complicated than it is. Attempting an end-to-end MAC layer CRC isn't worthwhile. As soon as one goes through a higher layer device such as a router, it will get tossed and regenerated anyway (unless they do CRC adjustment for IP and MAC header changes which seems unlikely). If real end-to-end protection against corruption is desired, then the place to do it is in transport or above. Pat P.S. the CRC-32 provides Hamming distance of 4 - it detects all 3 bit errors up to something larger than 8 K. -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Tuesday, November 18, 2003 2:12 PM To: stds-802-1@ieee.org Cc: pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Let's be clear here. I believe Norm is saying that the service provided to a bridge by whatever media needs to provide the same integrity as is provided by Ethernet today. This may be accomplished by a CRC-32/integrity check with Hamming distance of 5/whatever is needed to cover the particular faults of the media. In this sense bridges may need a CRC option on some PW. This is not a CRC transported through the bridge, and whatever the media in question is or locally appears to the bridge to be, if it requires a CRC additional to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. This is true even if the new MAC is partially constructed out of 802.3/Ethernet technology, and is documented in the 802.1 July 2003 minutes (documenting discussion with the 802.3 leadership), and in the liaison to the ITU agreed at last week's 802.1 meeting. Any packet buffering/relay function required 'inside' such a new media is not an 802.1 bridge. For an 802.1 Bridge to use new media/MAC it requires a mapping of the procedures etc. provided by the media to the Internal Sublayer Service (ISS) used by the bridge. See 802.1D Clause 6.5 for mappings for 802.3, 802.5, FDDI, and 802.11. These mappings are developed in close cooperation with the group responsible for the MAC, and are usually written by that group, so it is not in 802.1's gift to arbitrarily add to any existing mapping. There is no restriction on such mappings being exclusively developed by IEEE 802, the FDDI mapping was developed with the ANSI committee responsible for FDDI (I've forgotten its name). I am currently confused by the different answers I am getting on the CRC question that Scott is posing. In discussion at the meeting Scott told me that the proposed PW was using a perfectly adequate CRC, but hinted at some other source of faults (badly implemented bridge? thing that looks like a bridge to those not familiar with the bridging standards and what they require?). Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 18, 2003 12:22 PM To: 'Norman Finn' Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Norman, What media are bridges going to be running PW over that does not have a CRC? Are you talking about a CRC of the PW payload or a CRC of the PW packet including both payload and header? Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery Sent: Tuesday, November 18, 2003 10:16 AM To: Norman Finn Cc: stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norman, This is a good formulation of the problem. thanks, mark ---- Norman Finn wrote: > Mark, > > You say below, > > > but a PW will be running over a physical media itself already, possibly > > even SONET............. > > Exactly! Here, the trail gets a bit murky. If I'm in total control, and the PW > is running over known Ethernet links, then I can get away without the CRC in the > PW. I have no problem whatsoever with the current definition of PWs without CRC. > > But, if I don't have tight control over the physical media over which the PW runs, > then I really need a CRC on the PW for the bridge to be able to trust the "wire" > and thus provide the same level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs. > > -- Norm From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Danny McPherson Subject: IETF 58 Minutes Date: Wed, 19 Nov 2003 19:33:37 -0700 Lines: 11 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Thu Nov 20 04:59:08 2003 Return-path: To: pwe3@ietf.org X-Mailer: Apple Mail (2.606) 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 Folks, Please provide corrections/additions to the minutes to Stewart and I by 12/5. Again, the minutes are located here, along with the rest of the proceedings: http://pwe3.tcb.net/meetings/ietf58 Thanks! -danny From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Heiles Juergen Subject: AW: RE: [802.1] 802.1ad Customer FCS Retention Date: Thu, 20 Nov 2003 11:22:59 +0100 Lines: 339 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Thu Nov 20 11:24:10 2003 Return-path: To: Heiles Juergen , "'Scott Kotrla'" , mick_seaman@ieee.org, stds-802-1@ieee.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 had some further thoughts on the FCS issue and noted a major difference between FCS processing in circuit an packet switched networks. In a circuit switched network like SONET/SDH the FCS is bound to the trail while in a packet switched network like Ethernet it is bound to the link. In a circuit switched network a client frame is not dropped in case of bit errors detected by the server layer or link. It is still forwarded downstream and its payload can still be useful. In a packet network a frame is dropped in case of a server layer/link FCS error. One reason for this is in my view that packet networks have the forwarding information (address, label) as part of the frame itself. In case of a FCS error this information might be corrupted and correct forwarding is not guaranteed. In a circuit switched network the forwarding information is the timeslot which is a implicit information which can not be corrupted by bit errors (except for the case of excessive bit errors that result in loss of frame synchronization in which case the frame is also dropped = all-ONEs/AIS insertion). In addition circuit switched networks use in-frame multiplexing which means that frames from several clients are multiplexed into a single server layer frame. A server layer FCS err! or may only effect some, but not all of the client layer frames. Packet networks have often a one-to-one frame mapping between client and server layers or a 1 to n mapping where a client frame is split over several server frames. So server frame FCS errors are directly related to client frame FCS error. Circuit switched networks use a FCS often at all layers (SONET/SDH, OTN) while packet networks use it often only at a single layer, the link layer. In SDH the VC-4 BIP-8 is generated at the termination source and checked at the termination sink. The check at the termination sink provides the information about the error performance of the VC-4 trail. In addition we have BIPs at the multiplex section and regenerator section layer. These are mainly for error localization and protection switching trigger at these layers. In an Ethernet network the frame is dropped in case the link detects an error. One cannot get the error performance of the connection by just checking the FCS at the termination (end station, or egress UNI) as only good frames are passed to it and only information about the dropped frames of the last link are available. For the error performance the number of dropped frames of each link has to be added or one makes a comparison between the number of ingress and egress frames. The difference gives the number of dropped frames = error performance. This can be used for point-to-point connections (line), but gets difficult for multi-point-to-multi-point connections (LAN). The different behavior means also that a end-to-end FCS is not required for a packet service, what is required is a full coverage of error checks which for example could consists of link FCS and internal error supervision of the network elements. If any of the two detects errors the frame is dropped. This leads to the same frame dropped as an end-to-end FCS. This approach however is problematic as it is difficult to standardize internal error supervision of network elements and very difficult for operators to test the internal supervision. SO they have problems to trust this functionality. A end-to-end FCS is easier to handle. Regards Juergen > -----Ursprungliche Nachricht----- > Von: Heiles Juergen [mailto:juergen.heiles@siemens.com] > Gesendet: Mittwoch, 19. November 2003 11:51 > An: 'Scott Kotrla'; mick_seaman@ieee.org; stds-802-1@ieee.org > Cc: pwe3@ietf.org > Betreff: AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Scott, > > the pseudo wire and stacked VLAN case are different in my view. > Lets start with the Ethernet pseudo wire case: > > The client is the Ethernet MAC signal. This could be a > untagged frame, a .1Q tagged frame, a .1ad provider tagged > frame or even a proprietary .1Q in .1Q tagged frame. The > pseudo wire should not care about it. It is mapped into MPLS > or IP using the pwe3 mapping. If the pseudo wire is a layer > of its own or only a mapping is not relevant for this > discussion. So we have the following basic network layering: > > > Ethernet MAC ETH client > | | > MPLS LSP server client > | | > xyz server > > MPLS is a server layer for ETH and MPLS itself is again > supported by server layers. MPLS switching, supervision and > OAM is independent of the ETH client layer. MPLS can not > touch or modify the MAC frame. It is a real tunnel case. > With the original pwe3 definitions the MAC FCS would be > stripped when the frame was mapped and a end-to-end FCS check > of the ETH link over the pseudo wire was not possible. With > the optional inclusion of the FCS it is possible. This is the > issue Norm is talking about I think. The ETH link over a > pseudo wire should provide the same functionality as over a > physical Ethernet or as for example over SONET/SDH (using GFP > or LAPS). > Note that even with the inclusion of the FCS it doesn't > always mean that this is the original customer FCS. This is > only the case when the Ethernet UNI is directly forwarded to > the pseudo wire without any Ethernet bridging in between. In > case of a multiplexed access link (service services on the > access link separated by VLAN tags) or in the VPLS case (MAC > switching) a Ethernet bridge function is located between the > UNI and the pseudo wire which does the normal Ethernet FCS processing. > > Stacked VLAN: > With the stacked VLAN we do not introduce new layer. The VLAN > provides a method to fragment/part ion an ETH network in > several smaller ETH networks (see ITU G.8010 Ethernet Network > Architecture which is in the approval process). Connectivity > is only possible within the specific VLAN. Forwarding > decisions are still based on the MAC addresses. Switching, > supervision and OAM is/will be based on the MAC frame and the > MAC frame can/will be modified including the FCS. So it is > not a real tunnel. > Even in this case preserving the customer FCS is useful when > errored customer frames would be forwarded through the > network and not dropped at the ingress. This is for example > the case in SONET/SDH Tandem Connection Monitoring as we do > not drop frames with wrong FCS in circuit switched networks. > As stated in my earlier mail Ethernet drops frames with wrong > FCS. So we have only customer frames with correct FCS > forwarded at the ingress UNI. If the normal MAC FCS is not > recalculated at each bridge but instead is modified according > to the changes to the frame it provides the UNI-to-UNI > coverage for the customer frames Scott is looking for without > the need to tunnel the customer FCS. > > > Regards > > Juergen > > > > > -----Ursprungliche Nachricht----- > > Von: Scott Kotrla [mailto:scott.kotrla@mci.com] > > Gesendet: Mittwoch, 19. November 2003 00:09 > > An: mick_seaman@ieee.org; stds-802-1@ieee.org > > Cc: pwe3@ietf.org > > Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Let me attempt to clarify why I brought up Pseudowires in the first > > place. > > > > Pseudowire/Ethernet transport of Ethernet services(protocol stack is > > Customer Tagged Ethernet/Pseudowire/Carrier Untagged > > Ethernet, note the > > Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like > > Stacked VLAN transport of Ethernet services (protocol stack > > is Customer > > Tagged Ethernet/Carrier VLAN). In the Pseudowire model, > the customer > > FCS (originally tossed in the PWE3 specs but now optionally > > maintained) > > is an end-to-end Path FCS, while the carrier FCS (always present for > > Ethernet over Dark Fiber implementations as part of the > underlying L2 > > transport of the L2.5 PW frame) is a Link/Line FCS. In the > > stacked VLAN > > transport, the customer FCS is tossed/overwritten, just > like it was in > > the PWE3 spec originally. The newly calculated FCS is a > > Link/Line FCS. > > > > > > Keeping the customer FCS in PWE3 (when there is already an > underlying > > Link/Line FCS) is exactly the same as keeping the customer FCS in a > > Stacked VLAN model and appending a new Link/Line FCS (instead of > > overwriting the customer's FCS). If we can get consensus on > > this, then > > we should also be able to get consensus that the same functionality > > should optionally be available in either architecture. > This consensus > > has already been reached in PWE3, and my goal is to reach the same > > consensus in 802.1. > > > > As Norm stated, router guys take the underlying error correcting > > capabilities that bridges provide for granted, so it should > take less > > work to convince bridge guys (who understand the importance of error > > detection) than it did to convince router guys, which by > the way was a > > very long and grueling process. > > > > I plan to put some drawing together showing the protocol stack > > similarities as well as the functions required at each point in each > > switch for these various scenarios when time permits. > > > > Hope this textual explanation provides some clarification. > > > > Thanks, > > > > Scott > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Mick > > Seaman > > Sent: Tuesday, November 18, 2003 4:12 PM > > To: stds-802-1@ieee.org > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Let's be clear here. I believe Norm is saying that the > > service provided > > to a > > bridge by whatever media needs to provide the same integrity as is > > provided > > by Ethernet today. This may be accomplished by a > > CRC-32/integrity check > > with > > Hamming distance of 5/whatever is needed to cover the > > particular faults > > of > > the media. In this sense bridges may need a CRC option on > > some PW. This > > is > > not a CRC transported through the bridge, and whatever the media in > > question > > is or locally appears to the bridge to be, if it requires a CRC > > additional > > to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. > > > > This is true even if the new MAC is partially constructed out of > > 802.3/Ethernet technology, and is documented in the 802.1 July 2003 > > minutes > > (documenting discussion with the 802.3 leadership), and in > the liaison > > to > > the ITU agreed at last week's 802.1 meeting. Any packet > > buffering/relay > > function required 'inside' such a new media is not an 802.1 bridge. > > > > For an 802.1 Bridge to use new media/MAC it requires a > mapping of the > > procedures etc. provided by the media to the Internal > Sublayer Service > > (ISS) > > used by the bridge. See 802.1D Clause 6.5 for mappings for > > 802.3, 802.5, > > FDDI, and 802.11. These mappings are developed in close > > cooperation with > > the > > group responsible for the MAC, and are usually written by > > that group, so > > it > > is not in 802.1's gift to arbitrarily add to any existing > > mapping. There > > is > > no restriction on such mappings being exclusively developed > > by IEEE 802, > > the > > FDDI mapping was developed with the ANSI committee > > responsible for FDDI > > (I've forgotten its name). > > > > I am currently confused by the different answers I am getting > > on the CRC > > question that Scott is posing. In discussion at the meeting > Scott told > > me > > that the proposed PW was using a perfectly adequate CRC, > but hinted at > > some > > other source of faults (badly implemented bridge? thing that > > looks like > > a > > bridge to those not familiar with the bridging standards > and what they > > require?). > > > > Mick > > > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of > Scott Kotrla > > Sent: Tuesday, November 18, 2003 12:22 PM > > To: 'Norman Finn' > > Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > > > Norman, > > > > What media are bridges going to be running PW over that does > > not have a > > CRC? Are you talking about a CRC of the PW payload or a > CRC of the PW > > packet including both payload and header? > > > > Thanks, > > > > Scott > > > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery > > Sent: Tuesday, November 18, 2003 10:16 AM > > To: Norman Finn > > Cc: stds-802-1@ieee.org; pwe3@ietf.org > > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Hi Norman, > > > > This is a good formulation of the problem. > > > > thanks, > > mark > > > > ---- Norman Finn wrote: > > > Mark, > > > > > > You say below, > > > > > > > but a PW will be running over a physical media itself already, > > possibly > > > > even SONET............. > > > > > > Exactly! Here, the trail gets a bit murky. If I'm in > > total control, > > and the PW > > > is running over known Ethernet links, then I can get away > > without the > > CRC in the > > > PW. I have no problem whatsoever with the current > definition of PWs > > without CRC. > > > > > > But, if I don't have tight control over the physical media > > over which > > the PW runs, > > > then I really need a CRC on the PW for the bridge to be > > able to trust > > the "wire" > > > and thus provide the same level of data integrity that > bridges offer > > over physical > > > Ethernets. So, I claim that bridges need a CRC option on PWs. > > > > > > -- Norm > > > > > > > > > > > > _______________________________________________ > > 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: Akiva Sadovski Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 09:39:34 +0200 Lines: 411 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: "'pwe3@ietf.org '" X-From: pwe3-admin@ietf.org Fri Nov 21 08:42:24 2003 Return-path: To: "'Heiles Juergen '" 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 Juergen, 1) thank you for your thorough explanation 2) however the question is how we can stretch your FCS/BIP processing model to cover the PW case: should the PW be considered as an "Ethernet network link" that has to be protected by FCS or as a "packet service" ? IMHO the PW is closer to the "link"... Regards, Akiva Sadovski -----Original Message----- From: Heiles Juergen To: Heiles Juergen; 'Scott Kotrla'; mick_seaman@ieee.org; stds-802-1@ieee.org Cc: pwe3@ietf.org Sent: 20/11/2003 12:22 Subject: AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention I had some further thoughts on the FCS issue and noted a major difference between FCS processing in circuit an packet switched networks. In a circuit switched network like SONET/SDH the FCS is bound to the trail while in a packet switched network like Ethernet it is bound to the link. In a circuit switched network a client frame is not dropped in case of bit errors detected by the server layer or link. It is still forwarded downstream and its payload can still be useful. In a packet network a frame is dropped in case of a server layer/link FCS error. One reason for this is in my view that packet networks have the forwarding information (address, label) as part of the frame itself. In case of a FCS error this information might be corrupted and correct forwarding is not guaranteed. In a circuit switched network the forwarding information is the timeslot which is a implicit information which can not be corrupted by bit errors (except for the case of excessive bit errors that result in loss of frame synchronization in which case the frame is also dropped = all-ONEs/AIS insertion). In addition circuit switched networks use in-frame multiplexing which means that frames from several clients are multiplexed into a single server layer frame. A server layer FCS err! or may only effect some, but not all of the client layer frames. Packet networks have often a one-to-one frame mapping between client and server layers or a 1 to n mapping where a client frame is split over several server frames. So server frame FCS errors are directly related to client frame FCS error. Circuit switched networks use a FCS often at all layers (SONET/SDH, OTN) while packet networks use it often only at a single layer, the link layer. In SDH the VC-4 BIP-8 is generated at the termination source and checked at the termination sink. The check at the termination sink provides the information about the error performance of the VC-4 trail. In addition we have BIPs at the multiplex section and regenerator section layer. These are mainly for error localization and protection switching trigger at these layers. In an Ethernet network the frame is dropped in case the link detects an error. One cannot get the error performance of the connection by just checking the FCS at the termination (end station, or egress UNI) as only good frames are passed to it and only information about the dropped frames of the last link are available. For the error performance the number of dropped frames of each link has to be added or one makes a comparison between the number of ingress and egress frames. The difference gives the number of dropped frames = error performance. This can be used for point-to-point connections (line), but gets difficult for multi-point-to-multi-point connections (LAN). The different behavior means also that a end-to-end FCS is not required for a packet service, what is required is a full coverage of error checks which for example could consists of link FCS and internal error supervision of the network elements. If any of the two detects errors the frame is dropped. This leads to the same frame dropped as an end-to-end FCS. This approach however is problematic as it is difficult to standardize internal error supervision of network elements and very difficult for operators to test the internal supervision. SO they have problems to trust this functionality. A end-to-end FCS is easier to handle. Regards Juergen > -----Ursprungliche Nachricht----- > Von: Heiles Juergen [mailto:juergen.heiles@siemens.com] > Gesendet: Mittwoch, 19. November 2003 11:51 > An: 'Scott Kotrla'; mick_seaman@ieee.org; stds-802-1@ieee.org > Cc: pwe3@ietf.org > Betreff: AW: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Scott, > > the pseudo wire and stacked VLAN case are different in my view. > Lets start with the Ethernet pseudo wire case: > > The client is the Ethernet MAC signal. This could be a > untagged frame, a .1Q tagged frame, a .1ad provider tagged > frame or even a proprietary .1Q in .1Q tagged frame. The > pseudo wire should not care about it. It is mapped into MPLS > or IP using the pwe3 mapping. If the pseudo wire is a layer > of its own or only a mapping is not relevant for this > discussion. So we have the following basic network layering: > > > Ethernet MAC ETH client > | | > MPLS LSP server client > | | > xyz server > > MPLS is a server layer for ETH and MPLS itself is again > supported by server layers. MPLS switching, supervision and > OAM is independent of the ETH client layer. MPLS can not > touch or modify the MAC frame. It is a real tunnel case. > With the original pwe3 definitions the MAC FCS would be > stripped when the frame was mapped and a end-to-end FCS check > of the ETH link over the pseudo wire was not possible. With > the optional inclusion of the FCS it is possible. This is the > issue Norm is talking about I think. The ETH link over a > pseudo wire should provide the same functionality as over a > physical Ethernet or as for example over SONET/SDH (using GFP > or LAPS). > Note that even with the inclusion of the FCS it doesn't > always mean that this is the original customer FCS. This is > only the case when the Ethernet UNI is directly forwarded to > the pseudo wire without any Ethernet bridging in between. In > case of a multiplexed access link (service services on the > access link separated by VLAN tags) or in the VPLS case (MAC > switching) a Ethernet bridge function is located between the > UNI and the pseudo wire which does the normal Ethernet FCS processing. > > Stacked VLAN: > With the stacked VLAN we do not introduce new layer. The VLAN > provides a method to fragment/part ion an ETH network in > several smaller ETH networks (see ITU G.8010 Ethernet Network > Architecture which is in the approval process). Connectivity > is only possible within the specific VLAN. Forwarding > decisions are still based on the MAC addresses. Switching, > supervision and OAM is/will be based on the MAC frame and the > MAC frame can/will be modified including the FCS. So it is > not a real tunnel. > Even in this case preserving the customer FCS is useful when > errored customer frames would be forwarded through the > network and not dropped at the ingress. This is for example > the case in SONET/SDH Tandem Connection Monitoring as we do > not drop frames with wrong FCS in circuit switched networks. > As stated in my earlier mail Ethernet drops frames with wrong > FCS. So we have only customer frames with correct FCS > forwarded at the ingress UNI. If the normal MAC FCS is not > recalculated at each bridge but instead is modified according > to the changes to the frame it provides the UNI-to-UNI > coverage for the customer frames Scott is looking for without > the need to tunnel the customer FCS. > > > Regards > > Juergen > > > > > -----Ursprungliche Nachricht----- > > Von: Scott Kotrla [mailto:scott.kotrla@mci.com] > > Gesendet: Mittwoch, 19. November 2003 00:09 > > An: mick_seaman@ieee.org; stds-802-1@ieee.org > > Cc: pwe3@ietf.org > > Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Let me attempt to clarify why I brought up Pseudowires in the first > > place. > > > > Pseudowire/Ethernet transport of Ethernet services(protocol stack is > > Customer Tagged Ethernet/Pseudowire/Carrier Untagged > > Ethernet, note the > > Carrier Ethernet could be GFP, HDLC, X.86, etc.) looks a lot like > > Stacked VLAN transport of Ethernet services (protocol stack > > is Customer > > Tagged Ethernet/Carrier VLAN). In the Pseudowire model, > the customer > > FCS (originally tossed in the PWE3 specs but now optionally > > maintained) > > is an end-to-end Path FCS, while the carrier FCS (always present for > > Ethernet over Dark Fiber implementations as part of the > underlying L2 > > transport of the L2.5 PW frame) is a Link/Line FCS. In the > > stacked VLAN > > transport, the customer FCS is tossed/overwritten, just > like it was in > > the PWE3 spec originally. The newly calculated FCS is a > > Link/Line FCS. > > > > > > Keeping the customer FCS in PWE3 (when there is already an > underlying > > Link/Line FCS) is exactly the same as keeping the customer FCS in a > > Stacked VLAN model and appending a new Link/Line FCS (instead of > > overwriting the customer's FCS). If we can get consensus on > > this, then > > we should also be able to get consensus that the same functionality > > should optionally be available in either architecture. > This consensus > > has already been reached in PWE3, and my goal is to reach the same > > consensus in 802.1. > > > > As Norm stated, router guys take the underlying error correcting > > capabilities that bridges provide for granted, so it should > take less > > work to convince bridge guys (who understand the importance of error > > detection) than it did to convince router guys, which by > the way was a > > very long and grueling process. > > > > I plan to put some drawing together showing the protocol stack > > similarities as well as the functions required at each point in each > > switch for these various scenarios when time permits. > > > > Hope this textual explanation provides some clarification. > > > > Thanks, > > > > Scott > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On > > Behalf Of Mick > > Seaman > > Sent: Tuesday, November 18, 2003 4:12 PM > > To: stds-802-1@ieee.org > > Cc: pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Let's be clear here. I believe Norm is saying that the > > service provided > > to a > > bridge by whatever media needs to provide the same integrity as is > > provided > > by Ethernet today. This may be accomplished by a > > CRC-32/integrity check > > with > > Hamming distance of 5/whatever is needed to cover the > > particular faults > > of > > the media. In this sense bridges may need a CRC option on > > some PW. This > > is > > not a CRC transported through the bridge, and whatever the media in > > question > > is or locally appears to the bridge to be, if it requires a CRC > > additional > > to the Ethernet CRC it is *not* Ethernet but a *new MAC type*. > > > > This is true even if the new MAC is partially constructed out of > > 802.3/Ethernet technology, and is documented in the 802.1 July 2003 > > minutes > > (documenting discussion with the 802.3 leadership), and in > the liaison > > to > > the ITU agreed at last week's 802.1 meeting. Any packet > > buffering/relay > > function required 'inside' such a new media is not an 802.1 bridge. > > > > For an 802.1 Bridge to use new media/MAC it requires a > mapping of the > > procedures etc. provided by the media to the Internal > Sublayer Service > > (ISS) > > used by the bridge. See 802.1D Clause 6.5 for mappings for > > 802.3, 802.5, > > FDDI, and 802.11. These mappings are developed in close > > cooperation with > > the > > group responsible for the MAC, and are usually written by > > that group, so > > it > > is not in 802.1's gift to arbitrarily add to any existing > > mapping. There > > is > > no restriction on such mappings being exclusively developed > > by IEEE 802, > > the > > FDDI mapping was developed with the ANSI committee > > responsible for FDDI > > (I've forgotten its name). > > > > I am currently confused by the different answers I am getting > > on the CRC > > question that Scott is posing. In discussion at the meeting > Scott told > > me > > that the proposed PW was using a perfectly adequate CRC, > but hinted at > > some > > other source of faults (badly implemented bridge? thing that > > looks like > > a > > bridge to those not familiar with the bridging standards > and what they > > require?). > > > > Mick > > > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of > Scott Kotrla > > Sent: Tuesday, November 18, 2003 12:22 PM > > To: 'Norman Finn' > > Cc: stds-802-1@ieee.org; pwe3@ietf.org; 'mark seery' > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > > > Norman, > > > > What media are bridges going to be running PW over that does > > not have a > > CRC? Are you talking about a CRC of the PW payload or a > CRC of the PW > > packet including both payload and header? > > > > Thanks, > > > > Scott > > > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery > > Sent: Tuesday, November 18, 2003 10:16 AM > > To: Norman Finn > > Cc: stds-802-1@ieee.org; pwe3@ietf.org > > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Hi Norman, > > > > This is a good formulation of the problem. > > > > thanks, > > mark > > > > ---- Norman Finn wrote: > > > Mark, > > > > > > You say below, > > > > > > > but a PW will be running over a physical media itself already, > > possibly > > > > even SONET............. > > > > > > Exactly! Here, the trail gets a bit murky. If I'm in > > total control, > > and the PW > > > is running over known Ethernet links, then I can get away > > without the > > CRC in the > > > PW. I have no problem whatsoever with the current > definition of PWs > > without CRC. > > > > > > But, if I don't have tight control over the physical media > > over which > > the PW runs, > > > then I really need a CRC on the PW for the bridge to be > > able to trust > > the "wire" > > > and thus provide the same level of data integrity that > bridges offer > > over physical > > > Ethernets. So, I claim that bridges need a CRC option on PWs. > > > > > > -- Norm > > > > > > > > > > > > _______________________________________________ > > 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 > _______________________________________________ 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: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 12:28:43 +0100 Lines: 94 Sender: pwe3-admin@ietf.org References: <000801c3ae11$a0b995e0$338c23a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org, "'mark seery'" X-From: pwe3-admin@ietf.org Fri Nov 21 12:30:06 2003 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, fr, de, ru, ja, zh To: Scott Kotrla 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, Over what media can routers run? Wet string? There are media in use that have, in effect, only a 16-bit checksum. If the endpoints of the PW have knowledge of the underlying media on which the PW runs, and if those media have satisfactory data integrity protection, and if the methods of encapsulation and decapsulation have a suitable mathematical and/or implementation basis to suppose that they won't introduce significant errors, then you're done. On the other hand, one of the purposes of layering is precisely to insulate the upper layers from knowledge of the lower. If the ends of the PW do not know that the data is as safe as an Ethernet frame, then the Ether-over- whatever (i.e. PW) application needs its own checksum over its own data. This checksum certainly covers every bit of the Ethernet frame payload. If the checksum chosen is a polynomial CRC, presumably the IEEE 802 one, then it has the property of being extendable to cover some PW header information without compromise, just as it is used to cover added 802.1Q tags. I'm not expert enough on the various PW techniques to tell you for sure whether that's needed or not, but I doubt that it's necessary. -- Norm Scott Kotrla wrote: > Norman, > > What media are bridges going to be running PW over that does not have a > CRC? Are you talking about a CRC of the PW payload or a CRC of the PW > packet including both payload and header? > > Thanks, > > Scott > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of mark seery > Sent: Tuesday, November 18, 2003 10:16 AM > To: Norman Finn > Cc: stds-802-1@ieee.org; pwe3@ietf.org > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Hi Norman, > > This is a good formulation of the problem. > > thanks, > mark > > ---- Norman Finn wrote: > >>Mark, >> >>You say below, >> >> > but a PW will be running over a physical media itself already, > > possibly > >> > even SONET............. >> >>Exactly! Here, the trail gets a bit murky. If I'm in total control, > > and the PW > >>is running over known Ethernet links, then I can get away without the > > CRC in the > >>PW. I have no problem whatsoever with the current definition of PWs > > without CRC. > >>But, if I don't have tight control over the physical media over which > > the PW runs, > >>then I really need a CRC on the PW for the bridge to be able to trust > > the "wire" > >>and thus provide the same level of data integrity that bridges offer > > over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. >> >>-- Norm > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Norman Finn Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 13:03:07 +0100 Lines: 128 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E61@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 21 13:04:01 2003 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, fr, de, ru, ja, zh 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 think Pat Thaler's reply helps to straighten out this confusion, but let me try, also. There is a *lot* of confusion about the words "end-to-end", and about "transport layers". There are lots of ends in this picture, and there are layers and there are layers. An 802.1Q VLAN bridge, and by extension, a P802.1ad provider bridge, does NOT supply a "transport layer" in the same sense as IP-over-Ethernet or Ethernet-over-IP. This is because, at the data forwarding layers, VLAN tags are best though of as extensions to the address space, not as additional protocol layers. If you want to call it a "transport layer", feel free! But don't assume that VLANs are equivalent to other "transport layers". Data integrity, specifically, is different in bridges. Routers provide "best effort" not only in frame delivery, but in data integrity. There is no upper limit specified for the probability of delivery of a packet with undetected errors. IP's response, if you demand a particular level of data integrity, is that your application must supply its own checksum. Bridges, however, are not routers! Bridges *do* guarantee a level of service. They manage to do this by guaranteeing the quality of each bridge, and by *demanding* the quality of each link. Non-VLAN bridges, VLAN bridges, and Provider Bridges all make that guarantee to their users using this method. The Customers of a Provider Bridge service are not an "802.1Q application" over an "802.1ad transport layer". They are, in the 802.1 model, just endstations attached to a bridge. The Customers' data is just as well protected as an enterprise bridges' endstations, as long as the model is maintained. Adding an additional CRC to end-to-end service, where the ends are Customers attached to 802.1ad Provider Bridges, is therefore pointless. Changing that model is as silly as turning the model for routing upside down. When a Pseudowire is used to connect two bridges, the "end-to-end" is now just those two bridges. Those bridges are using that PW as an Ethernet to carry their traffic. The bridges demand that every wire be as reliable as an Ethernet. That's the PW CRC issue. -- Norm neil.2.harrison@bt.com wrote: > Norm....As per our discussion today face-face. I don't really see what the problem is here. The client layer network should not care about the server layer network (and vice versa)....we need this layer independence for lots of reasons. An ethernet traffic unit has a FCS. This should simply be transported transparently in the payload area of whatever the server layer is....and the server layer should use its own (OAM) 'integrity mechanisms' irrespective of the client. Problems arise when people start doing things like client layer compression and thus forming inter-layer dependencies. > > Further, as we agreed today and as I posted on an earlier mail to this thread, the ethernet FCS is a CRC that can be linerarly updated for adaptation function changes (eg VLAN ID change) on each link-connection (as provided by some server layer trail technology) whilst preserving its end-end intergrity check of the rest of the ethernet traffic unit between its trail termination points. > > regards, Neil > > >>-----Original Message----- >>From: Norman Finn [mailto:nfinn@cisco.com] >>Sent: 18 November 2003 08:56 >>To: mark seery >>Cc: stds-802-1@ieee.org; pwe3@ietf.org >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >> >> >>Mark, >> >>You say below, >> >> > but a PW will be running over a physical media itself >>already, possibly >> > even SONET............. >> >>Exactly! Here, the trail gets a bit murky. If I'm in total >>control, and the PW >>is running over known Ethernet links, then I can get away >>without the CRC in the >>PW. I have no problem whatsoever with the current definition >>of PWs without CRC. >> >>But, if I don't have tight control over the physical media >>over which the PW runs, >>then I really need a CRC on the PW for the bridge to be able >>to trust the "wire" >>and thus provide the same level of data integrity that >>bridges offer over physical >>Ethernets. So, I claim that bridges need a CRC option on PWs. >> >>-- Norm >> >>mark seery wrote: >> >>>Norman Finn wrote: >>> >>> >>>> >>>>In other words, routers pass about $0.93 of the data >>> >>integrity buck to >> >>>>bridges, >>>>and bridges pass about $0.75 of that to the data links. >>> >>The buck has >> >>>>to stop >>>>somewhere, and the data link is where it stops. The PW >>> >>has to take >> >>>>the same >>>>hit as the physical media. >>>> >>>>-- Norm >>> >>> >>>but a PW will be running over a physical media itself >> >>already, possibly >> >>>even SONET............. >>> >>>mark >>> >>> >>> >>> >> >> >> >>_______________________________________________ >>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: "Marc Holness" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 10:49:30 -0500 Lines: 422 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B047.0CF3D4BE" Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 21 16:51:16 2003 Return-path: To: Norman Finn , neil.2.harrison@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 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_01C3B047.0CF3D4BE Content-Type: text/plain Norm. I gather that Service Providers (which purchase and deploy or plan to deploy Ethernet bridging equipment) find it exceedingly difficult, if not next to impossible, to determine that each piece of bridging equipment uniformly adheres to the 802.1 model. Consequently, I would not categorize having a mechanism that supports a path like (i.e., end-to-end) integrity validation (via preservation of the client Ethernet FCS) as *pointless*. Rather I believe it should be a considered requirement. Marc. -----Original Message----- From: Norman Finn [mailto:nfinn@cisco.com] Sent: Friday, November 21, 2003 7:03 AM To: neil.2.harrison@bt.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Neil, I think Pat Thaler's reply helps to straighten out this confusion, but let me try, also. There is a *lot* of confusion about the words "end-to-end", and about "transport layers". There are lots of ends in this picture, and there are layers and there are layers. An 802.1Q VLAN bridge, and by extension, a P802.1ad provider bridge, does NOT supply a "transport layer" in the same sense as IP-over-Ethernet or Ethernet-over-IP. This is because, at the data forwarding layers, VLAN tags are best though of as extensions to the address space, not as additional protocol layers. If you want to call it a "transport layer", feel free! But don't assume that VLANs are equivalent to other "transport layers". Data integrity, specifically, is different in bridges. Routers provide "best effort" not only in frame delivery, but in data integrity. There is no upper limit specified for the probability of delivery of a packet with undetected errors. IP's response, if you demand a particular level of data integrity, is that your application must supply its own checksum. Bridges, however, are not routers! Bridges *do* guarantee a level of service. They manage to do this by guaranteeing the quality of each bridge, and by *demanding* the quality of each link. Non-VLAN bridges, VLAN bridges, and Provider Bridges all make that guarantee to their users using this method. The Customers of a Provider Bridge service are not an "802.1Q application" over an "802.1ad transport layer". They are, in the 802.1 model, just endstations attached to a bridge. The Customers' data is just as well protected as an enterprise bridges' endstations, as long as the model is maintained. Adding an additional CRC to end-to-end service, where the ends are Customers attached to 802.1ad Provider Bridges, is therefore pointless. Changing that model is as silly as turning the model for routing upside down. When a Pseudowire is used to connect two bridges, the "end-to-end" is now just those two bridges. Those bridges are using that PW as an Ethernet to carry their traffic. The bridges demand that every wire be as reliable as an Ethernet. That's the PW CRC issue. -- Norm neil.2.harrison@bt.com wrote: > Norm....As per our discussion today face-face. I don't really see > what the problem is here. The client layer network should not care > about the server layer network (and vice versa)....we need this layer > independence for lots of reasons. An ethernet traffic unit has a FCS. > This should simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should use its > own (OAM) 'integrity mechanisms' irrespective of the client. Problems > arise when people start doing things like client layer compression and > thus forming inter-layer dependencies. > > Further, as we agreed today and as I posted on an earlier mail to this > thread, the ethernet FCS is a CRC that can be linerarly updated for > adaptation function changes (eg VLAN ID change) on each > link-connection (as provided by some server layer trail technology) > whilst preserving its end-end intergrity check of the rest of the > ethernet traffic unit between its trail termination points. > > regards, Neil > > >>-----Original Message----- >>From: Norman Finn [mailto:nfinn@cisco.com] >>Sent: 18 November 2003 08:56 >>To: mark seery >>Cc: stds-802-1@ieee.org; pwe3@ietf.org >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >> >> >>Mark, >> >>You say below, >> >> > but a PW will be running over a physical media itself >>already, possibly >> > even SONET............. >> >>Exactly! Here, the trail gets a bit murky. If I'm in total >>control, and the PW >>is running over known Ethernet links, then I can get away >>without the CRC in the >>PW. I have no problem whatsoever with the current definition >>of PWs without CRC. >> >>But, if I don't have tight control over the physical media >>over which the PW runs, >>then I really need a CRC on the PW for the bridge to be able >>to trust the "wire" >>and thus provide the same level of data integrity that >>bridges offer over physical >>Ethernets. So, I claim that bridges need a CRC option on PWs. >> >>-- Norm >> >>mark seery wrote: >> >>>Norman Finn wrote: >>> >>> >>>> >>>>In other words, routers pass about $0.93 of the data >>> >>integrity buck to >> >>>>bridges, >>>>and bridges pass about $0.75 of that to the data links. >>> >>The buck has >> >>>>to stop >>>>somewhere, and the data link is where it stops. The PW >>> >>has to take >> >>>>the same >>>>hit as the physical media. >>>> >>>>-- Norm >>> >>> >>>but a PW will be running over a physical media itself >> >>already, possibly >> >>>even SONET............. >>> >>>mark >>> >>> >>> >>> >> >> >> >>_______________________________________________ >>pwe3 mailing list >>pwe3@ietf.org >>https://www1.ietf.org/mailman/listinfo/pwe3 >> > > ------_=_NextPart_001_01C3B047.0CF3D4BE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Norm.

I gather that Service Providers (which purchase and = deploy or plan to deploy Ethernet bridging equipment) find it = exceedingly difficult, if not next to impossible, to determine that = each piece of bridging equipment uniformly adheres to the 802.1 = model.

Consequently, I would not categorize having a = mechanism that supports a path like (i.e., end-to-end) integrity = validation (via preservation of the client Ethernet FCS) as = *pointless*. Rather I believe it should be a considered = requirement.

Marc.


-----Original Message-----
From: Norman Finn [mailto:nfinn@cisco.com]
Sent: Friday, November 21, 2003 7:03 AM
To: neil.2.harrison@bt.com
Cc: mark@interflect.com; stds-802-1@ieee.org; = pwe3@ietf.org
Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS = Retention



Neil,

I think Pat Thaler's reply helps to straighten out = this confusion, but let me try, also.

There is a *lot* of confusion about the words = "end-to-end", and about "transport layers". There = are lots of ends in this picture, and there are layers and there are = layers.

An 802.1Q VLAN bridge, and by extension, a P802.1ad = provider bridge, does NOT supply a "transport layer" in the = same sense as IP-over-Ethernet or Ethernet-over-IP.  This is = because, at the data forwarding layers, VLAN tags are best though of as = extensions to the address space, not as additional protocol = layers.  If you want to call it a "transport layer", = feel free!  But don't assume that VLANs are equivalent to other = "transport layers".  Data integrity, specifically, is = different in bridges.

Routers provide "best effort" not only in = frame delivery, but in data integrity.  There is no upper limit = specified for the probability of delivery of a packet with undetected = errors.  IP's response, if you demand a particular level of data = integrity, is that your application must supply its own = checksum.

Bridges, however, are not routers!

Bridges *do* guarantee a level of service.  They = manage to do this by guaranteeing the quality of each bridge, and by = *demanding* the quality of each link.  Non-VLAN bridges, VLAN = bridges, and Provider Bridges all make that guarantee to their users = using this method.  The Customers of a Provider Bridge service are = not an "802.1Q application" over an "802.1ad transport = layer".  They are, in the 802.1 model, just endstations = attached to a bridge.  The Customers' data is just as well = protected as an enterprise bridges' endstations, as long as the model = is maintained.  Adding an additional CRC to end-to-end service, = where the ends are Customers attached to 802.1ad Provider Bridges, is = therefore pointless.  Changing that model is as silly as turning = the model for routing upside down.

When a Pseudowire is used to connect two bridges, the = "end-to-end" is now just those two bridges.  Those = bridges are using that PW as an Ethernet to carry their traffic. The = bridges demand that every wire be as reliable as an Ethernet.  = That's the PW CRC issue.

-- Norm

neil.2.harrison@bt.com wrote:
> Norm....As per our discussion today = face-face.  I don't really see
> what the problem is here.  The client = layer network should not care
> about the server layer network (and vice = versa)....we need this layer
> independence for lots of reasons.  An = ethernet traffic unit has a FCS. 
> This should simply be transported transparently = in the payload area of
> whatever the server layer is....and the server = layer should use its
> own (OAM) 'integrity mechanisms' irrespective = of the client.  Problems
> arise when people start doing things like = client layer compression and
> thus forming inter-layer dependencies.
>
> Further, as we agreed today and as I posted on = an earlier mail to this
> thread, the ethernet FCS is a CRC that can be = linerarly updated for
> adaptation function changes (eg VLAN ID change) = on each
> link-connection (as provided by some server = layer trail technology)
> whilst preserving its end-end intergrity check = of the rest of the
> ethernet traffic unit between its trail = termination points.
>
> regards, Neil
>
>
>>-----Original Message-----
>>From: Norman Finn [mailto:nfinn@cisco.com]
>>Sent: 18 November 2003 08:56
>>To: mark seery
>>Cc: stds-802-1@ieee.org; = pwe3@ietf.org
>>Subject: Re: [PWE3] RE: [802.1] 802.1ad = Customer FCS Retention
>>
>>
>>Mark,
>>
>>You say below,
>>
>> > but a PW will be running over a = physical media itself
>>already, possibly
>> > even SONET.............
>>
>>Exactly!  Here, the trail gets a bit = murky.  If I'm in total
>>control, and the PW
>>is running over known Ethernet links, then I = can get away
>>without the CRC in the
>>PW.  I have no problem whatsoever with = the current definition
>>of PWs without CRC.
>>
>>But, if I don't have tight control over the = physical media
>>over which the PW runs,
>>then I really need a CRC on the PW for the = bridge to be able
>>to trust the "wire"
>>and thus provide the same level of data = integrity that
>>bridges offer over physical
>>Ethernets.  So, I claim that bridges = need a CRC option on PWs.
>>
>>-- Norm
>>
>>mark seery wrote:
>>
>>>Norman Finn wrote:
>>>
>>>
>>>><snip>
>>>>In other words, routers pass about = $0.93 of the data
>>>
>>integrity buck to
>>
>>>>bridges,
>>>>and bridges pass about $0.75 of that = to the data links.
>>>
>>The buck has
>>
>>>>to stop
>>>>somewhere, and the data link is = where it stops.  The PW
>>>
>>has to take
>>
>>>>the same
>>>>hit as the physical media.
>>>>
>>>>-- Norm
>>>
>>>
>>>but a PW will be running over a physical = media itself
>>
>>already, possibly
>>
>>>even SONET.............
>>>
>>>mark
>>>
>>>
>>>
>>>
>>
>>
>>
>>_______________________________________________
>>pwe3 mailing list
>>pwe3@ietf.org
>>https://www1.ietf.org/mailman/listinfo/pwe3=
>>
>
>


------_=_NextPart_001_01C3B047.0CF3D4BE-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: FCS retention in PWE3 Date: Fri, 21 Nov 2003 16:24:10 +0000 Organization: Cisco Systems, Inc. Lines: 118 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 Cc: stds-802-1@ieee.org, "Mick Seaman" , tony@jeffree.co.uk, "Norman Finn (nfinn)" X-From: pwe3-admin@ietf.org Fri Nov 21 17:25:07 2003 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 Plan of Record -------------- The plan of record in PWE3 with respect to FCS retention is that we would change the requirements draft to optionally permit the retention of FCS (currently is says must remove FCS), leave the base drafts as they are (they say remove FCS), and test the consensus of the WG for a new draft that calls up the optional retention of FCS for some encapsulations. Consensus --------- Danny and I have reviewed the discussion on the list and agree that there is consensus for the new draft, and that we should proceed with the plan of record. We hence ask Andy to resubmit (draft-malis-pwe3-fcs-retention-00.txt) as a WG draft. Applicability statement ---------------------- Looking at the discussion so far, I think that we need to take great care in our drafting of the applicability statement in the FCS retention draft. To quote section 7 of our requirements draft: "An emulated service SHOULD be as similar to the native service as possible, but NOT REQUIRED to be identical. The applicability statement of a PWE3 service MUST report limitations of the emulated service." This means that our WG goal is to provide the necessary and sufficient degree of emulation, not perfection. In the specific case of Ethernet FCS retention, I would take this to mean that we must provide the necessary degree of faithfulness required to support the assumptions made in IEEE 802.1. I have seen three cases made for FCS retention in the mails to the list. 1) IEEE 802.1 assumptions 2) OAM 3) Data integrity These need to be addressed in FCS retention draft applicability statement. IEEE 802.1 assumptions ---------------------- This is best summarized by the notes from Norman Finn: "PW is just another medium to a bridge. However, *all* media known to bridges, at least as far as IEEE 802.1 are concerned, are 802 media, and all 802 media have 32-bit CRCs. If you connect a medium that doesn't have at least a 32-bit CRC to a bridge, then the resultant bridged LAN will suffer a significant degradation in its ability to transport frames without error, because bridges depend on reliable media. And then the routers on top of the bridges don't work so well." and "If I'm in total control, and the PW is running over known Ethernet links, then I can get away without the CRC in the PW. I have no problem whatsoever with the current definition of PWs without CRC. "But, if I don't have tight control over the physical media over which the PW runs, then I really need a CRC on the PW for the bridge to be able to trust the "wire" and thus provide the same level of data integrity that bridges offer over physical Ethernets. So, I claim that bridges need a CRC option on PWs." That is to say PWE3 provides a service to 802.1 and needs by one method or another to provide the necessary and sufficient degree of wire emulation such that their design assumptions hold. OAM --- The original reason that FCS retention raised was because of an OAM issue. A malfunctioning bridge caused a network error, and it was thought that FCS retention would be useful in generating an alarm and diagnosing the fault. PWE3 is also developing an OAM method based on VCCV. We need to understand those circumstances where FCS retention is the best OAM technique, and those where VCCV is the better approach. Data integrity -------------- Some folks want FCS retention as a means of assuring the data integrity of the PW service. The degree of enhancement in data integrity when using FCS retention, compared to the base drafts is something that we need to treat carefully, because CRC32 offers a relatively weak degree of data assurance (4 or 5 bit corruption). The IETF standard method of ensuring data integrity is IPSec, and IPSec is called up in the security section of the PWE3 architecture for just this purpose. 802.1 are planning their own method of enhanced data assurance which we would pass this transparently over the PW. Within the PWE3 context the IETF method of providing a similar degree of data assurance would be to run IPSec between the PEs. We therefore need to describe the improvement in data integrity achieved through FCS retention and compare this to the improvements achieved through the use of IPSec. Regards Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 17:15:53 -0000 Lines: 227 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 Nov 21 18:17:04 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOwJ8FhItyGZLKlQyqWDfHZ+nfTMwAIWc+A To: X-OriginalArrivalTime: 21 Nov 2003 17:15:53.0747 (UTC) FILETIME=[1E876630:01C3B053] 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 Norm....We are on the same page I am sure, just using different = words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > >=20 > Neil, >=20 > I think Pat Thaler's reply helps to straighten out this=20 > confusion, but let me > try, also. >=20 > There is a *lot* of confusion about the words "end-to-end",=20 > and about "transport layers". NH=3D> Agreed. G.805 and G.809 func arch really helps sort this = out...as I hope was clear this week from Maarten's excellent analysis of = the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers=20 > and there are layers. NH=3D> Agreed.....just wish some more people grokked this stuff as it = should help mitigate arch violates. >=20 > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider=20 > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or=20 > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best=20 > though of as extensions to > the address space, not as additional protocol layers. NH=3D> Understood and agree. > If you=20 > want to call it a > "transport layer", feel free! NH=3D> No, that would be completely wrong....VLANs do *not* form a layer = network in any way, shape or form. > But don't assume that VLANs=20 > are equivalent to other > "transport layers". Data integrity, specifically, is=20 > different in bridges. >=20 > Routers provide "best effort" not only in frame delivery, but=20 > in data integrity. There > is no upper limit specified for the probability of delivery=20 > of a packet with undetected > errors. IP's response, if you demand a particular level of=20 > data integrity, is that > your application must supply its own checksum. >=20 > Bridges, however, are not routers! >=20 > Bridges *do* guarantee a level of service. They manage to do=20 > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of=20 > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to=20 > their users using this > method. The Customers of a Provider Bridge service are not=20 > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1=20 > model, just endstations > attached to a bridge. The Customers' data is just as well=20 > protected as an enterprise > bridges' endstations, as long as the model is maintained. =20 > Adding an additional CRC > to end-to-end service, where the ends are Customers attached=20 > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as=20 > silly as turning the model > for routing upside down. NH=3D> I agree with all this....so not quite sure what you think I am = not understanding here. >=20 > When a Pseudowire is used to connect two bridges, NH=3D> Similar to VLANs, a PW is *not* a layer network either. MPLS = does create layer networks however....but I suspect that is not well = understood by many. One of my colleagues, who like Maarten is a real = expert in the func modelling detail, is formally describing MPLS right = now...but of course MPLS is a not a singular layer network, it has many = flavours and this work will clearly bring out the different arch = behaviours. > the=20 > "end-to-end" is now just those > two bridges. NH=3D> Agreed. If one drew out the proper func arch model one can see = this immediately. > Those bridges are using that PW as an Ethernet=20 > to carry their traffic. > The bridges demand that every wire be as reliable as an=20 > Ethernet. That's the PW CRC > issue. NH=3D> Grokked totally. A PW is a form of adaptation function that lies = between a client (here we are discussing ethernet) and MPLS (or IP if = one is happy with a cnls server behaviour)...and then there are further = layer networks below this, eg the VC4 layer network of SDH, until we hit = the duct. The fact that a PW is not a layer network and not really = necessary is neither here nor there....other than its just something = else to manage. When the port on a bridge is not connected to an = 'ethernet shared media' (orginal case), but some technology (any) then = one simply has to adapt the ethernet PDU (*including its FCS*, as its = part of the client ethernet CI) to the payload of the server layer. One = should *not* be playing around with client layer network structures in a = simple client->server adaptation process at all. So I am totally = against all the 'Martini' PW compression stuff....the BW squeezing is = simply not worth it (compared to other technolgies that will squander = BW). So IMO the ethernet FCS is part of the ethernet's CI and should not = be removed by *any* server layer technology.=20 >=20 > -- Norm >=20 > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't=20 > really see what the problem is here. The client layer=20 > network should not care about the server layer network (and=20 > vice versa)....we need this layer independence for lots of=20 > reasons. An ethernet traffic unit has a FCS. This should=20 > simply be transported transparently in the payload area of=20 > whatever the server layer is....and the server layer should=20 > use its own (OAM) 'integrity mechanisms' irrespective of the=20 > client. Problems arise when people start doing things like=20 > client layer compression and thus forming inter-layer dependencies. > >=20 > > Further, as we agreed today and as I posted on an earlier=20 > mail to this thread, the ethernet FCS is a CRC that can be=20 > linerarly updated for adaptation function changes (eg VLAN ID=20 > change) on each link-connection (as provided by some server=20 > layer trail technology) whilst preserving its end-end=20 > intergrity check of the rest of the ethernet traffic unit=20 > between its trail termination points. > >=20 > > regards, Neil > >=20 > >=20 > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself=20 > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total=20 > >>control, and the PW > >>is running over known Ethernet links, then I can get away=20 > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition=20 > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media=20 > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able=20 > >>to trust the "wire" > >>and thus provide the same level of data integrity that=20 > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data=20 > >>> > >>integrity buck to=20 > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. =20 > >>> > >>The buck has=20 > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW=20 > >>> > >>has to take=20 > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself=20 > >> > >>already, possibly=20 > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >=20 > >=20 >=20 >=20 >=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: neil.2.harrison@bt.com Subject: RE: FCS retention in PWE3 Date: Fri, 21 Nov 2003 18:14:08 -0000 Lines: 159 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 Nov 21 19:15:08 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] FCS retention in PWE3 Thread-Index: AcOwTBWcIn9+HkqSRwaLRB2cFAh2jQADA48Q To: , X-OriginalArrivalTime: 21 Nov 2003 18:14:09.0013 (UTC) FILETIME=[41DEAA50:01C3B05B] 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 Stewart, With all due respect I really don't see what all the fuss is about here. = If the PW adaptation function did not mess about with the clients there = would be no problems at all. There should be exceedingly good reasons = why any server layer technology should modify a client layer network's = CI (characteristic information)....I am afraid BW squeezing is not a = good reason IMO. So the default behaviour in all client->server = adaptation functions (because that is what a PW is doing) should be *do = not change the client layer traffic unit at all*. This is not the only area where problems will arise. Like-mode = technology service I/W is another area where I can see that problems = will arise due to the very fact PWs even exist....as, in principle, they = are not serving any 'must-have' architectural technical purpose but = (IMO) simply a political one. However, if folks steadfastly refuse to = see that MPLS is not the same as IP and both create layer networks (one = belonging to the co-ps mode and one the cnls mode) then I am afraid we = are never going to get this sorted properly. regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Stewart Bryant > Sent: 21 November 2003 16:24 > To: pwe3@ietf.org > Cc: stds-802-1@ieee.org; Mick Seaman; tony@jeffree.co.uk; Norman Finn > (nfinn) > Subject: [PWE3] FCS retention in PWE3 >=20 >=20 >=20 > Plan of Record > -------------- >=20 > The plan of record in PWE3 with respect to FCS retention is that we > would change the requirements draft to optionally permit the retention > of FCS (currently is says must remove FCS), leave the base drafts > as they are (they say remove FCS), and test the consensus of the WG > for a new draft that calls up the optional retention of FCS for some > encapsulations. >=20 > Consensus > --------- >=20 > Danny and I have reviewed the discussion on the list and agree that > there is consensus for the new draft, and that we should proceed with > the plan of record. >=20 > We hence ask Andy to resubmit (draft-malis-pwe3-fcs-retention-00.txt) > as a WG draft. >=20 > Applicability statement > ---------------------- >=20 > Looking at the discussion so far, I think that we need to take great > care in our drafting of the applicability statement in the FCS > retention draft. >=20 > To quote section 7 of our requirements draft: >=20 > "An emulated service SHOULD be as similar to the native service as > possible, but NOT REQUIRED to be identical. The applicability > statement of a PWE3 service MUST report limitations of the emulated > service." >=20 > This means that our WG goal is to provide the necessary and > sufficient degree of emulation, not perfection. In the specific > case of Ethernet FCS retention, I would take this to mean that > we must provide the necessary degree of faithfulness required > to support the assumptions made in IEEE 802.1. >=20 > I have seen three cases made for FCS retention in the mails to > the list. >=20 > 1) IEEE 802.1 assumptions > 2) OAM > 3) Data integrity >=20 > These need to be addressed in FCS retention draft applicability > statement. >=20 >=20 > IEEE 802.1 assumptions > ---------------------- >=20 > This is best summarized by the notes from Norman Finn: >=20 > "PW is just another medium to a bridge. However, *all* media > known to bridges, at least as far as IEEE 802.1 are concerned, > are 802 media, and all 802 media have 32-bit CRCs. If you connect > a medium that doesn't have at least a 32-bit CRC to a bridge, > then the resultant bridged LAN will suffer a significant > degradation in its ability to transport frames without error, > because bridges depend on reliable media. And then the routers > on top of the bridges don't work so well." >=20 > and >=20 > "If I'm in total control, and the PW is running over known > Ethernet links, then I can get away without the CRC in the PW. > I have no problem whatsoever with the current definition of PWs > without CRC. >=20 > "But, if I don't have tight control over the physical media over > which the PW runs, then I really need a CRC on the PW for the > bridge to be able to trust the "wire" and thus provide the same > level of data integrity that bridges offer over physical > Ethernets. So, I claim that bridges need a CRC option on PWs." >=20 > That is to say PWE3 provides a service to 802.1 and needs by one > method or another to provide the necessary and sufficient > degree of wire emulation such that their design assumptions hold. >=20 >=20 > OAM > --- >=20 > The original reason that FCS retention raised was because of an > OAM issue. A malfunctioning bridge caused a network error, and > it was thought that FCS retention would be useful in generating > an alarm and diagnosing the fault. PWE3 is also developing an > OAM method based on VCCV. We need to understand those > circumstances where FCS retention is the best OAM technique, > and those where VCCV is the better approach. >=20 >=20 > Data integrity > -------------- >=20 > Some folks want FCS retention as a means of assuring the data > integrity of the PW service. The degree of enhancement in data > integrity when using FCS retention, compared to the base drafts > is something that we need to treat carefully, because CRC32 > offers a relatively weak degree of data assurance (4 or 5 bit > corruption). The IETF standard method of ensuring data > integrity is IPSec, and IPSec is called up in the security > section of the PWE3 architecture for just this purpose. 802.1 > are planning their own method of enhanced data assurance which > we would pass this transparently over the PW. Within the PWE3 > context the IETF method of providing a similar degree of > data assurance would be to run IPSec between the PEs. We > therefore need to describe the improvement in data integrity > achieved through FCS retention and compare this to the > improvements achieved through the use of IPSec. >=20 > Regards >=20 > Stewart >=20 >=20 >=20 >=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: mark seery Subject: X+Y+Z (was Re: FCS retention in PWE3) Date: Fri, 21 Nov 2003 10:41:05 -0800 Lines: 45 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E82@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, pwe3@ietf.org, stds-802-1@ieee.org, mick_seaman@ieee.org, tony@jeffree.co.uk, nfinn@cisco.com X-From: pwe3-admin@ietf.org Fri Nov 21 19:51:07 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2E82@i2km07-ukbr.domain1.systemhost.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 neil.2.harrison@bt.com wrote: >Hi Stewart, > >With all due respect I really don't see what all the fuss is about here. If the PW adaptation function did not mess about with the clients there would be no problems at all. There should be exceedingly good reasons why any server layer technology should modify a client layer network's CI (characteristic information)....I am afraid BW squeezing is not a good reason IMO. So the default behaviour in all client->server adaptation functions (because that is what a PW is doing) should be *do not change the client layer traffic unit at all*. > >This is not the only area where problems will arise. Like-mode technology service I/W is another area where I can see that problems will arise due to the very fact PWs even exist....as, in principle, they are not serving any 'must-have' architectural technical purpose but (IMO) simply a political one. However, if folks steadfastly refuse to see that MPLS is not the same as IP and both create layer networks (one belonging to the co-ps mode and one the cnls mode) then I am afraid we are never going to get this sorted properly. > >regards, Neil > > > Hi Neil, understand where you are coming from. I think the key issue is we need to have a common language in which to discuss the differences. Language is a problem here because it effects the preparedness of some listeners. So let me take a crack at this and see if it makes a difference. In much of our history, both datacom and telecom, we have thought in terms of layers. Whether we say physical/data link/network, or we say client/server we are thinking in terms of layers; and often we think in terms of X over Y. In the case of VLANs and IP-MPLS, we are dealing with X+Y. It could be argued that X+Y works when the full semantics of a layer are contained within the aggregate. This could be argued for both the VLAN and IP-MPLS case. When we then take MPLS and use it for PW, we have to make the decision about whether X+Y still works, or whether we need to move to X over Y, and make MPLS a full layer, because the X has different semantics now than it did for the IP-MPLS case. Another potential way of looking at it is that when we use PW-MPLS for Ethernet, we have created X+Y+Z. The key observation is that the role of MPLS may be different in IP-MPLS than it is in PW-MPLS, which is of course why the PID probably ended up in PW rather than MPLS. In saying this I am not trying to suggest that either X+Y or X+Y+Z meets yours, or anyone else's requirements. I am just trying to suggest a culture-neutral language that might be helpful in thinking through the issues you have raised. best, mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Rahul Aggarwal Subject: Re: IETF 58 Minutes Date: Fri, 21 Nov 2003 11:15:09 -0800 (PST) Lines: 68 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 Nov 21 20:18:03 2003 Return-path: X-Authentication-Warning: sapphire.juniper.net: rahul owned process doing -bs To: Danny McPherson 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 Danny, A few comments inline. Please look for ### Rahul Aggarwal - Use of PE-PE IP/GRE/IPSec for MPLS PWs http://www.ietf.org/internet-drafts/draft-raggarwa-pwe3-pw-over-ip-00.txt This document describes procedures for carrying MPLS PWs over IP, GRE or IPsec tunnels. Still uses MPLS control plane. Motivation is that there may be non-MPLS routers between ingress and egress PEs. MPLS packet gets sent over an IP or GRE tunnel. Can also use IPSEC to secure the tunnel Rahul - asked to make a WG document Eric Rosen - asked why this document exists since there is a similar document in MPLS WG Rahul - Agreed that other documents exists. This document does not define any protocols - just procedures. ### I also said that the MPLS WG document specifies how to encpsulate MPLS in IP/GRE. It does not specify how to carry PWs over IP/GRE. And that there is an existing document for doing the same for 2547 over IP/GRE. Mark Townsley - seconded Eric's opinion. Said that this was a way to send MPLS over IP without using L2TPv3. Rahul - said that there was a need coming from SPs ### I also said that this addresses the case when the PW control plane is MPLS and backbone is IP only. thanks, rahul Luca Martini - Said that it is contained in control document Rahul - will follow up, but not sure that it is in control document Luca - send me a paragraph Andy Malis - add voice to the chorus. All specified elsewhere Kireeti Kompella - Document in L3VPN in GRE defined elsewhere. This is the moral equivalent for PWE3. If already in place, perhaps we should just expand and clarify. Yaakov Stein - For MPLS label handling is obvious. For IP, not clear. Inner label may be OK. Document raises a good point about how to handle labels over IP. Rahul - concurred. Danny - take it to the mailing list. On Wed, 19 Nov 2003, Danny McPherson wrote: > > Folks, > Please provide corrections/additions to the minutes to > Stewart and I by 12/5. Again, the minutes are located > here, along with the rest of the proceedings: > > http://pwe3.tcb.net/meetings/ietf58 > > Thanks! > > -danny > > > _______________________________________________ > 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: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 08:31:11 -0800 Lines: 43 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E61@i2km07-ukbr.domain1.systemhost.net> <3FBDFEFB.6040101@cisco.com> Reply-To: mark@interflect.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 21 23:54:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Norman Finn In-Reply-To: <3FBDFEFB.6040101@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 Norman Finn wrote: > Neil, > > I think Pat Thaler's reply helps to straighten out this confusion, but > let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", and about > "transport layers". > There are lots of ends in this picture, and there are layers and there > are layers. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider bridge, > does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best though of > as extensions to > the address space, not as additional protocol layers. If you want to > call it a > "transport layer", feel free! But don't assume that VLANs are > equivalent to other > "transport layers". Hi Norman, this is a key point and a key area of disconnect (which I think we have in IP-MPLS as well, though perhaps slightly less so in PW-MPLS). Service Provider's should consider this point carefully and decide whether it meets their needs or not. > Bridges *do* guarantee a level of service. They manage to do this by > guaranteeing the > quality of each bridge, and by *demanding* the quality of each link. Norman, just out of curiousity, how does 802 guarantee the quality of bridges, and even if you get the PW requirements you want in terms of PW link guarantees, do routers have to be changed, in your opinion, to provide the equivalent quality of bridges. Just trying to understand all the moving pieces you need to get what you would consider an Ethernet grade service. Thanks, mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: John Messenger Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Fri, 21 Nov 2003 20:31:44 +0100 Lines: 12 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Fri Nov 21 23:54:04 2003 Return-path: To: "'neil.2.harrison@bt.com'" , nfinn@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 Neil Harrison said: > IMO the ethernet FCS is part of the ethernet's CI and should not be > removed by *any* server layer technology. Absolutely. Amen to that. -- John -- John Messenger (JMessenger@advaoptical.com) R&D Manager, Software ADVA Optical Networking Ltd. +44-1904-699309 www.advaoptical.com From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Sat, 22 Nov 2003 17:29:29 -0000 Lines: 60 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 Nov 22 18:31:12 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOwgmbeUXF0JGsGTi6nWhbBVusxzwAA4qYw To: X-OriginalArrivalTime: 22 Nov 2003 17:29:29.0639 (UTC) FILETIME=[2F406370:01C3B11E] 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 Mark,=20 mark observed 21 November 2003 16:31 > But don't assume that VLANs are=20 > > equivalent to other > > "transport layers".=20 >=20 > Hi Norman, this is a key point and a key area of disconnect (which I=20 > think we have in IP-MPLS as well, though perhaps slightly less so in=20 > PW-MPLS). Service Provider's should consider this point carefully and=20 > decide whether it meets their needs or not. NH=3D> Have already responded to Norm on this but in summary: VLANs are = *not* layer networks, neither are PWs. IP is a layer network and so is = MPLS (though IMO it's deficient in some respects and has some aspects = that violate functional arch requirements). Please see G.805 (for the = co modes) or G.809 (for the cnls mode) for further details (on = functional arch), or Chapter 3 of my colleague Andy Reid's book on BB = Networking (ISBN 0-890006-578-0) for a more comprehensive = history/explanation. =20 >=20 > > Bridges *do* guarantee a level of service. They manage to=20 > do this by=20 > > guaranteeing the > > quality of each bridge, and by *demanding* the quality of=20 > each link.=20 >=20 > Norman, just out of curiousity, how does 802 guarantee the quality of=20 > bridges, and even if you get the PW requirements you want in=20 > terms of PW=20 > link guarantees, do routers have to be changed, in your opinion, to=20 > provide the equivalent quality of bridges. Just trying to=20 > understand all=20 > the moving pieces you need to get what you would consider an Ethernet=20 > grade service. NH=3D> Mark.....It seems to me if more people grokked func arch and = layered networks better the answer to this question would be = self-evident, and it would hopefully also help in reducing the number of = arch mistakes.....this is very important to us as an operator, since = such mistakes create operational problems which ultimately impact our = opex. Bridges relay ethernet traffic units. The characteristic = information of the ethernet layer network is the ethernet PDU as = specified between the SA/DA and the FCS fields. So if there is some = (layer network) technology below this (eg FR, ATM, MPLS, etc), the = *whole* ethernet CI PDU (ie inc the FCS) must be encapsulated and = transported in the *payload* area of the relevent server layer = technology. As noted above, a PW is *not* a layer network per se though = MPLS is. A PW is an adaptation function to the server layer of either = IP or (the LSP in) MPLS (in a similar way that GFP is used when = adapating ethernet PDUs to an SDH VC4 server layer network). Now = whether a PW adaptation function is required or not is a different = question. It is my view that it is not, at least as how it has been = specified in certain respects, and especially noting that XoverIP is = *not* the same as XoverMPLS and thus the adaptation should not be = *forced* to be the same....that is simply being dogmatic without = properly understanding the functional arch requirements first. In any = case, removing the ethernet client's FCS (with any server layer network) = simply to save some BW and/or processing should not be done. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Keith Knightson Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Sat, 22 Nov 2003 12:43:53 -0500 Lines: 59 Sender: pwe3-admin@ietf.org References: <33BB463469A3D411B08F00508BDD1626E18E58@ntsyork.yrk.advaoptical.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Sat Nov 22 18:40:06 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <33BB463469A3D411B08F00508BDD1626E18E58@ntsyork.yrk.advaoptical.com> To: John Messenger , "'neil.2.harrison@bt.com'" , nfinn@cisco.com X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep03-mail.bloor.is.net.cable.rogers.com from [24.103.72.56] using ID at Sat, 22 Nov 2003 12:39:01 -0500 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, Well, this is what 802.1D has to say on the subject: "...for frames relayed between LANS of the same MAC type, the bridge shall not introduce an undetected frame error rate greater than that which would be achieved by *preserving* the FCS. I take this to mean that there is no requirement to preserve the (originally received) FCS, even on a pure native LAN system with bridges. Quite the contrary, Bridges are expected to not introduce errors. If you assume a PW to be a sort of bridge, this is certainly the case for a VPLS with multiple PWs, then a PW is no worse with or without a preserved FCS, if and only if, the undetected frame error rate is no greater than that which would be achieved by *preserving* the FCS. Why would one expect a PW to be better than a bridge? (Since a remote bridge would have been would been the alternative anyway!) I do not think that client/server has anything to do with this argument. In any case it is clear the client is the frame without its FCS. If anything, I would submit that the client is the LLC layer, ie the MAC Service User, and not the MAC Sublayer, i.e. the frames, yes, but not the mechanisms associated with the actual transmission of the frames. Otherwise, one could carry the argument to absurdum. For example, why not include the flags or manchester encodings or whatever else defines the frame? In a bridge the relaying is taking place at the frame level, not the MAC level. For example one can different MAC sublayers on each side of a bridge, forcing a recalculation of the FCS. MHO. Regards Keith 8:31 PM +0100 21/11/03, John Messenger wrote: >Neil Harrison said: >> IMO the ethernet FCS is part of the ethernet's CI and should not be >> removed by *any* server layer technology. > >Absolutely. Amen to that. > -- John >-- >John Messenger (JMessenger@advaoptical.com) >R&D Manager, Software >ADVA Optical Networking Ltd. >+44-1904-699309 >www.advaoptical.com > >_______________________________________________ >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: mark seery Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Sat, 22 Nov 2003 14:41:52 -0500 (EST) Lines: 18 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E8B@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: , X-From: pwe3-admin@ietf.org Sat Nov 22 20:42:03 2003 Return-path: To: In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2E8B@i2km07-ukbr.domain1.systemhost.net> from neil.2.harrison@bt.com on Sat, 22 Nov 2003 17:29:29 -0000 Content-Disposition: inline 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 Neil, below. thanks ---- neil.2.harrison@bt.com wrote: >> NH=> Mark.....It seems to me if more people grokked func arch and layered networks better the answer to this question would be self-evident, and it would hopefully also help in reducing the number of arch mistakes.....this is very important to us as an operator, since such mistakes create operational problems which ultimately impact our opex. << I think having a model would obviously provide **a** common reference that would like simpler for everyone. However,as in software development, so too in protocol design there are varying degrees of like/dislike for architectural approaches. There is a time-to-market mindset which the essential tenant of which is just decide on something and let's ship, plus there are certainly truly different approaches which cause conflict. One of the trends over the last couple ofyears has been towards getting rid of layers which I think has probably encouraged the development of X+Y approaches(see below). X+Y approaches create controversy where ever they appear (certainly the case in IEEE and IETF), which is not a judgement, just an observation of the very least that can be expected when you do something that is outside the boundaries of what people have traditionally seen. >> .... noting that XoverIP is *not* the same as XoverMPLS and thus the adaptation should not be *forced* to be the same....that is simply being dogmatic without properly understanding the functional arch requirements first. In any case, removing the ethernet client's FCS (with any server layer network) simply to save some BW and/or processing should not be done.<< if it is valid that MPLS is functionally deficient (as you stated but I snipped out) then XoverMPLS is never valid, which is why we have X+Y to get all the semantics required to make a layer. there are two ways of looking at this: 1) the IETF never meant MPLS to be an independent layer and therefore it is not deficient, it is just a shim with some function (from a data plane perspective) or 2) the IETF meant MPLS to be an independent layer and they did an incomplete job first go round. of the two alternatives, I suspect (like 802 did with VLANs) the first is more likely. so I see three models in play. the Y-X model (routing), the XoverY model (G.805) and X+Y (IP-MPLS and 802.1q). I would suggest that bridging is in a sense similar to the Y-X routing model in a number of ways, not the least of which is that the data link layer is source/sinked at each link -it is different in that the only upper layer protocols that are processed are control protocols (snooping aside). the beauty of Y-X models is that only an upper layer protocol indicator is needed. in XoverY models we have typically used encapsulations I agree. examples have included adaptation layers and RFC1483/1490 and their revisions. as I have said in private to some if we had used 1483/1490 as guidlines, then we may not have stumbled in to either the PID or FCS debates. however, that supposes that XoverY is an intent of the PW group. before we even get to the point of discussing encapsulation though, we first have to make sure we have a Y. because MPLS is not already a Y, we had to augment it with PW, by X+Y. Then we extend PW for encapsulation function and we still have X+Y, it is just that X is bigger now. Now comes the problem of what to do with the service layers. is it Z over (X+Y) or is it Z+(X+Y). this is what is not clear to me, which I have to go and do some study of. what is clear to me though is that X+Y thinking is more pervasive in this process than what might be apparent. there is a line of thought that says you must be able to functional understand what is going on, and then there is a line of thinking that says that functional thinking is broken and just slows everything down. i suspect this is the real disconnect. at the end of the day, the group will most likely focus on a set of requirements, create a solution, and ship. clearly the PW architecture document tried to create a functional model. translating that model is where the difficulty probably lays. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Sun, 23 Nov 2003 09:19:53 -0000 Lines: 114 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 Sun Nov 23 10:21:10 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOxH4yk2fM+9sYFRku8+75vYR8cXgAFq4VA To: , , X-OriginalArrivalTime: 23 Nov 2003 09:19:54.0463 (UTC) FILETIME=[F4B1FEF0:01C3B1A2] 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 Keith, Maarten....you may want to note this mail given you are defining the = functional models for ethernet. I'd be grateful if you would please = check the accuracy of my remarks below. Ditto Alan for MPLS. Thanks, = Neil Keith Knightson wrote 22 November 2003 17:44 > Well, this is what 802.1D has to say on the subject: >=20 > "...for frames relayed between LANS of the same MAC type, the bridge=20 > shall not introduce an undetected frame error rate greater than that=20 > which would be achieved by *preserving* the FCS. >=20 > I take this to mean that there is no requirement to preserve the=20 > (originally received) FCS, even on a pure native LAN system with=20 > bridges. Quite the contrary, Bridges are expected to not introduce=20 > errors. >=20 > If you assume a PW to be a sort of bridge, NH=3D> A PW is for sure not a bridge! A PW is an adaptation funtion = that lies between a client layer network and a server layer network of = MPLS or IP. A PW is *not* a layer network itself since PWs are not = 'networked'. CF GPF which has a similar role in adapting an ethernet = client layer network to an SDH VC4 layer network. Now whether a PW = adaptation function is required or is properly constructed is a = different question, and some things are not right here IMO....but this = is not relevant to this topic. A bridge is a node in the ethernet layer = network.....and from the perspective of recursive partitioning of the = ethernet layer network, it is the smallest flow domain subnetwork. I = believe that if you were more au fait with G.805 and G.809 func arch = concepts then this would help you see these things more clearly. > this is certainly the case=20 > for a VPLS with multiple PWs, then a PW is no worse with or without a=20 > preserved FCS, if and only if, the undetected frame error rate is no=20 > greater than that which would be achieved by *preserving* the FCS. >=20 > Why would one expect a PW to be better than a bridge? (Since a=20 > remote bridge would have been would been the alternative anyway!) NH=3D> This is not a valid comparison, ie apples with oranges. >=20 > I do not think that client/server has anything to do with this=20 > argument. NH=3D> On the contrary it has everything to do with the issue at = question. But I can see that you are having problems with this. > In any case it is clear the client is the frame without its=20 > FCS. NH=3D> This is not correct. The FCS is an intrinsic component of the = ethernet CI (characteristic information).....you simply cannot go around = arbitrarily changing/removing it. =20 > If anything, I would submit that the client is the LLC layer, ie=20 > the MAC Service User, and not the MAC Sublayer, i.e. the frames,=20 > yes, but not the mechanisms associated with the actual transmission=20 > of the frames. NH=3D> I can see your confusion given the way the LLC and MAC sublayers = were orginally specified (for example, see Radia Perlman's book = 'Interconnections' section 2.7). >=20 > Otherwise, one could carry the argument to absurdum. For example,=20 > why not include the flags or manchester encodings or whatever else=20 > defines the frame? NH=3D> This is wrong...and if you understood G.805/809 you would = immediately know why. Specific line codings belong to the section media = level. They occur *below* a given link connection on the *lowest* layer = network. Line codings are *not* networked entities. For example, = consider a VC4 layer network. The SDH STM-N nodes can be connected = together (so these would be link connections in the VC4 layer network) = using radio, electrical or optical media sections. The line codes used = on each section are different, however the VC4 entity is consistent = across all of them. Note that a VC4 traffic unit carries a BIP check of = degree 8 (x^8 +1), which is its FCS if you like....and these do not get = changed/removed in some ad hoc fashion by the section layers. > In a bridge the relaying is taking place at the=20 > frame level, not the MAC level. For example one can different MAC=20 > sublayers on each side of a bridge, forcing a recalculation of the=20 > FCS. NH=3D> I assume you mean 802.3 and 802.5 interworking for example? If = you looked at what is happening here from a func arch perspective, you = would note that we have to terminate the MAC trails either side. Why? = Because the CI is different on each side, eg the bit ordering of DA/SA = fields is different. So it is a requirement to have different FCSs. >=20 > MHO. >=20 > Regards >=20 > Keith >=20 > 8:31 PM +0100 21/11/03, John Messenger wrote: > >Neil Harrison said: > >> IMO the ethernet FCS is part of the ethernet's CI and=20 > should not be > >> removed by *any* server layer technology. > > > >Absolutely. Amen to that. > > -- John > >-- > >John Messenger (JMessenger@advaoptical.com) > >R&D Manager, Software > >ADVA Optical Networking Ltd. > >+44-1904-699309 > >www.advaoptical.com > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 >=20 >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Sun, 23 Nov 2003 15:55:54 -0800 Lines: 86 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , , X-From: pwe3-admin@ietf.org Mon Nov 24 00:52:05 2003 Return-path: To: "'Keith Knightson'" , "'John Messenger'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 Not withstanding the claim that an Ethernet frame has some called characteristic information (CI) that one cannot change and that FCS is part of it, no such notion (CI) exist in the MAC Service or Internal Sublayer Service or bridge specifications (or I believe in ISO 7498 including its addenda and interpretations) and Keith is entirely correct in saying that the MAC Service (as delivered to an LLC Entity and specified in ISO 15802-1 ,formerly ISO 10039) does not have FCS as a parameter. Moreover the MAC Service is provided at an abstract interface in a system and there is no requirement to associate an FCS with the parameters of the service until they have been encoded and transmitted in a frame by media access method specific functions. The coverage of an FCS is not from service user to service user, it is across media. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Keith Knightson Sent: Saturday, November 22, 2003 9:44 AM To: John Messenger; 'neil.2.harrison@bt.com'; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Guys, Well, this is what 802.1D has to say on the subject: "...for frames relayed between LANS of the same MAC type, the bridge shall not introduce an undetected frame error rate greater than that which would be achieved by *preserving* the FCS. I take this to mean that there is no requirement to preserve the (originally received) FCS, even on a pure native LAN system with bridges. Quite the contrary, Bridges are expected to not introduce errors. If you assume a PW to be a sort of bridge, this is certainly the case for a VPLS with multiple PWs, then a PW is no worse with or without a preserved FCS, if and only if, the undetected frame error rate is no greater than that which would be achieved by *preserving* the FCS. Why would one expect a PW to be better than a bridge? (Since a remote bridge would have been would been the alternative anyway!) I do not think that client/server has anything to do with this argument. In any case it is clear the client is the frame without its FCS. If anything, I would submit that the client is the LLC layer, ie the MAC Service User, and not the MAC Sublayer, i.e. the frames, yes, but not the mechanisms associated with the actual transmission of the frames. Otherwise, one could carry the argument to absurdum. For example, why not include the flags or manchester encodings or whatever else defines the frame? In a bridge the relaying is taking place at the frame level, not the MAC level. For example one can different MAC sublayers on each side of a bridge, forcing a recalculation of the FCS. MHO. Regards Keith 8:31 PM +0100 21/11/03, John Messenger wrote: >Neil Harrison said: >> IMO the ethernet FCS is part of the ethernet's CI and should not be >> removed by *any* server layer technology. > >Absolutely. Amen to that. > -- John >-- >John Messenger (JMessenger@advaoptical.com) >R&D Manager, Software >ADVA Optical Networking Ltd. >+44-1904-699309 >www.advaoptical.com > >_______________________________________________ >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: FCS retention in PWE3 Date: Sun, 23 Nov 2003 03:52:50 -0500 Lines: 144 Sender: pwe3-admin@ietf.org References: <3FBE3C2A.2040404@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 Mon Nov 24 01:16:04 2003 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: stbryant@cisco.com In-Reply-To: <3FBE3C2A.2040404@cisco.com> References: <3FBE3C2A.2040404@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 Stewart et al, I've just submitted draft-ietf-pwe3-fcs-retention-00.txt, which has been updated to reflect the discussion on the list to date. In particular, I've added a new Applicability section to reflect the discussion on the list and in your message below, but I've made some other changes that were suggested as well, such as discussing FCS checking at pseudowire ingress (a MUST) and egress (a MAY). I tried to make the new section succinct while still capturing the issues that have been discussed. Once it comes out, please all send comments to the list. Thanks, Andy ---------- At 11/21/2003 04:24 PM +0000, Stewart Bryant wrote: >Plan of Record >-------------- > >The plan of record in PWE3 with respect to FCS retention is that we >would change the requirements draft to optionally permit the retention >of FCS (currently is says must remove FCS), leave the base drafts >as they are (they say remove FCS), and test the consensus of the WG >for a new draft that calls up the optional retention of FCS for some >encapsulations. > >Consensus >--------- > >Danny and I have reviewed the discussion on the list and agree that >there is consensus for the new draft, and that we should proceed with >the plan of record. > >We hence ask Andy to resubmit (draft-malis-pwe3-fcs-retention-00.txt) >as a WG draft. > >Applicability statement >---------------------- > >Looking at the discussion so far, I think that we need to take great >care in our drafting of the applicability statement in the FCS >retention draft. > >To quote section 7 of our requirements draft: > >"An emulated service SHOULD be as similar to the native service as >possible, but NOT REQUIRED to be identical. The applicability >statement of a PWE3 service MUST report limitations of the emulated >service." > >This means that our WG goal is to provide the necessary and >sufficient degree of emulation, not perfection. In the specific >case of Ethernet FCS retention, I would take this to mean that >we must provide the necessary degree of faithfulness required >to support the assumptions made in IEEE 802.1. > >I have seen three cases made for FCS retention in the mails to >the list. > >1) IEEE 802.1 assumptions >2) OAM >3) Data integrity > >These need to be addressed in FCS retention draft applicability >statement. > > >IEEE 802.1 assumptions >---------------------- > >This is best summarized by the notes from Norman Finn: > >"PW is just another medium to a bridge. However, *all* media >known to bridges, at least as far as IEEE 802.1 are concerned, >are 802 media, and all 802 media have 32-bit CRCs. If you connect >a medium that doesn't have at least a 32-bit CRC to a bridge, >then the resultant bridged LAN will suffer a significant >degradation in its ability to transport frames without error, >because bridges depend on reliable media. And then the routers >on top of the bridges don't work so well." > >and > >"If I'm in total control, and the PW is running over known >Ethernet links, then I can get away without the CRC in the PW. >I have no problem whatsoever with the current definition of PWs >without CRC. > >"But, if I don't have tight control over the physical media over >which the PW runs, then I really need a CRC on the PW for the >bridge to be able to trust the "wire" and thus provide the same >level of data integrity that bridges offer over physical >Ethernets. So, I claim that bridges need a CRC option on PWs." > >That is to say PWE3 provides a service to 802.1 and needs by one >method or another to provide the necessary and sufficient >degree of wire emulation such that their design assumptions hold. > > >OAM >--- > >The original reason that FCS retention raised was because of an >OAM issue. A malfunctioning bridge caused a network error, and >it was thought that FCS retention would be useful in generating >an alarm and diagnosing the fault. PWE3 is also developing an >OAM method based on VCCV. We need to understand those >circumstances where FCS retention is the best OAM technique, >and those where VCCV is the better approach. > > >Data integrity >-------------- > >Some folks want FCS retention as a means of assuring the data >integrity of the PW service. The degree of enhancement in data >integrity when using FCS retention, compared to the base drafts >is something that we need to treat carefully, because CRC32 >offers a relatively weak degree of data assurance (4 or 5 bit >corruption). The IETF standard method of ensuring data >integrity is IPSec, and IPSec is called up in the security >section of the PWE3 architecture for just this purpose. 802.1 >are planning their own method of enhanced data assurance which >we would pass this transparently over the PW. Within the PWE3 >context the IETF method of providing a similar degree of >data assurance would be to run IPSec between the PEs. We >therefore need to describe the improvement in data integrity >achieved through FCS retention and compare this to the >improvements achieved through the use of IPSec. > >Regards > >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: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 00:25:29 +0000 Organization: Cisco Systems, Inc. Lines: 14 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kgk@igs.net, jmessenger@advaoptical.com, nfinn@cisco.com, mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org, Maarten.Vissers@alcatel.de, alan.mcguire@bt.com X-From: pwe3-admin@ietf.org Mon Nov 24 01:27:03 2003 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: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.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 >>If you assume a PW to be a sort of bridge, > > NH=> A PW is for sure not a bridge! A PW is an adaptation funtion > that lies between a client layer network and a server layer network > of MPLS or IP. Neil Surely that is just one way to model the PW? Can't a PW also be modelled as a repeater with certain internal delay and error characteristics. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Yaakov Stein" Subject: RE: IETF 58 Minutes Date: Mon, 24 Nov 2003 09:45:20 +0200 Lines: 46 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 Nov 24 08:46:09 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Thread-Topic: [PWE3] IETF 58 Minutes Thread-Index: AcOwZDoz5S4LEe1KQqyn13RzyKh7mwB+Ri4Q 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 Just a few (mostly editorial) changes: 1) > Yaakov Stein - For MPLS label handling is obvious. For IP, not clear. = =20 Inner label may be OK. Document raises a good point about how to = handle labels over IP. A more informative version would be >> Yaakov Stein - For MPLS it is obvious that the PW label is an MLPS = inner label. =20 For IP, there have been various suggestions (L2TP, UDP port numbers, = MPLS-like label). =20 Document raises a good point about how to handle labels over IP. 2) > Subject is being discussed in ITU SG13 as Y.tdmompls. should be >> Subject is being discussed in ITU SG13 as Y.tdmpls. 3) > Yaakov - can add mode, but what is the exact service? Need to be = specify. Should be "need to be specific" or "need to specify" Actually, a more informative version would be >> Yaakov - can add mode, but need to specify if interoperability = between the two T1 modes is required. 4) > Danny - why did they object (add "?") 5) > Stewart - what is the status of the TDM requirements (add "?") 6) > Yaakov - why is this a separate draft (add "?") From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 09:02:03 -0000 Lines: 20 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 Mon Nov 24 10:03:07 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOyIXxHJTttl7nPQweG3XVURu+34gACKBHA To: X-OriginalArrivalTime: 24 Nov 2003 09:02:03.0858 (UTC) FILETIME=[A0FA6320:01C3B269] 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 > >>If you assume a PW to be a sort of bridge, > >=20 > > NH=3D> A PW is for sure not a bridge! A PW is an adaptation funtion = > > that lies between a client layer network and a server layer network=20 > > of MPLS or IP. =20 >=20 > Neil >=20 > Surely that is just one way to model the PW? Can't a PW also be > modelled as a repeater with certain internal delay and error > characteristics. >=20 > Stewart Stewart, If this is a valid analogy then every networking technology that relays = some traffic unit between points A and B can be regarded as modelling a = bridge.....and that does not seem a good analogy to me. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 09:37:20 +0000 Organization: Cisco Systems, Inc. Lines: 46 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E93@i2km07-ukbr.domain1.systemhost.net> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: kgk@igs.net, jmessenger@advaoptical.com, nfinn@cisco.com, mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org, Maarten.Vissers@alcatel.de, alan.mcguire@bt.com X-From: pwe3-admin@ietf.org Mon Nov 24 10:39:04 2003 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: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2E93@i2km07-ukbr.domain1.systemhost.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 neil.2.harrison@bt.com wrote: >>>>If you assume a PW to be a sort of bridge, >>> >>>NH=> A PW is for sure not a bridge! A PW is an adaptation funtion >>>that lies between a client layer network and a server layer network >>>of MPLS or IP. >> >>Neil >> >>Surely that is just one way to model the PW? Can't a PW also be >>modelled as a repeater with certain internal delay and error >>characteristics. >> >>Stewart > > > Stewart, > If this is a valid analogy then every networking technology that > relays some traffic unit between points A and B can be regarded > as modelling a bridge.....and that does not seem a good analogy to me. > regards, Neil > A bridge has certain filtering and path selection properties, so the PW is certainly not a bridge. A PW has the property that it does not transform the data (any transformation takes place in the NSP, and that is not part of the PW). The data carried over the PW has no meaning within the context of the PSN that carries it, and from the point of view of the CE's the PW does not exist other than in terms of delay and error. Therefore from the CE point of view, the PW is just a repeater. For the PW to be an adaptation function, one would have to assert that the contents of the PW had some meaning within the PSN. I don't beleive it has, because we never communicate any context information to any object in the PSN (either by signalling or self description) which it can use to interpret the contents of the PW. Stewart From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 11:46:26 -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 Cc: , , , , , , , X-From: pwe3-admin@ietf.org Mon Nov 24 12:49:02 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOybpNlb/1qTeCAR366DOtAoe/EFQAERsTw To: X-OriginalArrivalTime: 24 Nov 2003 11:46:27.0385 (UTC) FILETIME=[98192A90:01C3B280] 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 Stewart, > >=20 > > Stewart, > > If this is a valid analogy then every networking technology that=20 > > relays some traffic unit between points A and B can be regarded=20 > > as modelling a bridge.....and that does not seem a good=20 > analogy to me. > > regards, Neil > >=20 >=20 > A bridge has certain filtering and path selection properties, so > the PW is certainly not a bridge. NH=3D> Agreed >=20 > A PW has the property that it does not transform the data (any > transformation takes place in the NSP, and that is not part of the > PW). NH=3D> OK, but there is an adaptation between the client and the = server....the flags, length and Seq No. fields are that adaptation = function. >=20 > The data carried over the PW has no meaning within the context of > the PSN that carries it, NH=3D> I agree that a client layer should be transparent to a server = layer.....but does the ECMP hack not violate this then? > and from the point of view of the CE's > the PW does not exist other than in terms of delay and error. NH=3D> But surely any client->server encapsulation relationship has this = property. >=20 > Therefore from the CE point of view, the PW is just a repeater. NH=3D> As noted above, I believe we can extend this to any = client->server encaps. >=20 > For the PW to be an adaptation function, one would have to assert > that the contents of the PW had some meaning within the PSN. NH=3D> See remark on ECMP above.....my observation however is that there = are functions that lie between the client layer network and the server = layer network (be this IP or MPLS), and in my mind these are an = adapatation function. regards, Neil > I don't beleive it has, because we never communicate any context > information to any object in the PSN (either by signalling or > self description) which it can use to interpret the contents of > the PW. >=20 > Stewart >=20 >=20 >=20 From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Heiles Juergen Subject: AW: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 14:03:40 +0100 Lines: 163 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org, Maarten.Vissers@alcatel.de, alan.mcguire@bt.com X-From: pwe3-admin@ietf.org Mon Nov 24 14:24:26 2003 Return-path: To: "'neil.2.harrison@bt.com'" , kgk@igs.net, jmessenger@advaoptical.com, nfinn@cisco.com X-Mailer: Internet Mail Service (5.5.2656.59) 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 Neil I have to correct you here. In the ITU Ethernet Network Architecture (G.8010 which is currently out = for approval) the FCS is not part of the CI. It is a link property. = This is the difference in FCS for circuit and packet switched networks = I mentioned in my previous email. G.8010 refers however to the undetected errors of a bridge. This = doesn't mean that a bridge should be error free. An error introduced by = a bridge which is detected by the FCS is ok. For a bridge as a single = network element designed by a single manufacturer such a requirement on = undetected errors seems to be achievable. For a pseudo wire which is a = link connection through a network which consists of network elements = and connections between them such a requirement is very difficult to = achieve. Regards Juergen > -----Urspr=FCngliche Nachricht----- > Von: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com] > Gesendet: Sonntag, 23. November 2003 10:20 > An: kgk@igs.net; jmessenger@advaoptical.com; nfinn@cisco.com > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org; > Maarten.Vissers@alcatel.de; alan.mcguire@bt.com > Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 > Keith, >=20 > Maarten....you may want to note this mail given you are=20 > defining the functional models for ethernet. I'd be grateful=20 > if you would please check the accuracy of my remarks below. =20 > Ditto Alan for MPLS. Thanks, Neil >=20 > Keith Knightson wrote 22 November 2003 17:44 >=20 > > Well, this is what 802.1D has to say on the subject: > >=20 > > "...for frames relayed between LANS of the same MAC type,=20 > the bridge=20 > > shall not introduce an undetected frame error rate greater=20 > than that=20 > > which would be achieved by *preserving* the FCS. > >=20 > > I take this to mean that there is no requirement to preserve the=20 > > (originally received) FCS, even on a pure native LAN system with=20 > > bridges. Quite the contrary, Bridges are expected to not introduce=20 > > errors. > >=20 > > If you assume a PW to be a sort of bridge, > NH=3D> A PW is for sure not a bridge! A PW is an adaptation=20 > funtion that lies between a client layer network and a server=20 > layer network of MPLS or IP. A PW is *not* a layer network=20 > itself since PWs are not 'networked'. CF GPF which has a=20 > similar role in adapting an ethernet client layer network to=20 > an SDH VC4 layer network. Now whether a PW adaptation=20 > function is required or is properly constructed is a=20 > different question, and some things are not right here=20 > IMO....but this is not relevant to this topic. A bridge is a=20 > node in the ethernet layer network.....and from the=20 > perspective of recursive partitioning of the ethernet layer=20 > network, it is the smallest flow domain subnetwork. I=20 > believe that if you were more au fait with G.805 and G.809=20 > func arch concepts then this would help you see these things=20 > more clearly. >=20 > > this is certainly the case=20 > > for a VPLS with multiple PWs, then a PW is no worse with or=20 > without a=20 > > preserved FCS, if and only if, the undetected frame error=20 > rate is no=20 > > greater than that which would be achieved by *preserving* the FCS. > >=20 > > Why would one expect a PW to be better than a bridge? (Since a=20 > > remote bridge would have been would been the alternative anyway!) > NH=3D> This is not a valid comparison, ie apples with oranges. > >=20 > > I do not think that client/server has anything to do with this=20 > > argument. > NH=3D> On the contrary it has everything to do with the issue=20 > at question. But I can see that you are having problems with this. >=20 > > In any case it is clear the client is the frame without its=20 > > FCS. > NH=3D> This is not correct. The FCS is an intrinsic component=20 > of the ethernet CI (characteristic information).....you > simply cannot go around arbitrarily changing/removing it. =20 >=20 > > If anything, I would submit that the client is the LLC layer, ie=20 > > the MAC Service User, and not the MAC Sublayer, i.e. the frames,=20 > > yes, but not the mechanisms associated with the actual=20 > transmission=20 > > of the frames. > NH=3D> I can see your confusion given the way the LLC and MAC=20 > sublayers were orginally specified (for example, see Radia=20 > Perlman's book 'Interconnections' section 2.7). > >=20 > > Otherwise, one could carry the argument to absurdum. For example,=20 > > why not include the flags or manchester encodings or whatever else=20 > > defines the frame? > NH=3D> This is wrong...and if you understood G.805/809 you=20 > would immediately know why. Specific line codings belong to=20 > the section media level. They occur *below* a given link=20 > connection on the *lowest* layer network. Line codings are=20 > *not* networked entities. For example, consider a VC4 layer=20 > network. The SDH STM-N nodes can be connected together (so=20 > these would be link connections in the VC4 layer network)=20 > using radio, electrical or optical media sections. The line=20 > codes used on each section are different, however the VC4=20 > entity is consistent across all of them. Note that a VC4=20 > traffic unit carries a BIP check of degree 8 (x^8 +1), which=20 > is its FCS if you like....and these do not get=20 > changed/removed in some ad hoc fashion by the section layers. >=20 > > In a bridge the relaying is taking place at the=20 > > frame level, not the MAC level. For example one can different MAC=20 > > sublayers on each side of a bridge, forcing a recalculation of the=20 > > FCS. > NH=3D> I assume you mean 802.3 and 802.5 interworking for=20 > example? If you looked at what is happening here from a func=20 > arch perspective, you would note that we have to terminate=20 > the MAC trails either side. Why? Because the CI is=20 > different on each side, eg the bit ordering of DA/SA fields=20 > is different. So it is a requirement to have different FCSs. > >=20 > > MHO. > >=20 > > Regards > >=20 > > Keith > >=20 > > 8:31 PM +0100 21/11/03, John Messenger wrote: > > >Neil Harrison said: > > >> IMO the ethernet FCS is part of the ethernet's CI and=20 > > should not be > > >> removed by *any* server layer technology. > > > > > >Absolutely. Amen to that. > > > -- John > > >-- > > >John Messenger (JMessenger@advaoptical.com) > > >R&D Manager, Software > > >ADVA Optical Networking Ltd. > > >+44-1904-699309 > > >www.advaoptical.com > > > > > >_______________________________________________ > > >pwe3 mailing list > > >pwe3@ietf.org > > >https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 > >=20 >=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: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 14:08:00 -0000 Lines: 27 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 Mon Nov 24 15:09:06 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOyi3U5IGlqluu6Rbmi+Im1MXVzUgABeahQ To: , , , X-OriginalArrivalTime: 24 Nov 2003 14:08:01.0011 (UTC) FILETIME=[5EB1A430:01C3B294] 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 Thanks Juergen, please see below. >=20 > Neil I have to correct you here. >=20 > In the ITU Ethernet Network Architecture (G.8010 which is=20 > currently out for approval) the FCS is not part of the CI. It is a = link property. NH=3D> Agreed.....you are correct that strictly speaking the FCS does = not belong to the eth CI as defined in G.8010 though its still belongs = to the eth client.....and as you note its part of the link-adaptation = (so like the HEC in a ATM cell header changes with VPI/VCI change per = link the FCS can also change if the VLAN field changes (though this = would not be per link I guess)). > This is the difference in FCS for circuit=20 > and packet switched networks I mentioned in my previous email. NH=3D>I have just been looking through G.8010 and I don't like the = inconsistency in I see in the sections dealing with ethernet over X. In = SDH/VC4 and OTN/ODUk layer networks the FCS is carried transparently. = For ATM (or more accurately AAL5) its removal or carriage is optional. = And currently it is noted as removed for MPLS......but I guess this may = now have to change and become optional too. Its my opinion that client = layer traffic units should be carried transparently by some server layer = technology.....irrespective of what that server layer technology is. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Keith Knightson Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 09:37:08 -0500 Lines: 54 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.n et> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: , , , , X-From: pwe3-admin@ietf.org Mon Nov 24 15:34:03 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.n et> To: , , X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep01-mail.bloor.is.net.cable.rogers.com from [24.103.72.56] using ID at Mon, 24 Nov 2003 09:31:25 -0500 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 9:19 AM +0000 23/11/03, wrote: >Keith, > >NH=> I assume you mean 802.3 and 802.5 interworking for example? If >you looked at what is happening here from a func arch perspective, >you would note that we have to terminate the MAC trails either side. >Why? Because the CI is different on each side, eg the bit ordering >of DA/SA fields is different. So it is a requirement to have >different FCSs. >> Neil, Well, you illustrate my point exactly. Once you terminate the trail, you terminate the scope of the FCS. THe FCS is particular to the MAC sublayer trail. The FCS does not belong to the information being relayed, it belongs to the framing mechanism, not the frame itself. You then have to create another trail on the other side with a new FCS. As far as G.805 is concerned it is a question of interpretation. By that I mean it all depends which sub-strings of bits out of total string of bits under consideration, you think belong to which layer, sublayer, or trail. Onion skin models of IEEE/HDLC protocols were around long before G.805 was invented, as a matter of fact. BTW, I do not believe that the definition of network interworking (NI) supports your argument at all. There are many cases of NI where some changes take place between both sides of the IWF. The precise difference between SI and NI is not clear. They are simply two ends of a spectrum of mapping possibilities. The data link layer was never conceived to be end-to-end, in the first place. It is an architectural aberration to make it so. I find it difficult to believ ein this day and age, that the FCS is the key/essential tool for data ensuring end-to-end integrity of application data. The PW acts liike it is the internal part of a bridge, despite what you say. In the VPLS work the service is described as a logical bridge, which is exactly what it is. It is a distributed bridge using PWs to effect is distribution to multiple ports. It uses PWs in excactly the same way, just prefaced by selective forwarding functions. Bridges act as relays not interworking units, and did so long before G.805/9 or definition of NI was invented. I would still maintain that you cannot expect more from a PW than you would get from a remote bridges connected directly by another LAN or a real piece of wire. Regards Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Heiles Juergen Subject: AW: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 16:06:18 +0100 Lines: 52 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org, Maarten.Vissers@alcatel.de, alan.mcguire@bt.com X-From: pwe3-admin@ietf.org Mon Nov 24 16:07:04 2003 Return-path: To: "'Keith Knightson'" , neil.2.harrison@bt.com, jmessenger@advaoptical.com, nfinn@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 Keith, see my comments below. Regards Juergen > -----Ursprungliche Nachricht----- > Von: Keith Knightson [mailto:kgk@igs.net] > Gesendet: Montag, 24. November 2003 15:37 > An: neil.2.harrison@bt.com; jmessenger@advaoptical.com; > nfinn@cisco.com > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org; > Maarten.Vissers@alcatel.de; alan.mcguire@bt.com > Betreff: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > The PW acts liike it is the internal part of a bridge, > despite what you say. > The PW acts like and is a link between two bridges. > In the VPLS work the service is described as a logical bridge, which > is exactly what it is. It is a distributed bridge using PWs to effect > is distribution to multiple ports. It uses PWs in excactly the same > way, just prefaced by selective forwarding functions. Bridges act as > relays not interworking units, and did so long before G.805/9 or > definition of NI was invented. > VPLS is a (sub) network of bridges interconnected by PW links. > I would still maintain that you cannot expect more from a PW than > you would get from a remote bridges connected directly by another LAN > or a real piece of wire. > > Regards > > Keith > > > _______________________________________________ > 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: Keith Knightson Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 10:35:09 -0500 Lines: 44 Sender: pwe3-admin@ietf.org References: <002101c3b21d$58173ee0$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: , , X-From: pwe3-admin@ietf.org Mon Nov 24 16:32:02 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <002101c3b21d$58173ee0$210110ac@corp.telseon.com> To: , "'John Messenger'" , , X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.103.72.56] using ID at Mon, 24 Nov 2003 10:29:35 -0500 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 3:55 PM -0800 23/11/03, Mick Seaman wrote: >Not withstanding the claim that an Ethernet frame has some called >characteristic information (CI) that one cannot change and that FCS is part >of it, no such notion (CI) exist in the MAC Service or Internal Sublayer >Service or bridge specifications (or I believe in ISO 7498 including its >addenda and interpretations) and Keith is entirely correct in saying that >the MAC Service (as delivered to an LLC Entity and specified in ISO 15802-1 >,formerly ISO 10039) does not have FCS as a parameter. > >Moreover the MAC Service is provided at an abstract interface in a system >and there is no requirement to associate an FCS with the parameters of the >service until they have been encoded and transmitted in a frame by media >access method specific functions. The coverage of an FCS is not from service >user to service user, it is across media. > >Mick > Mick, Exaclty, so. The FCS is not part of the Service Data Unit (i.e the client layer, for those who insist) delivered to the MAC Sublayer (i.e. the server layer) for transmission. If the transmission is a PW one simply uses the framing of that instead of the MAC Sublayer, IP or whatever it is that is "acting" as the transmission layer for the next link. The PE is clearly not a repeater. Layers are terminated. Relay functions are included. IMHO, it is thus the SDU, (i.e. the frame and not the transmission framing information) that is to be encapsulation by the PW. Otherwise, there is no architectural criteria on which to base the distinction between any of the layers in the layered stack, and one could argue that a lot of other other stuff should also be encapsulated along with the frame. The notion of the separation between service user and provider layers is key in this discussion. Anyway this is all these concepts are extremely well documented in the IEEE docs, so I do not see why other different and dubious approaches should be taken. Regards Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 08:19:34 -0800 Lines: 33 Sender: pwe3-admin@ietf.org References: <002101c3b21d$58173ee0$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mick_seaman@ieee.org, "'John Messenger'" , neil.2.harrison@bt.com, nfinn@cisco.com, mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 24 17:32:15 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: Keith Knightson 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 Keith Knightson wrote: > The PE is clearly not a repeater. Layers are terminated. Relay > functions are included. > Keith, I think there is a disconnect being caused by the fact that a PW is envisioned in multiple applications. In a wire service, depending on how the carrier defines the service to the subscriber, there are potential implications. VPLS does as you say involve some type of relay function. On the more general issue, Neil is arguing for something based on the principle of layer encapsulation (similar to object encapsulation in software) and which is also reflected in the minimum intervention principle stated in the PW architecture; the theory being that a tunnel is more extensible if you do not change the payload. This is a general principle, and there may be occassions where it does not apply when dealing with the real world. What 802 defines as a SDU and what is an SDU is to a PW may legitimately be two different things depending on the service definition; which is not to say your points are not good. If the practicality is that vendors will use the same mac chips for both wire and VPLS services, and if those mac chips act in a way that does not support retaining the FCS, then the discussion becomes moot, except to highlight an unmet desire on the behalf of some operators to have an end to end indication of whether they corrupted the subsriber's data anywhere in the network. It could be argued that if all links have a 32-bit CRC and all equipment does not introduce errors above a similarly prescribed rate, then that is achieved. The only question that would remain is whether the operator knows where corruption is occuring, when it does. mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 12:43:11 -0500 Lines: 71 Sender: pwe3-admin@ietf.org References: <3FBE3C2A.2040404@cisco.com> 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 Mon Nov 24 18:45:08 2003 Return-path: To: stbryant@cisco.com In-reply-to: Your message of Fri, 21 Nov 2003 16:24:10 +0000. <3FBE3C2A.2040404@cisco.com> 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 One thing that is clear from this discussion is that we were right to keep the FCS option out of the base spec! It's not at all clear that carrying the FCS is either a necessary or a sufficient condition for the solution of any actual problem. Let's step back and look at some of the reasons advanced for carrying the customer FCS: 1. Port-to-port ethernet is a "transmission service". Unlike general network services, it is a requirement of "transmission services" that every bit which goes in one end must come out the other end. We haven't discussed this putative requirement very much. There's been some suggestion that failure to meet it will result in a customer relations problem (between the SP and its customers), but I haven't seen very much to back this up. Perhaps this is just a dogma from the past, which can be discarded. 2. A switch in the SP network may corrupt frames. If this happens, and if there is no FCS which the egress PE can check, then the corrupted frames will be sent to the customer network. If this is a regular occurrence, then the customer will complain to the SP. It would be better if the SP could detect the corruption, and not send the corrupted frames to the customer. (Presumably the customer wont complain about the missing frames?) There seem to be two problems with this argument: a. Since the ethernet FCS is not validated on egress from a switch, this can't be done. Frames with bit errors will be sent to the customer even if they carry the customer's original FCS. b. If this were really a requirement, it would apply equally well to services other than port-to-port ethernet, even though carrying the customer's original FCS is not a possibility for those services. Hence a solution other than carrying the customer's original FCS would be required. In fact, what would really be needed to solve this problem is a PW-specific checksum which is created by the ingress PE and validated by the egress PE. However, no one has actually asked for that, probably because the added overhead it would create is obvious and the payback is minimal. By the way, anyone who thinks that the FCS should be used to enable the SP (rather than the customer) to detect the corruption should argue that the egress PE MUST validate the FCS. I don't see much point in saying "MAY", as I think Andy has proposed. 3. IEEE specs require that any media connecting two bridges provide a bounded rate of undetected errors. However, I think the discussion has made it pretty clear that carrying the customer FCS through the PWs is not necessary to meet this requirement. As far as I can tell, it is not sufficient either, because it is not possible to do in various scenarios involving VLANs. 4. A proper understanding of the theoretical aspects of network layering and/or IEEE standards require that the customer FCS be carried transparently. There are two problems with this argument: a. Who cares? b. In my judgment, Mick Seaman and Keith Knightson have thoroughly refuted the claim that this is even a theoretical requirement. Taking all these together, I just don't see any reason to pursue the "customer FCS retention" capability, even as an option. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 11:40:16 -0600 Lines: 280 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E7F@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 24 18:47:12 2003 Return-path: In-reply-to: <0536FC9B908BEC4597EE721BE6A3538904EF2E7F@i2km07-ukbr.domain1.systemhost.net> To: neil.2.harrison@bt.com, nfinn@cisco.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: Eric Rosen Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 13:31:35 -0500 Lines: 34 Sender: pwe3-admin@ietf.org References: <000101c3b2b2$062e3440$338c23a6@acer4wc5zk5t43> 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 Mon Nov 24 19:34:03 2003 Return-path: To: Scott Kotrla In-reply-to: Your message of Mon, 24 Nov 2003 11:40:16 -0600. <000101c3b2b2$062e3440$338c23a6@acer4wc5zk5t43> 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 Scott> As some background, what started MCI's quest for FCS retention was a Scott> lab infrastructure Ethernet switch that was corrupting packets and Scott> calculating a new FCS on packets where no changes should have been Scott> occurring. This was one of the top Ethernet switch vendors as Scott> provided by Gartner in 2002. This took days to troubleshoot, and as Scott> service providers, scared the Hell out of us. My understanding is that the customers noticed the problem in the form of TCP checksum errors, and complained to MCI. I'm not sure how having the customers notice the problem in the form of ethernet checksum errors rather than TCP checksum errors would have made it any easier for you to diagnose the problem. Scott> The TRANS layer often refers to transport over SONET, but there is no Scott> reason why it shouldn't also support the model of transport over Scott> Ethernet, in which case the requirements are different from ETH Scott> requirements. Why is that? In PWE3, we are accustomed to hearing that SPs can't provide an IP service unless IP becomes more like ATM, but this is the first I've heard that SP's can't provide an ethernet service unless ethernet becomes more like SONET. Scott> The idea of VLAN stacking, VLAN swapping, marking as discard Scott> eligible, and messing with packets in general seems to open up the Scott> possibility of such things happening even more. All these things have been happening for many years. In routers, rewriting of the data link layer header has to happen. I am not aware of any empirical data suggesting that a node which rewrites the header is more likely to corrupt the data than a node which does not (or is not supposed to) rewrite the header. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 14:08:46 -0500 (EST) Lines: 13 Sender: pwe3-admin@ietf.org References: <200311241743.hAOHhBDM021271@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Mon Nov 24 20:10:06 2003 Return-path: To: In-Reply-To: <200311241743.hAOHhBDM021271@rtp-core-2.cisco.com> from Eric Rosen on Mon, 24 Nov 2003 12:43:11 -0500 Content-Disposition: inline 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 Eric, Consider the following: --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- where a,b,c, & d are Ethernet ports wouldn't ports "b" and "c" be able to detect FCS errors before they entered the customers network, and at least provide an indication that the problem is in the operators network and not the customers, therefore narrowing down the problem of diagnosing TCP checksum errors? in the case where the CE-PE link was MPLS I agree that would require the CE to do a FCS check before egress on to a and d. Mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 14:26:58 -0500 Lines: 14 Sender: pwe3-admin@ietf.org References: <200311241908.OAA28220@linus.bcentralhost.com> 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 Mon Nov 24 20:28:05 2003 Return-path: To: mark seery In-reply-to: Your message of Mon, 24 Nov 2003 14:08:46 -0500. <200311241908.OAA28220@linus.bcentralhost.com> 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 Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- Mark> wouldn't ports "b" and "c" be able to detect FCS errors before they Mark> entered the customers network, and at least provide an indication that Mark> the problem is in the operators network and not the customers, Mark> therefore narrowing down the problem of diagnosing TCP checksum Mark> errors? I don't think so. Presumably the frame is ethernet-checksummed from its source to the ingress PE, and then is ethernet-checksummed again from the egress PE to its destination. The only place where it is not ethernet-checksummed is in the SP network. So if the frame actually arrives at the destination host with a bad TCP checksum, chances seem high that the problem was in the operator's network. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 13:38:53 -0600 Lines: 89 Sender: pwe3-admin@ietf.org References: <200311241831.hAOIVZxg028913@rtp-core-1.cisco.com> 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 Mon Nov 24 20:49:05 2003 Return-path: In-reply-to: <200311241831.hAOIVZxg028913@rtp-core-1.cisco.com> To: erosen@cisco.com X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 First topic: TCP Checksum errors are spread out among all of the customer end devices. There is no convenient way to aggregate these and identify a root cause. It may very well look like a customer network problem and not a service provider problem. It's not clear that all endstations even report such statistics. For UDP traffic, the checksum may or may not be there. For a handful of packets, this may or may not be noticeable, but in the case of the bad Ethernet switch, the majority of the packets were being corrupted, so it is possible that corrupted frames would never be caught and the applications just wouldn't work with no clear reason for the failure. If service provider customer egress FCS checking were enabled, the service provider would be able to catch the errors, identify that thee is a problem, and begin fault isolation. Even if egress FCS checking were not enabled, the customer would see all of the FCS errors at the service provider demark in a single place, and would be able to open a trouble ticket with the service provider. Either way, the issue is identified, which is my number one concern as a service provider. Second topic: We are not talking Ethernet "service" necessarily, but more Ethernet transport. I would like to take SONET out of the network where possible. To do so, I need the Section/Path/Line functionality of SONET replicated over Ethernet. Service providers cannot take SONET out of the network anywhere unless the functionality of SONET is added to packet switched protocols. I don't want every device in the network to be Ethernet service aware. I see a clear distinction in packet transport and packet services. For my packet services to utilize packet transport from A to Z, I need certain guarantees in the packet transport, such as an end-to-end guarantee against unknown corruption. Thanks, Scott -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Eric Rosen Sent: Monday, November 24, 2003 12:32 PM To: Scott Kotrla Cc: pwe3@ietf.org Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Scott> As some background, what started MCI's quest for FCS retention was a Scott> lab infrastructure Ethernet switch that was corrupting packets and Scott> calculating a new FCS on packets where no changes should have been Scott> occurring. This was one of the top Ethernet switch vendors as Scott> provided by Gartner in 2002. This took days to troubleshoot, and as Scott> service providers, scared the Hell out of us. My understanding is that the customers noticed the problem in the form of TCP checksum errors, and complained to MCI. I'm not sure how having the customers notice the problem in the form of ethernet checksum errors rather than TCP checksum errors would have made it any easier for you to diagnose the problem. Scott> The TRANS layer often refers to transport over SONET, but there is no Scott> reason why it shouldn't also support the model of transport over Scott> Ethernet, in which case the requirements are different from ETH Scott> requirements. Why is that? In PWE3, we are accustomed to hearing that SPs can't provide an IP service unless IP becomes more like ATM, but this is the first I've heard that SP's can't provide an ethernet service unless ethernet becomes more like SONET. ______________________________________________ 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 Kotrla Subject: RE: FCS retention in PWE3 Date: Mon, 24 Nov 2003 13:47:31 -0600 Lines: 50 Sender: pwe3-admin@ietf.org References: <200311241926.hAOJQxxg012235@rtp-core-1.cisco.com> 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 Mon Nov 24 20:49:10 2003 Return-path: In-reply-to: <200311241926.hAOJQxxg012235@rtp-core-1.cisco.com> To: erosen@cisco.com, "'mark seery'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Why couldn't the corruption be occurring in the customer's network? How are the provider and customer supposed to figure out whose fault it is with certainty? Because all of the links are checksummed, the error had to have occurred inside a device. But there is NO way to isolate whether it was a provider device or a customer device. There are likely more customer devices in the path than carrier devices, so it would seem more likely to be a customer problem. Is it not clear that this is a huge nightmare for a service provider who deploys this in a large scale? I just don't get how people cannot see how this could be useful in some SP networks. The blanket statement that it would NEVER be useful and shouldn't be an OPTION is absurd. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Eric Rosen Sent: Monday, November 24, 2003 1:27 PM To: mark seery Cc: pwe3@ietf.org Subject: Re: [PWE3] FCS retention in PWE3 Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- Mark> wouldn't ports "b" and "c" be able to detect FCS errors before they Mark> entered the customers network, and at least provide an indication that Mark> the problem is in the operators network and not the customers, Mark> therefore narrowing down the problem of diagnosing TCP checksum Mark> errors? I don't think so. Presumably the frame is ethernet-checksummed from its source to the ingress PE, and then is ethernet-checksummed again from the egress PE to its destination. The only place where it is not ethernet-checksummed is in the SP network. So if the frame actually arrives at the destination host with a bad TCP checksum, chances seem high that the problem was in the operator's network. _______________________________________________ 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: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 12:05:29 -0800 Lines: 328 Sender: pwe3-admin@ietf.org References: <000101c3b2b2$062e3440$338c23a6@acer4wc5zk5t43> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Mon Nov 24 21:01:06 2003 Return-path: To: , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000101c3b2b2$062e3440$338c23a6@acer4wc5zk5t43> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: Nick DelRegno Subject: RE: FCS retention in PWE3 Date: Mon, 24 Nov 2003 13:51:55 -0600 Lines: 66 Sender: pwe3-admin@ietf.org References: <200311241926.hAOJQxxg012235@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 24 21:02:02 2003 Return-path: In-reply-to: <200311241926.hAOJQxxg012235@rtp-core-1.cisco.com> To: erosen@cisco.com, "'mark seery'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 The problem is that noone will ever see the TCP checksum reported! What = if it is UDP and checksum is disabled? Please educate me as to how, as a SP, I can detect TCP checksum errors = in my network, IP, Ethernet or otherwise. How often, when a client station is experiencing Internet connectivity issues, does Support say, "Please tell me what your TCP Checksum counter says," or better yet, Tech Support calls the end user to tell them "Our network management system indicates an unusually high number of TCP = Checksum errors being reported by several end stations in our network, yours = being one." ?? In my exerperience, never. The bottom line is: If I am connecting two Layer 2/Layer 3 devices = together via an emulated Layer 2 connection, I need to ensure that the part of = the link carried by my emulation is functioning properly. Not doing so is = like not running Ethernet FCS on the links connecting my SP ethernet switches together. We would never do that. Retaining the error check mechanism = that is already there provides the error check I require without dramatically changing the spirit or form of PWE3. > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On=20 > Behalf Of Eric Rosen > Sent: Monday, November 24, 2003 1:27 PM > To: mark seery > Cc: pwe3@ietf.org > Subject: Re: [PWE3] FCS retention in PWE3 >=20 >=20 > Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- >=20 > Mark> wouldn't ports "b" and "c" be able to detect FCS =20 > errors before=20 > Mark> they entered the customers network, and at least provide an=20 > Mark> indication that the problem is in the operators =20 > network and=20 > Mark> not the customers, therefore narrowing down the =20 > problem of =20 > Mark> diagnosing TCP checksum errors? >=20 > I don't think so. Presumably the frame is=20 > ethernet-checksummed from its > source to the ingress PE, and then is ethernet-checksummed =20 > again from the > egress PE to its destination. The only place =20 > where it is not > ethernet-checksummed is in the SP network. So if the frame=20 > actually arrives at the destination host with a bad TCP=20 > checksum, chances seem high that the problem was in the=20 > operator's network.=20 >=20 >=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: Eric Rosen Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 15:35:20 -0500 Lines: 50 Sender: pwe3-admin@ietf.org References: <000b01c3b2c3$ccdd06f0$338c23a6@acer4wc5zk5t43> Reply-To: erosen@cisco.com Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Cc: "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Mon Nov 24 21:37:08 2003 Return-path: To: Scott Kotrla In-reply-to: Your message of Mon, 24 Nov 2003 13:47:31 -0600. <000b01c3b2c3$ccdd06f0$338c23a6@acer4wc5zk5t43> 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 Scott> Why couldn't the corruption be occurring in the customer's network? In my interpretation of Mark's example, there's an FCS carried from the source host to the operator's network (native ethernet service), and then another FCS carried from the operator's network to the destination host (native ethernet service), so corruption in the customer's network would be caught by the FCS. (Of course, it's also possible that the ingress PE fails to properly detect an invalid FCS. This is no less likely than having a device which corrupts the packets, and would certainly make diagnosis difficult.) Nick> The bottom line is: If I am connecting two Layer 2/Layer 3 devices Nick> together via an emulated Layer 2 connection, I need to ensure that the Nick> part of the link carried by my emulation is functioning properly. Of course; that implies the need for some OAM capability. What we're discussing here is a particular solution, not the question of whether you really need to maintain your network. Nick> when a client station is experiencing Internet connectivity issues If you were a service provider offering layer 3 connectivity, how would you handle IP connectivity problems? Nick> Please educate me as to how, as a SP, I can detect TCP checksum errors Nick> in my network, IP, Ethernet or otherwise. How do you determine that some customer's ethernet equipment is detecting checksum errors on packets that came from your equipment? Note that if some particular switch in your network is corrupting packets, the corrupt packets may enter the networks of a variety of customers at a variety of different places, not necessarily causing a very large "bad checksum" spike in any one place. I think what you are really asking for is an OAM capability which will identify the PWs that are experiencing trouble. Scott> The blanket statement that it would NEVER be useful ... is absurd. I don't think anyone said it could never be useful, one can certainly construct situations in which it would be useful. The question is whether it gives you a significant increase in coverage. Andy> I guess we can continue to repeat the same positions over again The post-IETF debate has gone to a somewhat deeper level; I haven't yet ruled out the possibility that someone will actually learn something from someone else, unlikely as it may seem ;-) From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 15:58:47 -0500 (EST) Lines: 14 Sender: pwe3-admin@ietf.org References: <200311242035.hAOKZKDM000741@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: "'mark seery'" , X-From: pwe3-admin@ietf.org Mon Nov 24 22:00:11 2003 Return-path: To: , Scott Kotrla In-Reply-To: <200311242035.hAOKZKDM000741@rtp-core-2.cisco.com> from Eric Rosen on Mon, 24 Nov 2003 15:35:20 -0500 Content-Disposition: inline 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 Eric, ---- Eric Rosen wrote: > In my interpretation of Mark's example, there's an FCS carried from the > source host to the operator's network (native ethernet service), and then > another FCS carried from the operator's network to the destination host > (native ethernet service), so corruption in the customer's network would be > caught by the FCS. My diagram could be interpreted in light of the optional proposal on the table (Mallis et el.) in which case the first part of the above is correct; alternatively it could be interpreted in the context of the general conversation in which case the FCS is retained, copied to the PW, copied to the egress. The diagram could have been clearer. The point is, how does the SP determine (including historically and with trending) where errors are occurring - seems you are headed down the OAM route - which brings up the issue of an e2e OAM mechanism. Errors could also be occurring within the customer equipment on the egress side of the CE, a check at CE would be useful in that case. If as Mick states a CRC-32 is not useful, then that's a whole nother ball game. -mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Keith Knightson Subject: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 17:48:08 -0500 Lines: 80 Sender: pwe3-admin@ietf.org References: <000801c3b2c2$98266b00$338c23a6@acer4wc5zk5t43> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-From: pwe3-admin@ietf.org Mon Nov 24 23:54:04 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <000801c3b2c2$98266b00$338c23a6@acer4wc5zk5t43> To: pwe3@ietf.org X-Authentication-Info: Submitted using SMTP AUTH LOGIN at web01-imail.rogers.com from [24.103.72.56] using ID at Mon, 24 Nov 2003 17:53:35 -0500 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, Anyway, let's set aside specious architectural arguments for a moment. What is the objective? Is the objective to make the CE1 - CE2 path emulate a piece of wire, even though in reality it contains a CE1-PE1 - PE2 - CE2 intervening section? Then and only then would there be a requirement to at least consider the problem. If this was the objective, it seems to me that there is no practical solution. Because..... First we need to capture the FCS at the ingress of PE1 (assuming it checks ok, if not discard). I am not sure that FCS can be kept. In my experience, when a frame is being received the FCS also goes through the hardware polynomial division process to get a zero result if correct? There's a piece of math thats shows that Frame plus FCS all divided by the ploynomial goes to zero. The result is binary, good or bad. This avoids the need for a two step process. So there is never a residual FCS to capture. Thus, we may fall at the very first hurdle. Can someone check this point? Anyway let's suppose the original FCS can be captured and can be associated in some way with the frame, by pre-pending, appending, whatever. BTW, a recalculation fomr the payload will not fit the bill, since it could be corrupted in memory of PE1 prior to recalculation, which presumably would have to be a software process, since there are no outgoing ethernet hardware ports on the PW side of the PE1. The payload is then PW'ed, in IP, MPLS, whatever. At the ingress to PE2, the payload + plus its FCS would be dumped in memory. This could be checked by software, it seems to me it would have to be, unless PE2 can transmit the frame to get a new FCS derived from payload (minus the original FCS) to itself in order that received FCS is still equal to the one stored in memory. This would allow PE2 to discard a frame corrupted over the PW. this is conditional on being able to capture FCS from receiving hardware. But now we still have to ensure that PE2 itself does corrupt the payload before transmitting to CE2. We have an outgoing ethernet port on PE2 to CE2, with its autonomous sending hardware with its autonomous "on the fly" FCS addition. As far as I know (which admittedly may not be very far) when stuff is queued for transmitting that's the end of it. It just goes all by itself. The FCS is being calculated as it goes out on the wire and is automatically slammed on the end. How on earth is this "on the fly" FCS going to be compared to the original FCS still stuck in memory somewhere? I do not believe the FCS is retained after transmission, and even if it could its too late. The frame has already gone with the new FCS! Why is the hardware designed like this? Because it has been architected that way, it conforms to the architecture. So in the end, the IEEE original architecture does count, and it is not surprising considering the definition of its layering. It seems to me that the objective is in fact unobtainable given the hardware at our disposal. BTW, when people say "this is an architectural violation' or the "architecture requires it", what they usually mean is one or both of two things: a) my idea of what an architecture is, is better than yours, and b) I can't find any other proper justification for what I want to you to do (or not do) I think those who want this service have a duty to explain how this is all going to work. I may have missed something vital in my rant. Regards Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Keith Knightson Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 17:59:35 -0500 Lines: 81 Sender: pwe3-admin@ietf.org References: <200311242058.PAA20253@linus.bcentralhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "'mark seery'" , , X-From: pwe3-admin@ietf.org Mon Nov 24 23:56:02 2003 Return-path: X-Sender: kgk@mailbox.ott.igs.net In-Reply-To: <200311242058.PAA20253@linus.bcentralhost.com> To: mark seery , , Scott Kotrla X-Authentication-Info: Submitted using SMTP AUTH LOGIN at web01-imail.rogers.com from [24.103.72.56] using ID at Mon, 24 Nov 2003 17:55:05 -0500 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, Let's set aside specious architectural arguments for a moment. Let's say that the objective is to make the CE1 - CE2 path emulate a piece of wire, even though in reality it contains a CE1-PE1-PE2-CE2 intervening section? Then and only then would there be a requirement to at least consider the problem. If this was the objective, it seems to me that there is no practical solution. Because..... First we need to capture the FCS at the ingress of PE1 (assuming it checks ok, if not discard). I am not sure that FCS can be kept. In my experience, when a frame is being received the FCS also goes through the hardware polynomial division process to get a zero result if correct. There's a piece of math thats shows that Frame plus the received FCS all divided by the ploynomial goes to zero. The result is binary, good or bad. This avoids the need for a two step process. So there is never a residual FCS to capture. Thus, we may fall at the very first hurdle. Can someone check this point? Anyway let's suppose the original FCS can be captured and can be associated in some way with the frame, by pre-pending, appending, whatever. BTW, a recalculation from the payload will not fit the bill, since it could be corrupted in memory of PE1 prior to recalculation, which presumably would have to be a software process, since there are no outgoing ethernet hardware ports on the PW side of the PE1. Ok, so now payload plus the original FCS is then PW'ed, in IP, MPLS, whatever. At the ingress to PE2, the payload + plus its FCS would be dumped in memory. This could be checked by software, it seems to me it would have to be, unless PE2 can somehow transmit the frame to get a new FCS derived from payload (minus the original FCS) to itself in order that received FCS is still equal to the one stored in memory. This would allow PE2 to discard a frame corrupted over the PW. this is again conditional on being able to capture FCS from receiving hardware. But now we still have to ensure that PE2 itself does corrupt the payload before transmitting to CE2. We have an outgoing ethernet port on PE2 to CE2, with its autonomous sending hardware with its autonomous "on the fly" FCS addition. As far as I know (which admittedly may not be very far) when stuff is queued for transmitting that's the end of it. It just goes all by itself. The FCS is being calculated as it goes out on the wire and is automatically slammed on the end. How on earth is this "on the fly" FCS going to be compared to the original FCS still lying about in memory somewhere? I do not believe the FCS is retained after transmission, and even if it could it's too late. The frame has already gone with the new FCS! Why is the hardware designed like this? Well, because it has been architected that way, it conforms to the IEEE architecture. So in the end, the IEEE original architecture does count, and it is not surprising considering the definition of its layering. It seems to me that the objective is in fact unobtainable given the hardware at our disposal. BTW, when people say "this is an architectural violation' or the "architecture requires it", what they usually mean is one or both of two things: a) my idea of what an architecture is, is better than yours, and b) I can't find any other proper justification for what I want to you to do (or not do) I think those who want this service have a duty to explain how this is all going to work. I may have missed something vital in my rant, and am willing to eat whatever crow is necessary, but I just don't see how to do it. Regards Keith From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Andrew G. Malis" Subject: Re: FCS retention in PWE3 Date: Mon, 24 Nov 2003 14:51:02 -0500 Lines: 97 Sender: pwe3-admin@ietf.org References: <200311241743.hAOHhBDM021271@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: stbryant@cisco.com, "pwe3@ietf.org" X-From: pwe3-admin@ietf.org Tue Nov 25 11:08:20 2003 Return-path: X-Sender: andymalis@comcast.net@mail.comcast.net X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 To: erosen@cisco.com In-Reply-To: <200311241743.hAOHhBDM021271@rtp-core-2.cisco.com> References: <200311241743.hAOHhBDM021271@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 Eric, I think we've pretty beat to death whether or not FCS retention has merit, although I guess we can continue to repeat the same positions over again. Both on the list and in Minneapolis, there has been expressed interest and consensus (which certainly doesn't meant unanimity :-) to make this a WG draft. There are service providers who have said they would like to have this available for their networks, and vendors interested in implementing it. As I said previously, I've tried to capture the discussion from the list in the new applicability section. The draft should be out within a day or two (it's already been submitted), and I certainly invite your comments on the draft text. Cheers, Andy ---------- At 11/24/2003 12:43 PM -0500, Eric Rosen wrote: >One thing that is clear from this discussion is that we were right to keep >the FCS option out of the base spec! It's not at all clear that carrying >the FCS is either a necessary or a sufficient condition for the solution of >any actual problem. > >Let's step back and look at some of the reasons advanced for carrying the >customer FCS: > >1. Port-to-port ethernet is a "transmission service". Unlike general > network services, it is a requirement of "transmission services" that > every bit which goes in one end must come out the other end. > > We haven't discussed this putative requirement very much. There's been > some suggestion that failure to meet it will result in a customer > relations problem (between the SP and its customers), but I haven't seen > very much to back this up. Perhaps this is just a dogma from the past, > which can be discarded. > >2. A switch in the SP network may corrupt frames. If this happens, and if > there is no FCS which the egress PE can check, then the corrupted frames > will be sent to the customer network. If this is a regular occurrence, > then the customer will complain to the SP. It would be better if the SP > could detect the corruption, and not send the corrupted frames to the > customer. (Presumably the customer wont complain about the missing > frames?) > > There seem to be two problems with this argument: > > a. Since the ethernet FCS is not validated on egress from a switch, this > can't be done. Frames with bit errors will be sent to the customer > even if they carry the customer's original FCS. > > b. If this were really a requirement, it would apply equally well to > services other than port-to-port ethernet, even though carrying the > customer's original FCS is not a possibility for those services. > Hence a solution other than carrying the customer's original FCS would > be required. > > In fact, what would really be needed to solve this problem is a > PW-specific checksum which is created by the ingress PE and validated by > the egress PE. However, no one has actually asked for that, probably > because the added overhead it would create is obvious and the payback is > minimal. > > By the way, anyone who thinks that the FCS should be used to enable the > SP (rather than the customer) to detect the corruption should argue that > the egress PE MUST validate the FCS. I don't see much point in saying > "MAY", as I think Andy has proposed. > >3. IEEE specs require that any media connecting two bridges provide a > bounded rate of undetected errors. > > However, I think the discussion has made it pretty clear that carrying > the customer FCS through the PWs is not necessary to meet this > requirement. As far as I can tell, it is not sufficient either, because > it is not possible to do in various scenarios involving VLANs. > >4. A proper understanding of the theoretical aspects of network layering > and/or IEEE standards require that the customer FCS be carried > transparently. > > There are two problems with this argument: > > a. Who cares? > > b. In my judgment, Mick Seaman and Keith Knightson have thoroughly > refuted the claim that this is even a theoretical requirement. > >Taking all these together, I just don't see any reason to pursue the >"customer FCS retention" capability, even as an option. > > > >_______________________________________________ >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: mark seery Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Mon, 24 Nov 2003 05:51:41 -0800 Lines: 62 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2E8C@i2km07-ukbr.domain1.systemhost.net> <3FC14FF9.5070709@cisco.com> Reply-To: m_seery@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: neil.2.harrison@bt.com, kgk@igs.net, jmessenger@advaoptical.com, nfinn@cisco.com, mark@interflect.com, stds-802-1@ieee.org, pwe3@ietf.org, Maarten.Vissers@alcatel.de, alan.mcguire@bt.com X-From: pwe3-admin@ietf.org Tue Nov 25 11:08:25 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: stbryant@cisco.com In-Reply-To: <3FC14FF9.5070709@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 Stewart Bryant wrote: > >>> If you assume a PW to be a sort of bridge, >> >> >> NH=> A PW is for sure not a bridge! A PW is an adaptation funtion >> that lies between a client layer network and a server layer network >> of MPLS or IP. > > > Neil > > Surely that is just one way to model the PW? Can't a PW also be > modelled as a repeater with certain internal delay and error > characteristics. > > Stewart > > _____________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 Stewart, I have worked on equipment that transported Ethernet over a tunnel, without doing bridging, and the Ethernet testers have commented to me "this is a repeater". So I think the analogy you make is intuitive for Ethernet people. It is not technically correct because of the formal definition of repeaters (IMO), but in spirit it is. The more difficult issue is that repeaters have 802 on ingress and egress, so if we are to extend this analogy, then a PW is an internal connection within the "virtual repeater" that is not part of a formal 802 model, other than it should not introduce errors greater than some prescription. All Neil is suggesting is that the internal connection is "transporting" the ethernet layer, and he is further arguing for a principle of layer encapsulation (similar to object encapsulation in software) which is very similar in spirit to the principle of minimum intervention sited in the PW architecture document (3.3.5). All that is left is to argue about whether the FCS belongs to the layer being transported. I would assume a real 802 repeater would not strip the FCS, so if we were to take the analogy to the extreme, we would not strip the FCS here either, but of course as this is not a real repeater function, so we are left with balancing the models and requirements of at multiple views: IEEE, IP, IP-MPLS, ITU, carrier operations/engineering. In a later email you say: "For the PW to be an adaptation function, one would have to assert hat the contents of the PW had some meaning within the PSN. I don't beleive it has, because we never communicate any context information to any object in the PSN (either by signalling or self description) which it can use to interpret the contents of the PW." If we were to assert that the contents of the PW had some meaning within the PSN, I would suggest that would be an interworking function, not an adaptation function. mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: Re: FCS retention in PWE3 Date: Tue, 25 Nov 2003 10:46:40 +0000 Organization: Cisco Systems, Inc. Lines: 83 Sender: pwe3-admin@ietf.org References: <000b01c3b2c3$ccdd06f0$338c23a6@acer4wc5zk5t43> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 11:48:06 2003 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: Scott Kotrla In-Reply-To: <000b01c3b2c3$ccdd06f0$338c23a6@acer4wc5zk5t43> 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 A question that I have raised before, and called up in my applicability statement notes is whether VCCV (or similar) allows us to diagnose the problem more accurately. VCCV run between the PEs will allow the SP to audit the PW's path over the PSN. The only element not covered is the circuit between the CE and the PE, and the different internal data path between the VCCV generator/receiver and the PE-PSN interface. If the customer also runs an OAM protocol, they can audit from CE to CE and validate the whole SP PW path. Unlike the FCS approach the OAM could be signed with a decent crypto and would not be fooled by short error bursts. If FCS is the right tool for the path audit we should use it, but I am not convinced that it will do better than a purpose designed OAM protocol. Stewart Scott Kotrla wrote: > Why couldn't the corruption be occurring in the customer's network? How > are the provider and customer supposed to figure out whose fault it is > with certainty? Because all of the links are checksummed, the error had > to have occurred inside a device. But there is NO way to isolate whether > it was a provider device or a customer device. There are likely more > customer devices in the path than carrier devices, so it would seem more > likely to be a customer problem. > > Is it not clear that this is a huge nightmare for a service provider who > deploys this in a large scale? I just don't get how people cannot see > how this could be useful in some SP networks. The blanket statement > that it would NEVER be useful and shouldn't be an OPTION is absurd. > > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Eric > Rosen > Sent: Monday, November 24, 2003 1:27 PM > To: mark seery > Cc: pwe3@ietf.org > Subject: Re: [PWE3] FCS retention in PWE3 > > Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- > > Mark> wouldn't ports "b" and "c" be able to detect FCS errors before > they > Mark> entered the customers network, and at least provide an indication > that > Mark> the problem is in the operators network and not the > customers, > Mark> therefore narrowing down the problem of diagnosing TCP > checksum > Mark> errors? > > I don't think so. Presumably the frame is ethernet-checksummed from > its > source to the ingress PE, and then is ethernet-checksummed again from > the > egress PE to its destination. The only place where it is > not > ethernet-checksummed is in the SP network. So if the frame actually > arrives > at the destination host with a bad TCP checksum, chances seem high that > the > problem was in the operator's network. > > > _______________________________________________ > 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: Stewart Bryant Subject: Re: FCS retention in PWE3 Date: Tue, 25 Nov 2003 10:48:47 +0000 Organization: Cisco Systems, Inc. Lines: 23 Sender: pwe3-admin@ietf.org References: <000501c3b2c4$6a121550$4c8b23a6@nick> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: erosen@cisco.com, "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 11:50:02 2003 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: Nick DelRegno In-Reply-To: <000501c3b2c4$6a121550$4c8b23a6@nick> 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 Nick DelRegno wrote: > The problem is that noone will ever see the TCP checksum reported! What if > it is UDP and checksum is disabled? > > Please educate me as to how, as a SP, I can detect TCP checksum errors in my > network, IP, Ethernet or otherwise. > > How often, when a client station is experiencing Internet connectivity > issues, does Support say, "Please tell me what your TCP Checksum counter > says," or better yet, Tech Support calls the end user to tell them "Our > network management system indicates an unusually high number of TCP Checksum > errors being reported by several end stations in our network, yours being > one." ?? In my exerperience, never. > But on the other hand you have not had a decent OAM protocol running in background in the past. Stewart > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Stewart Bryant Subject: Re: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 11:14:05 +0000 Organization: Cisco Systems, Inc. Lines: 384 Sender: pwe3-admin@ietf.org References: <000401c3b2c6$5019e950$210110ac@corp.telseon.com> Reply-To: stbryant@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stds-802-1@ieee.org, pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 12:15:13 2003 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: mick_seaman@ieee.org In-Reply-To: <000401c3b2c6$5019e950$210110ac@corp.telseon.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 The IEEE 802.1 community may not be aware, but in addition to the encapsulation protocols, PWE3 is also standardising an OAM protocol designed to validate the PW. http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-01.txt This does not do a thorough bit integrity test, and maybe it needs to be extended to do so. Perhaps the best way for a customer to validate the PW is with an OAM protocol that runs between the CEs, rather than trying to discover the problem implicitly through the FCS? Stewart Mick Seaman wrote: > There seems to be an undercurrent in this discussion that somehow an FCS-32 > is good protection against arbitrary packet mangling. Sorry, not true. > > The FCS/CRC-32 is designed to protect against a limited number of changes in > bits, and was designed against a noise error model that rated changes in > more than a certain number of bits improbable. You can't reliably use the > CRC to defend against a wider range of errors such as omission or > replacement of whole bytes or words (which has been know to sporadically > occur in DMA controllers designed close to their limits), or substitution of > part of the frame for another frame (which might occur if frames were > interleaved on a synchronous clock and the clock slipped a bit position once > in a while for example). Nor does the FCS protect well against software > errors where a relay system does something other than it is supposed to do > when forwarding a frame. > > The protection offered by a CRC-32 against such events is little better than > the chance of randomly guessing the right number in 2**32. To put that in > perspective if all frames on a fully utilised 10 Gb/s link were errored you > would get a frame with a good FCS about once every 20 minutes. Of course if > all the frames were errored the link would probably come down, but spread > around a network or many the errored 10Gb/s aggregate is more plausible. Now > if you factor out all the errors that are going to get caught with the exact > same CRC algorithm used on a link by link basis then the extra CRC is pretty > much a waste of 4 bytes. At least use a different integrity check if you are > serious! (and not one that the existing hardware is not going to > accidentally emulate by accident when there is a software bug!). > > This discussion seems to be largely driven by philosophy, if it is going to > go anywhere at all there better be an engineering component. > > Separately you are not going to get bit level transparency for a bridged > network. In particular we have already established the layering model will > not be broken to allow media specific frames (PAUSE, LACP) etc. to transit > though bridges. > > Mick > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla > Sent: Monday, November 24, 2003 9:40 AM > To: neil.2.harrison@bt.com; nfinn@cisco.com > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > As a service provider, I want layers. I want to be as a transparent as > possible. Throwing away the customer's FCS and introducing the > possibility of undetected errors is not transparent. VLAN stacking > isn't the best solution here for layer encapsulation, but it can work. > MAC-in-MAC is architecturally a better fit because the whole customer > frame goes into the new payload field, but wasting 12 bytes for dummy > DA/SA that won't be used for TRANS (MEF layer) applications doesn't make > a lot of sense. ETH layer functionality is the application of existing > 802 technologies to service providers, so arguments about what exactly > does or does not belong has value. > > TRANS layer functionality for physical Ethernet transport is new > functionality that 802 was not designed for. But for service providers, > this provides new requirements. The TRANS layer often refers to > transport over SONET, but there is no reason why it shouldn't also > support the model of transport over Ethernet, in which case the > requirements are different from ETH requirements. If physical Ethernet > is being used for point-to-point TRANS functionality, new features like > a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable > alternative to Ethernet over SONET. > > In this context, it may be clearer how Stacked VLANs and PW are > comparable. As a provider, I am looking for a way to tunnel customer > ports or customer VLANs from point-to-point from end-to-end > transparently across the access network. I am open to other > alternatives. Ethernet TRANS should maintain customer FCS end-to-end as > a separate layer from the service Ethernet Link FCS. > > As some background, what started MCI's quest for FCS retention was a lab > infrastructure Ethernet switch that was corrupting packets and > calculating a new FCS on packets where no changes should have been > occurring. This was one of the top Ethernet switch vendors as provided > by Gartner in 2002. This took days to troubleshoot, and as service > providers, scared the Hell out of us. The idea of VLAN stacking, VLAN > swapping, marking as discard eligible, and messing with packets in > general seems to open up the possibility of such things happening even > more. > > Thanks, > > Scott > > -----Original Message----- > From: owner-stds-802-1@majordomo.ieee.org > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of > neil.2.harrison@bt.com > Sent: Friday, November 21, 2003 11:16 AM > To: nfinn@cisco.com > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > Hi Norm....We are on the same page I am sure, just using different > words....please see in-line. > > regards, Neil > > >>Norman Finn wrote 21 November 2003 12:03 >> >> >>Neil, >> >>I think Pat Thaler's reply helps to straighten out this >>confusion, but let me >>try, also. >> >>There is a *lot* of confusion about the words "end-to-end", >>and about "transport layers". > > NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as > I hope was clear this week from Maarten's excellent analysis of the > ethernet OAM issues at SG13. > > >>There are lots of ends in this picture, and there are layers >>and there are layers. > > NH=> Agreed.....just wish some more people grokked this stuff as it > should help mitigate arch violates. > >>An 802.1Q VLAN bridge, and by extension, a P802.1ad provider >>bridge, does NOT supply a >>"transport layer" in the same sense as IP-over-Ethernet or >>Ethernet-over-IP. This is >>because, at the data forwarding layers, VLAN tags are best >>though of as extensions to >>the address space, not as additional protocol layers. > > NH=> Understood and agree. > > >> If you >>want to call it a >>"transport layer", feel free! > > NH=> No, that would be completely wrong....VLANs do *not* form a layer > network in any way, shape or form. > > >> But don't assume that VLANs >>are equivalent to other >>"transport layers". Data integrity, specifically, is >>different in bridges. >> >>Routers provide "best effort" not only in frame delivery, but >>in data integrity. There >>is no upper limit specified for the probability of delivery >>of a packet with undetected >>errors. IP's response, if you demand a particular level of >>data integrity, is that >>your application must supply its own checksum. >> >>Bridges, however, are not routers! >> >>Bridges *do* guarantee a level of service. They manage to do >>this by guaranteeing the >>quality of each bridge, and by *demanding* the quality of >>each link. Non-VLAN bridges, >>VLAN bridges, and Provider Bridges all make that guarantee to >>their users using this >>method. The Customers of a Provider Bridge service are not >>an "802.1Q application" >>over an "802.1ad transport layer". They are, in the 802.1 >>model, just endstations >>attached to a bridge. The Customers' data is just as well >>protected as an enterprise >>bridges' endstations, as long as the model is maintained. >>Adding an additional CRC >>to end-to-end service, where the ends are Customers attached >>to 802.1ad Provider >>Bridges, is therefore pointless. Changing that model is as >>silly as turning the model >>for routing upside down. > > NH=> I agree with all this....so not quite sure what you think I am not > understanding here. > >>When a Pseudowire is used to connect two bridges, > > NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does > create layer networks however....but I suspect that is not well > understood by many. One of my colleagues, who like Maarten is a real > expert in the func modelling detail, is formally describing MPLS right > now...but of course MPLS is a not a singular layer network, it has many > flavours and this work will clearly bring out the different arch > behaviours. > > >>the >>"end-to-end" is now just those >>two bridges. > > NH=> Agreed. If one drew out the proper func arch model one can see > this immediately. > > >>Those bridges are using that PW as an Ethernet >>to carry their traffic. >>The bridges demand that every wire be as reliable as an >>Ethernet. That's the PW CRC >>issue. > > NH=> Grokked totally. A PW is a form of adaptation function that lies > between a client (here we are discussing ethernet) and MPLS (or IP if > one is happy with a cnls server behaviour)...and then there are further > layer networks below this, eg the VC4 layer network of SDH, until we hit > the duct. The fact that a PW is not a layer network and not really > necessary is neither here nor there....other than its just something > else to manage. When the port on a bridge is not connected to an > 'ethernet shared media' (orginal case), but some technology (any) then > one simply has to adapt the ethernet PDU (*including its FCS*, as its > part of the client ethernet CI) to the payload of the server layer. One > should *not* be playing around with client layer network structures in a > simple client->server adaptation process at all. So I am totally > against all the 'Martini' PW compression stuff....the BW squeezing is > simply not worth it (compared to other technolgies that will squander > BW). So ! > IMO the ethernet FCS is part of the ethernet's CI and should not be > removed by *any* server layer technology. > >>-- Norm >> >>neil.2.harrison@bt.com wrote: >> >>>Norm....As per our discussion today face-face. I don't >> >>really see what the problem is here. The client layer >>network should not care about the server layer network (and >>vice versa)....we need this layer independence for lots of >>reasons. An ethernet traffic unit has a FCS. This should >>simply be transported transparently in the payload area of >>whatever the server layer is....and the server layer should >>use its own (OAM) 'integrity mechanisms' irrespective of the >>client. Problems arise when people start doing things like >>client layer compression and thus forming inter-layer dependencies. >> >>>Further, as we agreed today and as I posted on an earlier >> >>mail to this thread, the ethernet FCS is a CRC that can be >>linerarly updated for adaptation function changes (eg VLAN ID >>change) on each link-connection (as provided by some server >>layer trail technology) whilst preserving its end-end >>intergrity check of the rest of the ethernet traffic unit >>between its trail termination points. >> >>>regards, Neil >>> >>> >>> >>>>-----Original Message----- >>>>From: Norman Finn [mailto:nfinn@cisco.com] >>>>Sent: 18 November 2003 08:56 >>>>To: mark seery >>>>Cc: stds-802-1@ieee.org; pwe3@ietf.org >>>>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >>>> >>>> >>>>Mark, >>>> >>>>You say below, >>>> >>>> >>>>>but a PW will be running over a physical media itself >>>> >>>>already, possibly >>>> >>>>>even SONET............. >>>> >>>>Exactly! Here, the trail gets a bit murky. If I'm in total >>>>control, and the PW >>>>is running over known Ethernet links, then I can get away >>>>without the CRC in the >>>>PW. I have no problem whatsoever with the current definition >>>>of PWs without CRC. >>>> >>>>But, if I don't have tight control over the physical media >>>>over which the PW runs, >>>>then I really need a CRC on the PW for the bridge to be able >>>>to trust the "wire" >>>>and thus provide the same level of data integrity that >>>>bridges offer over physical >>>>Ethernets. So, I claim that bridges need a CRC option on PWs. >>>> >>>>-- Norm >>>> >>>>mark seery wrote: >>>> >>>> >>>>>Norman Finn wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>>In other words, routers pass about $0.93 of the data >>>>> >>>>integrity buck to >>>> >>>> >>>>>>bridges, >>>>>>and bridges pass about $0.75 of that to the data links. >>>>> >>>>The buck has >>>> >>>> >>>>>>to stop >>>>>>somewhere, and the data link is where it stops. The PW >>>>> >>>>has to take >>>> >>>> >>>>>>the same >>>>>>hit as the physical media. >>>>>> >>>>>>-- Norm >>>>> >>>>> >>>>>but a PW will be running over a physical media itself >>>> >>>>already, possibly >>>> >>>> >>>>>even SONET............. >>>>> >>>>>mark >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>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: Sasha Vainshtein Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 13:33:45 +0200 Lines: 474 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-8" Cc: stds-802-1@ieee.org, pwe3@ietf.org, mick_seaman@ieee.org X-From: pwe3-admin@ietf.org Tue Nov 25 12:37:09 2003 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, 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: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, November 25, 2003 1:14 PM > To: mick_seaman@ieee.org > Cc: stds-802-1@ieee.org; pwe3@ietf.org > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > The IEEE 802.1 community may not be aware, but in addition to the > encapsulation protocols, PWE3 is also standardising an OAM protocol > designed to validate the PW. > > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-01.txt > > This does not do a thorough bit integrity test, and maybe it > needs to be extended to do so. > > Perhaps the best way for a customer to validate the PW is > with an OAM protocol that runs between the CEs, rather than > trying to discover the problem implicitly through the FCS? > [Sasha] I am not sure this is the correct approach since it would mean that the customer is aware of the fact that connection between CE devices passes through a PW and has to modify CEs accordingly. > > Stewart > > > Mick Seaman wrote: > > > There seems to be an undercurrent in this discussion that > somehow an FCS-32 > > is good protection against arbitrary packet mangling. > Sorry, not true. > > > > The FCS/CRC-32 is designed to protect against a limited > number of changes in > > bits, and was designed against a noise error model that > rated changes in > > more than a certain number of bits improbable. You can't > reliably use the > > CRC to defend against a wider range of errors such as omission or > > replacement of whole bytes or words (which has been know to > sporadically > > occur in DMA controllers designed close to their limits), > or substitution of > > part of the frame for another frame (which might occur if > frames were > > interleaved on a synchronous clock and the clock slipped a > bit position once > > in a while for example). Nor does the FCS protect well > against software > > errors where a relay system does something other than it is > supposed to do > > when forwarding a frame. > > > > The protection offered by a CRC-32 against such events is > little better than > > the chance of randomly guessing the right number in 2**32. > To put that in > > perspective if all frames on a fully utilised 10 Gb/s link > were errored you > > would get a frame with a good FCS about once every 20 > minutes. Of course if > > all the frames were errored the link would probably come > down, but spread > > around a network or many the errored 10Gb/s aggregate is > more plausible. Now > > if you factor out all the errors that are going to get > caught with the exact > > same CRC algorithm used on a link by link basis then the > extra CRC is pretty > > much a waste of 4 bytes. At least use a different integrity > check if you are > > serious! (and not one that the existing hardware is not going to > > accidentally emulate by accident when there is a software bug!). > > > > This discussion seems to be largely driven by philosophy, > if it is going to > > go anywhere at all there better be an engineering component. > > > > Separately you are not going to get bit level transparency > for a bridged > > network. In particular we have already established the > layering model will > > not be broken to allow media specific frames (PAUSE, LACP) > etc. to transit > > though bridges. > > > > Mick > > > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of > Scott Kotrla > > Sent: Monday, November 24, 2003 9:40 AM > > To: neil.2.harrison@bt.com; nfinn@cisco.com > > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > > > As a service provider, I want layers. I want to be as a > transparent as > > possible. Throwing away the customer's FCS and introducing the > > possibility of undetected errors is not transparent. VLAN stacking > > isn't the best solution here for layer encapsulation, but > it can work. > > MAC-in-MAC is architecturally a better fit because the > whole customer > > frame goes into the new payload field, but wasting 12 bytes > for dummy > > DA/SA that won't be used for TRANS (MEF layer) applications > doesn't make > > a lot of sense. ETH layer functionality is the application > of existing > > 802 technologies to service providers, so arguments about > what exactly > > does or does not belong has value. > > > > TRANS layer functionality for physical Ethernet transport is new > > functionality that 802 was not designed for. But for > service providers, > > this provides new requirements. The TRANS layer often refers to > > transport over SONET, but there is no reason why it shouldn't also > > support the model of transport over Ethernet, in which case the > > requirements are different from ETH requirements. If > physical Ethernet > > is being used for point-to-point TRANS functionality, new > features like > > a Path FCS are required. Otherwise, Ethernet over Fiber is > not a viable > > alternative to Ethernet over SONET. > > > > In this context, it may be clearer how Stacked VLANs and PW are > > comparable. As a provider, I am looking for a way to > tunnel customer > > ports or customer VLANs from point-to-point from end-to-end > > transparently across the access network. I am open to other > > alternatives. Ethernet TRANS should maintain customer FCS > end-to-end as > > a separate layer from the service Ethernet Link FCS. > > > > As some background, what started MCI's quest for FCS > retention was a lab > > infrastructure Ethernet switch that was corrupting packets and > > calculating a new FCS on packets where no changes should have been > > occurring. This was one of the top Ethernet switch vendors > as provided > > by Gartner in 2002. This took days to troubleshoot, and as service > > providers, scared the Hell out of us. The idea of VLAN > stacking, VLAN > > swapping, marking as discard eligible, and messing with packets in > > general seems to open up the possibility of such things > happening even > > more. > > > > Thanks, > > > > Scott > > > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of > > neil.2.harrison@bt.com > > Sent: Friday, November 21, 2003 11:16 AM > > To: nfinn@cisco.com > > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > Hi Norm....We are on the same page I am sure, just using different > > words....please see in-line. > > > > regards, Neil > > > > > >>Norman Finn wrote 21 November 2003 12:03 > >> > >> > >>Neil, > >> > >>I think Pat Thaler's reply helps to straighten out this > >>confusion, but let me > >>try, also. > >> > >>There is a *lot* of confusion about the words "end-to-end", > >>and about "transport layers". > > > > NH=> Agreed. G.805 and G.809 func arch really helps sort > this out...as > > I hope was clear this week from Maarten's excellent analysis of the > > ethernet OAM issues at SG13. > > > > > >>There are lots of ends in this picture, and there are layers > >>and there are layers. > > > > NH=> Agreed.....just wish some more people grokked this stuff as it > > should help mitigate arch violates. > > > >>An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > >>bridge, does NOT supply a > >>"transport layer" in the same sense as IP-over-Ethernet or > >>Ethernet-over-IP. This is > >>because, at the data forwarding layers, VLAN tags are best > >>though of as extensions to > >>the address space, not as additional protocol layers. > > > > NH=> Understood and agree. > > > > > >> If you > >>want to call it a > >>"transport layer", feel free! > > > > NH=> No, that would be completely wrong....VLANs do *not* > form a layer > > network in any way, shape or form. > > > > > >> But don't assume that VLANs > >>are equivalent to other > >>"transport layers". Data integrity, specifically, is > >>different in bridges. > >> > >>Routers provide "best effort" not only in frame delivery, but > >>in data integrity. There > >>is no upper limit specified for the probability of delivery > >>of a packet with undetected > >>errors. IP's response, if you demand a particular level of > >>data integrity, is that > >>your application must supply its own checksum. > >> > >>Bridges, however, are not routers! > >> > >>Bridges *do* guarantee a level of service. They manage to do > >>this by guaranteeing the > >>quality of each bridge, and by *demanding* the quality of > >>each link. Non-VLAN bridges, > >>VLAN bridges, and Provider Bridges all make that guarantee to > >>their users using this > >>method. The Customers of a Provider Bridge service are not > >>an "802.1Q application" > >>over an "802.1ad transport layer". They are, in the 802.1 > >>model, just endstations > >>attached to a bridge. The Customers' data is just as well > >>protected as an enterprise > >>bridges' endstations, as long as the model is maintained. > >>Adding an additional CRC > >>to end-to-end service, where the ends are Customers attached > >>to 802.1ad Provider > >>Bridges, is therefore pointless. Changing that model is as > >>silly as turning the model > >>for routing upside down. > > > > NH=> I agree with all this....so not quite sure what you > think I am not > > understanding here. > > > >>When a Pseudowire is used to connect two bridges, > > > > NH=> Similar to VLANs, a PW is *not* a layer network > either. MPLS does > > create layer networks however....but I suspect that is not well > > understood by many. One of my colleagues, who like Maarten > is a real > > expert in the func modelling detail, is formally describing > MPLS right > > now...but of course MPLS is a not a singular layer network, > it has many > > flavours and this work will clearly bring out the different arch > > behaviours. > > > > > >>the > >>"end-to-end" is now just those > >>two bridges. > > > > NH=> Agreed. If one drew out the proper func arch model one can see > > this immediately. > > > > > >>Those bridges are using that PW as an Ethernet > >>to carry their traffic. > >>The bridges demand that every wire be as reliable as an > >>Ethernet. That's the PW CRC > >>issue. > > > > NH=> Grokked totally. A PW is a form of adaptation function > that lies > > between a client (here we are discussing ethernet) and MPLS > (or IP if > > one is happy with a cnls server behaviour)...and then there > are further > > layer networks below this, eg the VC4 layer network of SDH, > until we hit > > the duct. The fact that a PW is not a layer network and not really > > necessary is neither here nor there....other than its just something > > else to manage. When the port on a bridge is not connected to an > > 'ethernet shared media' (orginal case), but some technology > (any) then > > one simply has to adapt the ethernet PDU (*including its > FCS*, as its > > part of the client ethernet CI) to the payload of the > server layer. One > > should *not* be playing around with client layer network > structures in a > > simple client->server adaptation process at all. So I am totally > > against all the 'Martini' PW compression stuff....the BW > squeezing is > > simply not worth it (compared to other technolgies that > will squander > > BW). So ! > > IMO the ethernet FCS is part of the ethernet's CI and should not be > > removed by *any* server layer technology. > > > >>-- Norm > >> > >>neil.2.harrison@bt.com wrote: > >> > >>>Norm....As per our discussion today face-face. I don't > >> > >>really see what the problem is here. The client layer > >>network should not care about the server layer network (and > >>vice versa)....we need this layer independence for lots of > >>reasons. An ethernet traffic unit has a FCS. This should > >>simply be transported transparently in the payload area of > >>whatever the server layer is....and the server layer should > >>use its own (OAM) 'integrity mechanisms' irrespective of the > >>client. Problems arise when people start doing things like > >>client layer compression and thus forming inter-layer dependencies. > >> > >>>Further, as we agreed today and as I posted on an earlier > >> > >>mail to this thread, the ethernet FCS is a CRC that can be > >>linerarly updated for adaptation function changes (eg VLAN ID > >>change) on each link-connection (as provided by some server > >>layer trail technology) whilst preserving its end-end > >>intergrity check of the rest of the ethernet traffic unit > >>between its trail termination points. > >> > >>>regards, Neil > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Norman Finn [mailto:nfinn@cisco.com] > >>>>Sent: 18 November 2003 08:56 > >>>>To: mark seery > >>>>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>>>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >>>> > >>>> > >>>>Mark, > >>>> > >>>>You say below, > >>>> > >>>> > >>>>>but a PW will be running over a physical media itself > >>>> > >>>>already, possibly > >>>> > >>>>>even SONET............. > >>>> > >>>>Exactly! Here, the trail gets a bit murky. If I'm in total > >>>>control, and the PW > >>>>is running over known Ethernet links, then I can get away > >>>>without the CRC in the > >>>>PW. I have no problem whatsoever with the current definition > >>>>of PWs without CRC. > >>>> > >>>>But, if I don't have tight control over the physical media > >>>>over which the PW runs, > >>>>then I really need a CRC on the PW for the bridge to be able > >>>>to trust the "wire" > >>>>and thus provide the same level of data integrity that > >>>>bridges offer over physical > >>>>Ethernets. So, I claim that bridges need a CRC option on PWs. > >>>> > >>>>-- Norm > >>>> > >>>>mark seery wrote: > >>>> > >>>> > >>>>>Norman Finn wrote: > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>>In other words, routers pass about $0.93 of the data > >>>>> > >>>>integrity buck to > >>>> > >>>> > >>>>>>bridges, > >>>>>>and bridges pass about $0.75 of that to the data links. > >>>>> > >>>>The buck has > >>>> > >>>> > >>>>>>to stop > >>>>>>somewhere, and the data link is where it stops. The PW > >>>>> > >>>>has to take > >>>> > >>>> > >>>>>>the same > >>>>>>hit as the physical media. > >>>>>> > >>>>>>-- Norm > >>>>> > >>>>> > >>>>>but a PW will be running over a physical media itself > >>>> > >>>>already, possibly > >>>> > >>>> > >>>>>even SONET............. > >>>>> > >>>>>mark > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 > > > > > > > _______________________________________________ > 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: neil.2.harrison@bt.com Subject: RE: FCS retention in PWE3 Date: Tue, 25 Nov 2003 12:41:57 -0000 Lines: 136 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 Tue Nov 25 13:43:05 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] FCS retention in PWE3 Thread-Index: AcOzQdvf6JDyrlANRVyjEW2rDig//gADYJUA To: X-OriginalArrivalTime: 25 Nov 2003 12:41:57.0964 (UTC) FILETIME=[83B0F0C0:01C3B351] 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 Stwart, In general I agree with you. But what you are actually saying here is = that we want independent OAM in each layer network (simply has to be = independent....one reason being that we want the *same* OAM solution in = the server irrespective of its client). But please note this: - a PW is not a layer network, ie we do not network/switch PW entities; - an LSP is a layer network, ie we do network/switch LSP entities; - why can't we use Y.1711 OAM on the top level p2p LSP? - Y.1711 is sparse/simple/complete, ie all defects are defined with = entry-exit criteria and consequent actions.....it even defines = availability and does so in order it can be used a single-ended way, ie = behaviour of both directions can be observed from 1 end. - MPLS and ATM OAM layer I/W is already defined in Y.1712.....and again = its really simple. None of this is done (and in some cases is not appropriate) for the VCCV = approach. =20 So what is wrong with this solution? regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Stewart Bryant > Sent: 25 November 2003 10:47 > To: Scott Kotrla > Cc: erosen@cisco.com; 'mark seery'; pwe3@ietf.org > Subject: Re: [PWE3] FCS retention in PWE3 >=20 >=20 >=20 > A question that I have raised before, and called up in my > applicability statement notes is whether VCCV (or similar) > allows us to diagnose the problem more accurately. >=20 > VCCV run between the PEs will allow the SP to audit the PW's > path over the PSN. The only element not covered is the > circuit between the CE and the PE, and the different > internal data path between the VCCV generator/receiver > and the PE-PSN interface. If the customer also runs an > OAM protocol, they can audit from CE to CE and validate > the whole SP PW path. >=20 > Unlike the FCS approach the OAM could be signed with a > decent crypto and would not be fooled by short error bursts. >=20 > If FCS is the right tool for the path audit we should use it, > but I am not convinced that it will do better than a > purpose designed OAM protocol. >=20 > Stewart >=20 >=20 > Scott Kotrla wrote: >=20 > > Why couldn't the corruption be occurring in the customer's=20 > network? How > > are the provider and customer supposed to figure out whose=20 > fault it is > > with certainty? Because all of the links are checksummed,=20 > the error had > > to have occurred inside a device. But there is NO way to=20 > isolate whether > > it was a provider device or a customer device. There are=20 > likely more > > customer devices in the path than carrier devices, so it=20 > would seem more > > likely to be a customer problem. =20 > >=20 > > Is it not clear that this is a huge nightmare for a service=20 > provider who > > deploys this in a large scale? I just don't get how people=20 > cannot see > > how this could be useful in some SP networks. The blanket statement > > that it would NEVER be useful and shouldn't be an OPTION is absurd. > >=20 > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On=20 > Behalf Of Eric > > Rosen > > Sent: Monday, November 24, 2003 1:27 PM > > To: mark seery > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] FCS retention in PWE3 > >=20 > > Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- > >=20 > > Mark> wouldn't ports "b" and "c" be able to detect FCS =20 > errors before > > they > > Mark> entered the customers network, and at least provide=20 > an indication > > that > > Mark> the problem is in the operators network and not the > > customers, > > Mark> therefore narrowing down the problem of diagnosing TCP > > checksum > > Mark> errors? =20 > >=20 > > I don't think so. Presumably the frame is=20 > ethernet-checksummed from > > its > > source to the ingress PE, and then is=20 > ethernet-checksummed again from > > the > > egress PE to its destination. The only place =20 > where it is > > not > > ethernet-checksummed is in the SP network. So if the frame actually > > arrives > > at the destination host with a bad TCP checksum, chances=20 > seem high that > > the > > problem was in the operator's network.=20 > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > 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 > >=20 > >=20 >=20 >=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: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 14:40:45 -0000 Lines: 497 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 Tue Nov 25 15:42:06 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOzRYW5n+a4J8wLSYasbI3WIammFgADTJRQ To: X-OriginalArrivalTime: 25 Nov 2003 14:40:46.0376 (UTC) FILETIME=[1C8E4A80:01C3B362] 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 Stewart, I think it only fair to point out that ITU SG13 has already defined some = pretty good OAM for MPLS p2p LSPs (in Y.1711) that could be complimented = with LSP-Ping for the more complex problem of fault-diagnosis on mp2p = constructs. Further, SG13 is also working on ethernet OAM based on the = functional model of ethernet as defined in G.8010. The OAM solutions required for each of the 3 networking modes of cnls, = co-ps and co-cs mode are somewhat different. A PW is not a layer = network....if you look at the func arch picture of what is going on in = the case of MPLS then an adaptation function (ie comprising of the PW CW = flags/length/Seq No fields, some of which are optional) is being added = onto a (top-level) p2p LSP. IMO the thing that needs the OAM is the LSP = not the PW, so that it can cater for all current and future cases. = Similarly IP needs its own independent OAM which it has in ICMP. = Ethernet also needs its own OAM. Etc. Further, when there are defects between LSPs (ie swaps or = mismerging/branching faults) one wants the OAM to be *same* in order to = detect/handle the defects in a consistent manner irrespective of the = client. This won't be the case if the OAM is only in the PW adaptation = function, ie an LSP carrying a PW interfering with an LSP not carrying a = PW. So I really question the value of adding PW OAM. One further remark below regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of > Stewart Bryant > Sent: 25 November 2003 11:14 > To: mick_seaman@ieee.org > Cc: stds-802-1@ieee.org; pwe3@ietf.org > Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 >=20 > The IEEE 802.1 community may not be aware, but in addition to the > encapsulation protocols, PWE3 is also standardising an OAM protocol > designed to validate the PW. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-01.txt >=20 > This does not do a thorough bit integrity test, and maybe it > needs to be extended to do so. >=20 > Perhaps the best way for a customer to validate the PW is > with an OAM protocol that runs between the CEs, rather than > trying to discover the problem implicitly through the FCS? NH=3D> Why should a client layer be aware of the lower level PW.....or = even any lower level technology right to the duct? What is required is = independent OAM in whatever the clinet layer is and all the server = layers. =20 regards, Neil >=20 > Stewart >=20 >=20 > Mick Seaman wrote: >=20 > > There seems to be an undercurrent in this discussion that=20 > somehow an FCS-32 > > is good protection against arbitrary packet mangling.=20 > Sorry, not true. > >=20 > > The FCS/CRC-32 is designed to protect against a limited=20 > number of changes in > > bits, and was designed against a noise error model that=20 > rated changes in > > more than a certain number of bits improbable. You can't=20 > reliably use the > > CRC to defend against a wider range of errors such as omission or > > replacement of whole bytes or words (which has been know to=20 > sporadically > > occur in DMA controllers designed close to their limits),=20 > or substitution of > > part of the frame for another frame (which might occur if=20 > frames were > > interleaved on a synchronous clock and the clock slipped a=20 > bit position once > > in a while for example). Nor does the FCS protect well=20 > against software > > errors where a relay system does something other than it is=20 > supposed to do > > when forwarding a frame. > >=20 > > The protection offered by a CRC-32 against such events is=20 > little better than > > the chance of randomly guessing the right number in 2**32.=20 > To put that in > > perspective if all frames on a fully utilised 10 Gb/s link=20 > were errored you > > would get a frame with a good FCS about once every 20=20 > minutes. Of course if > > all the frames were errored the link would probably come=20 > down, but spread > > around a network or many the errored 10Gb/s aggregate is=20 > more plausible. Now > > if you factor out all the errors that are going to get=20 > caught with the exact > > same CRC algorithm used on a link by link basis then the=20 > extra CRC is pretty > > much a waste of 4 bytes. At least use a different integrity=20 > check if you are > > serious! (and not one that the existing hardware is not going to > > accidentally emulate by accident when there is a software bug!). > >=20 > > This discussion seems to be largely driven by philosophy,=20 > if it is going to > > go anywhere at all there better be an engineering component. > >=20 > > Separately you are not going to get bit level transparency=20 > for a bridged > > network. In particular we have already established the=20 > layering model will > > not be broken to allow media specific frames (PAUSE, LACP)=20 > etc. to transit > > though bridges. > >=20 > > Mick > >=20 > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of=20 > Scott Kotrla > > Sent: Monday, November 24, 2003 9:40 AM > > To: neil.2.harrison@bt.com; nfinn@cisco.com > > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >=20 > >=20 > >=20 > > As a service provider, I want layers. I want to be as a=20 > transparent as > > possible. Throwing away the customer's FCS and introducing the > > possibility of undetected errors is not transparent. VLAN stacking > > isn't the best solution here for layer encapsulation, but=20 > it can work. > > MAC-in-MAC is architecturally a better fit because the=20 > whole customer > > frame goes into the new payload field, but wasting 12 bytes=20 > for dummy > > DA/SA that won't be used for TRANS (MEF layer) applications=20 > doesn't make > > a lot of sense. ETH layer functionality is the application=20 > of existing > > 802 technologies to service providers, so arguments about=20 > what exactly > > does or does not belong has value. > >=20 > > TRANS layer functionality for physical Ethernet transport is new > > functionality that 802 was not designed for. But for=20 > service providers, > > this provides new requirements. The TRANS layer often refers to > > transport over SONET, but there is no reason why it shouldn't also > > support the model of transport over Ethernet, in which case the > > requirements are different from ETH requirements. If=20 > physical Ethernet > > is being used for point-to-point TRANS functionality, new=20 > features like > > a Path FCS are required. Otherwise, Ethernet over Fiber is=20 > not a viable > > alternative to Ethernet over SONET. > >=20 > > In this context, it may be clearer how Stacked VLANs and PW are > > comparable. As a provider, I am looking for a way to=20 > tunnel customer > > ports or customer VLANs from point-to-point from end-to-end > > transparently across the access network. I am open to other > > alternatives. Ethernet TRANS should maintain customer FCS=20 > end-to-end as > > a separate layer from the service Ethernet Link FCS. > >=20 > > As some background, what started MCI's quest for FCS=20 > retention was a lab > > infrastructure Ethernet switch that was corrupting packets and > > calculating a new FCS on packets where no changes should have been > > occurring. This was one of the top Ethernet switch vendors=20 > as provided > > by Gartner in 2002. This took days to troubleshoot, and as service > > providers, scared the Hell out of us. The idea of VLAN=20 > stacking, VLAN > > swapping, marking as discard eligible, and messing with packets in > > general seems to open up the possibility of such things=20 > happening even > > more. > >=20 > > Thanks, > >=20 > > Scott > >=20 > > -----Original Message----- > > From: owner-stds-802-1@majordomo.ieee.org > > [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of > > neil.2.harrison@bt.com > > Sent: Friday, November 21, 2003 11:16 AM > > To: nfinn@cisco.com > > Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >=20 > >=20 > > Hi Norm....We are on the same page I am sure, just using different > > words....please see in-line. > >=20 > > regards, Neil > >=20 > >=20 > >>Norman Finn wrote 21 November 2003 12:03 > >> > >> > >>Neil, > >> > >>I think Pat Thaler's reply helps to straighten out this > >>confusion, but let me > >>try, also. > >> > >>There is a *lot* of confusion about the words "end-to-end", > >>and about "transport layers". > >=20 > > NH=3D> Agreed. G.805 and G.809 func arch really helps sort=20 > this out...as > > I hope was clear this week from Maarten's excellent analysis of the > > ethernet OAM issues at SG13. > >=20 > >=20 > >>There are lots of ends in this picture, and there are layers > >>and there are layers. > >=20 > > NH=3D> Agreed.....just wish some more people grokked this stuff as = it > > should help mitigate arch violates. > >=20 > >>An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > >>bridge, does NOT supply a > >>"transport layer" in the same sense as IP-over-Ethernet or > >>Ethernet-over-IP. This is > >>because, at the data forwarding layers, VLAN tags are best > >>though of as extensions to > >>the address space, not as additional protocol layers. > >=20 > > NH=3D> Understood and agree. > >=20 > >=20 > >> If you > >>want to call it a > >>"transport layer", feel free! > >=20 > > NH=3D> No, that would be completely wrong....VLANs do *not*=20 > form a layer > > network in any way, shape or form. > >=20 > >=20 > >> But don't assume that VLANs > >>are equivalent to other > >>"transport layers". Data integrity, specifically, is > >>different in bridges. > >> > >>Routers provide "best effort" not only in frame delivery, but > >>in data integrity. There > >>is no upper limit specified for the probability of delivery > >>of a packet with undetected > >>errors. IP's response, if you demand a particular level of > >>data integrity, is that > >>your application must supply its own checksum. > >> > >>Bridges, however, are not routers! > >> > >>Bridges *do* guarantee a level of service. They manage to do > >>this by guaranteeing the > >>quality of each bridge, and by *demanding* the quality of > >>each link. Non-VLAN bridges, > >>VLAN bridges, and Provider Bridges all make that guarantee to > >>their users using this > >>method. The Customers of a Provider Bridge service are not > >>an "802.1Q application" > >>over an "802.1ad transport layer". They are, in the 802.1 > >>model, just endstations > >>attached to a bridge. The Customers' data is just as well > >>protected as an enterprise > >>bridges' endstations, as long as the model is maintained. > >>Adding an additional CRC > >>to end-to-end service, where the ends are Customers attached > >>to 802.1ad Provider > >>Bridges, is therefore pointless. Changing that model is as > >>silly as turning the model > >>for routing upside down. > >=20 > > NH=3D> I agree with all this....so not quite sure what you=20 > think I am not > > understanding here. > >=20 > >>When a Pseudowire is used to connect two bridges, > >=20 > > NH=3D> Similar to VLANs, a PW is *not* a layer network=20 > either. MPLS does > > create layer networks however....but I suspect that is not well > > understood by many. One of my colleagues, who like Maarten=20 > is a real > > expert in the func modelling detail, is formally describing=20 > MPLS right > > now...but of course MPLS is a not a singular layer network,=20 > it has many > > flavours and this work will clearly bring out the different arch > > behaviours. > >=20 > >=20 > >>the > >>"end-to-end" is now just those > >>two bridges. > >=20 > > NH=3D> Agreed. If one drew out the proper func arch model one can = see > > this immediately. > >=20 > >=20 > >>Those bridges are using that PW as an Ethernet > >>to carry their traffic. > >>The bridges demand that every wire be as reliable as an > >>Ethernet. That's the PW CRC > >>issue. > >=20 > > NH=3D> Grokked totally. A PW is a form of adaptation function=20 > that lies > > between a client (here we are discussing ethernet) and MPLS=20 > (or IP if > > one is happy with a cnls server behaviour)...and then there=20 > are further > > layer networks below this, eg the VC4 layer network of SDH,=20 > until we hit > > the duct. The fact that a PW is not a layer network and not really > > necessary is neither here nor there....other than its just something > > else to manage. When the port on a bridge is not connected to an > > 'ethernet shared media' (orginal case), but some technology=20 > (any) then > > one simply has to adapt the ethernet PDU (*including its=20 > FCS*, as its > > part of the client ethernet CI) to the payload of the=20 > server layer. One > > should *not* be playing around with client layer network=20 > structures in a > > simple client->server adaptation process at all. So I am totally > > against all the 'Martini' PW compression stuff....the BW=20 > squeezing is > > simply not worth it (compared to other technolgies that=20 > will squander > > BW). So ! > > IMO the ethernet FCS is part of the ethernet's CI and should not be > > removed by *any* server layer technology. > >=20 > >>-- Norm > >> > >>neil.2.harrison@bt.com wrote: > >> > >>>Norm....As per our discussion today face-face. I don't > >> > >>really see what the problem is here. The client layer > >>network should not care about the server layer network (and > >>vice versa)....we need this layer independence for lots of > >>reasons. An ethernet traffic unit has a FCS. This should > >>simply be transported transparently in the payload area of > >>whatever the server layer is....and the server layer should > >>use its own (OAM) 'integrity mechanisms' irrespective of the > >>client. Problems arise when people start doing things like > >>client layer compression and thus forming inter-layer dependencies. > >> > >>>Further, as we agreed today and as I posted on an earlier > >> > >>mail to this thread, the ethernet FCS is a CRC that can be > >>linerarly updated for adaptation function changes (eg VLAN ID > >>change) on each link-connection (as provided by some server > >>layer trail technology) whilst preserving its end-end > >>intergrity check of the rest of the ethernet traffic unit > >>between its trail termination points. > >> > >>>regards, Neil > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Norman Finn [mailto:nfinn@cisco.com] > >>>>Sent: 18 November 2003 08:56 > >>>>To: mark seery > >>>>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>>>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >>>> > >>>> > >>>>Mark, > >>>> > >>>>You say below, > >>>> > >>>> > >>>>>but a PW will be running over a physical media itself > >>>> > >>>>already, possibly > >>>> > >>>>>even SONET............. > >>>> > >>>>Exactly! Here, the trail gets a bit murky. If I'm in total > >>>>control, and the PW > >>>>is running over known Ethernet links, then I can get away > >>>>without the CRC in the > >>>>PW. I have no problem whatsoever with the current definition > >>>>of PWs without CRC. > >>>> > >>>>But, if I don't have tight control over the physical media > >>>>over which the PW runs, > >>>>then I really need a CRC on the PW for the bridge to be able > >>>>to trust the "wire" > >>>>and thus provide the same level of data integrity that > >>>>bridges offer over physical > >>>>Ethernets. So, I claim that bridges need a CRC option on PWs. > >>>> > >>>>-- Norm > >>>> > >>>>mark seery wrote: > >>>> > >>>> > >>>>>Norman Finn wrote: > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>>In other words, routers pass about $0.93 of the data > >>>>> > >>>>integrity buck to > >>>> > >>>> > >>>>>>bridges, > >>>>>>and bridges pass about $0.75 of that to the data links. > >>>>> > >>>>The buck has > >>>> > >>>> > >>>>>>to stop > >>>>>>somewhere, and the data link is where it stops. The PW > >>>>> > >>>>has to take > >>>> > >>>> > >>>>>>the same > >>>>>>hit as the physical media. > >>>>>> > >>>>>>-- Norm > >>>>> > >>>>> > >>>>>but a PW will be running over a physical media itself > >>>> > >>>>already, possibly > >>>> > >>>> > >>>>>even SONET............. > >>>>> > >>>>>mark > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>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 > >> > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > pwe3 mailing list > > pwe3@ietf.org > > https://www1.ietf.org/mailman/listinfo/pwe3 > >=20 > >=20 >=20 >=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: "David Allan" Subject: RE: FCS retention in PWE3 Date: Tue, 25 Nov 2003 10:08:14 -0500 Lines: 374 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B365.F0EF1EDC" Cc: erosen@cisco.com, "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 16:10:09 2003 Return-path: To: "'stbryant@cisco.com'" , Scott Kotrla 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_01C3B365.F0EF1EDC Content-Type: text/plain; charset="iso-8859-1" Stewart: I think there is an aspect of your assertions that I am missing. CE to CE OAM tools are not in control of the provider and IMO the provider asking the customer to diagnose the service is a non-starter. PE to PE OAM tools have incomplete coverage in the PE and as the whole ECMP discussion highlights, is not payload and therefore may not be subject to exactly the same transfer functions. PW OAM tools are typically single hop at the PW level so IMO are rather limited in utility. Key delta here is detection vs. diagnosis. FCS offers detection, and if done right can also provide a useful degree of fault isolation (via ingress and egress checking). It is not clear to me that an OAM protocol helps the detection aspects in any useful timeframe if the nature of the problem is inherently masked. I also am not grokking the reference to the use of crypto esp. in the context of diagnosis once we've assumed a problem exists.... What we are really discussing is the economics of service integrity, a.k.a. is the problem sufficently rare that only diagnosis is required, and therefore it can be punted into reactive OAM tools and we can save that 1/8th sq. inch of silicon in the forwarding plane. Personally I think there is a lot of value in a service that works, and self identifies when it is broken. Ruthless optimization of the forwarding plane on the assumption that it just works really complicates life when it doesn't work.... cheers Dave > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: Tuesday, November 25, 2003 5:47 AM > To: Scott Kotrla > Cc: erosen@cisco.com; 'mark seery'; pwe3@ietf.org > Subject: Re: [PWE3] FCS retention in PWE3 > > > > A question that I have raised before, and called up in my > applicability statement notes is whether VCCV (or similar) > allows us to diagnose the problem more accurately. > > VCCV run between the PEs will allow the SP to audit the PW's > path over the PSN. The only element not covered is the > circuit between the CE and the PE, and the different internal > data path between the VCCV generator/receiver and the PE-PSN > interface. If the customer also runs an OAM protocol, they > can audit from CE to CE and validate the whole SP PW path. > > Unlike the FCS approach the OAM could be signed with a > decent crypto and would not be fooled by short error bursts. > > If FCS is the right tool for the path audit we should use it, > but I am not convinced that it will do better than a purpose > designed OAM protocol. > > Stewart > > > Scott Kotrla wrote: > > > Why couldn't the corruption be occurring in the customer's > network? > > How are the provider and customer supposed to figure out > whose fault > > it is with certainty? Because all of the links are > checksummed, the > > error had to have occurred inside a device. But there is NO way to > > isolate whether it was a provider device or a customer > device. There > > are likely more customer devices in the path than carrier > devices, so > > it would seem more likely to be a customer problem. > > > > Is it not clear that this is a huge nightmare for a service > provider > > who deploys this in a large scale? I just don't get how > people cannot > > see how this could be useful in some SP networks. The blanket > > statement that it would NEVER be useful and shouldn't be an > OPTION is > > absurd. > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of > > Eric Rosen > > Sent: Monday, November 24, 2003 1:27 PM > > To: mark seery > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] FCS retention in PWE3 > > > > Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- > > > > Mark> wouldn't ports "b" and "c" be able to detect FCS errors > > Mark> before > > they > > Mark> entered the customers network, and at least provide an > > Mark> indication > > that > > Mark> the problem is in the operators network and not the > > customers, > > Mark> therefore narrowing down the problem of diagnosing TCP > > checksum > > Mark> errors? > > > > I don't think so. Presumably the frame is > ethernet-checksummed from > > its > > source to the ingress PE, and then is ethernet-checksummed again > > from the > > egress PE to its destination. The only place > where it is > > not > > ethernet-checksummed is in the SP network. So if the frame > actually > > arrives at the destination host with a bad TCP checksum, > chances seem > > high that the > > problem was in the operator's network. > > > > > > _______________________________________________ > > 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 > ------_=_NextPart_001_01C3B365.F0EF1EDC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PWE3] FCS retention in PWE3

Stewart:

I think there is an aspect of your assertions that I = am missing. CE to CE OAM tools are not in control of the provider and = IMO the provider asking the customer to diagnose the service is a = non-starter. PE to PE OAM tools have incomplete coverage in the PE and = as the whole ECMP discussion highlights, is not payload and therefore = may not be subject to exactly the same transfer functions. PW OAM tools = are typically single hop at the PW level so IMO are rather limited in = utility.

Key delta here is detection vs. diagnosis. FCS offers = detection, and if done right can also provide a useful degree of fault = isolation (via ingress and egress checking). It is not clear to me that = an OAM protocol helps the detection aspects in any useful timeframe if = the nature of the problem is inherently masked. I also am not grokking = the reference to the use of crypto esp. in the context of diagnosis = once we've assumed a problem exists....

What we are really discussing is the economics of = service integrity, a.k.a. is the problem sufficently rare that only = diagnosis is required, and therefore it can be punted into reactive OAM = tools and we can save that 1/8th sq. inch of silicon in the forwarding = plane. Personally I think there is a lot of value in a service that = works, and self identifies when it is broken. Ruthless optimization of = the forwarding plane on the assumption that it just works really = complicates life when it doesn't work....

cheers
Dave



> -----Original Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com] =
> Sent: Tuesday, November 25, 2003 5:47 AM
> To: Scott Kotrla
> Cc: erosen@cisco.com; 'mark seery'; = pwe3@ietf.org
> Subject: Re: [PWE3] FCS retention in = PWE3
>
>
>
> A question that I have raised before, and = called up in my
> applicability statement notes is whether VCCV = (or similar)
> allows us to diagnose the problem more = accurately.
>
> VCCV run between the PEs will allow the SP to = audit the PW's
> path over the PSN. The only element not covered = is the
> circuit between the CE and the PE, and the = different internal
> data path between the VCCV generator/receiver = and the PE-PSN
> interface. If the customer also runs an OAM = protocol, they
> can audit from CE to CE and validate the whole = SP PW path.
>
> Unlike the FCS approach the OAM could be signed = with a
> decent crypto and would not be fooled by short = error bursts.
>
> If FCS is the right tool for the path audit we = should use it,
> but I am not convinced that it will do better = than a purpose
> designed OAM protocol.
>
> Stewart
>
>
> Scott Kotrla wrote:
>
> > Why couldn't the corruption be occurring = in the customer's
> network? 
> > How are the provider and customer supposed = to figure out
> whose fault
> > it is with certainty?  Because all of = the links are
> checksummed, the
> > error had to have occurred inside a = device. But there is NO way to
> > isolate whether it was a provider device = or a customer
> device.  There
> > are likely more customer devices in the = path than carrier
> devices, so
> > it would seem more likely to be a customer = problem.
> >
> > Is it not clear that this is a huge = nightmare for a service
> provider
> > who deploys this in a large scale?  I = just don't get how
> people cannot
> > see how this could be useful in some SP = networks.  The blanket
> > statement that it would NEVER be useful = and shouldn't be an
> OPTION is
> > absurd.
> >
> > -----Original Message-----
> > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On = Behalf Of
> > Eric Rosen
> > Sent: Monday, November 24, 2003 1:27 = PM
> > To: mark seery
> > Cc: pwe3@ietf.org
> > Subject: Re: [PWE3] FCS retention in = PWE3
> >
> > Mark> = --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|--
> >
> > Mark> wouldn't ports  = "b" and "c" be  able to detect FCS  = errors
> > Mark> before
> > they
> > Mark> entered the customers network, = and at least provide an
> > Mark> indication
> > that
> > Mark> the  problem  is = in  the  operators  network  and not  = the
> > customers,
> > Mark> therefore  narrowing  = down  the  problem of  diagnosing  TCP
> > checksum
> > Mark> errors?
> >
> > I don't  think so.   = Presumably the frame  is
> ethernet-checksummed  from
> > its
> > source to  the ingress PE, and  = then is ethernet-checksummed  again
> > from the
> > egress  PE   to  = its   destination.   The  only   = place 
> where  it   is
> > not
> > ethernet-checksummed is in the SP = network.  So if the frame
> actually
> > arrives at the destination host with a = ; bad TCP checksum,
> chances seem
> > high that the
> > problem was in the operator's network. =
> >
> >
> > = _______________________________________________
> > 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=
>

------_=_NextPart_001_01C3B365.F0EF1EDC-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Eric Rosen Subject: Re: FCS retention in PWE3 Date: Tue, 25 Nov 2003 10:33:42 -0500 Lines: 30 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: "'stbryant@cisco.com'" , Scott Kotrla , "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 16:35:03 2003 Return-path: To: "David Allan" In-reply-to: Your message of Tue, 25 Nov 2003 10:08:14 -0500. 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 > FCS offers detection I don't really see any basis for this statement. If what we are trying to detect is a malfunctioning switch, then we need to consider the various ways in which a switch may malfunction before we can state that FCS enables us to detect the malfunctions. For instance, a switch may malfunction by discarding frames entirely, or perhaps by intermittently discarding bursts of frames. FCS would not detect this sort of malfunction. Given the way switches work, this is a more likely malfunction than overwriting the frame data. In the particular case of PW, a switch may malfunction by incorrectly manipulating the PSN header during transit. This is a much more likely malfunction than overwriting the frame data. Carrying the customer's FCS to the remote edge won't detect this at all. FCS may be good for detecting burst errors on a transmission medium, but I see no reason to believe that it has a high probability of detecting errors that might be caused by malfunctioning switches. > CE to CE OAM tools are not in control of the provider and IMO the provider > asking the customer to diagnose the service is a non-starter. I agree with this, but note that with the usual ethernet switching equipment it would be the egress CE that would detect any FCS failure that is caused by problems in the provider network. So any specification of an option for carrying the customer's FCS should REQUIRE that the egress PE validate the FCS. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Scott Kotrla Subject: RE: FCS retention in PWE3 Date: Tue, 25 Nov 2003 10:35:43 -0600 Lines: 74 Sender: pwe3-admin@ietf.org References: <200311251533.hAPFXhxg014556@rtp-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stbryant@cisco.com, "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 17:42:09 2003 Return-path: In-reply-to: <200311251533.hAPFXhxg014556@rtp-core-1.cisco.com> To: erosen@cisco.com, "'David Allan'" X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 no problems requiring that optional FCS retention implementations do an egress FCS check. I would much rather have a dropped frame than a corrupt frame that looks valid. Customers that aren't receiving frames will know that they have a problem in the provider network. Customers that are receiving a bunch of frames that appear to be valid will not know that they are having a problem with their service. -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of Eric Rosen Sent: Tuesday, November 25, 2003 9:34 AM To: David Allan Cc: 'stbryant@cisco.com'; Scott Kotrla; 'mark seery'; pwe3@ietf.org Subject: Re: [PWE3] FCS retention in PWE3 > FCS offers detection I don't really see any basis for this statement. If what we are trying to detect is a malfunctioning switch, then we need to consider the various ways in which a switch may malfunction before we can state that FCS enables us to detect the malfunctions. For instance, a switch may malfunction by discarding frames entirely, or perhaps by intermittently discarding bursts of frames. FCS would not detect this sort of malfunction. Given the way switches work, this is a more likely malfunction than overwriting the frame data. In the particular case of PW, a switch may malfunction by incorrectly manipulating the PSN header during transit. This is a much more likely malfunction than overwriting the frame data. Carrying the customer's FCS to the remote edge won't detect this at all. FCS may be good for detecting burst errors on a transmission medium, but I see no reason to believe that it has a high probability of detecting errors that might be caused by malfunctioning switches. > CE to CE OAM tools are not in control of the provider and IMO the provider > asking the customer to diagnose the service is a non-starter. I agree with this, but note that with the usual ethernet switching equipment it would be the egress CE that would detect any FCS failure that is caused by problems in the provider network. So any specification of an option for carrying the customer's FCS should REQUIRE that the egress PE validate the FCS. _______________________________________________ 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 Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 10:35:43 -0600 Lines: 390 Sender: pwe3-admin@ietf.org References: <000401c3b2c6$5019e950$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 25 17:43:50 2003 Return-path: In-reply-to: <000401c3b2c6$5019e950$210110ac@corp.telseon.com> To: mick_seaman@ieee.org, stds-802-1@ieee.org, pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 So are you suggesting because a CRC-32 will miss 1 in 4 billion frames it is not useful to know? I don't need to catch every frame to know there is a problem. The standard Ethernet CRC protects the link and not the internal switch, and it is very difficult to put requirements on the internal working of a switch. As stated in a previous message: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." I am not worried about link errors. I am worried about corruption within switches. If switches have unknown failure modes that add unknown corruption, what besides a Path FCS will be able to determine that there is a problem. Once again, detection is at least 10 times as important as diagnosis. If we can come up with a better way to detect when (not if) switches are corrupting packets, I would be very interested in understanding the benefits of this approach. The service provider requirement can be succinctly stated as: The network shall be able to detect when (not if) switches are corrupting packets. Suggesting that switches will never unknowingly corrupt packets is wishing the problem away and is not an acceptable answer. Never is a very long time. Besides, out of the 100 or so switches I have worked with, I have already seen it happen. And I am not all that lucky. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Monday, November 24, 2003 2:05 PM To: stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention There seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: FCS retention in PWE3 Date: Tue, 25 Nov 2003 12:19:30 -0500 Organization: Cisco Systems, inc. Lines: 567 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C3B34E.64A4AA80" Cc: , "'mark seery'" , X-From: pwe3-admin@ietf.org Tue Nov 25 18:21:17 2003 Return-path: To: "'David Allan'" , , "'Scott Kotrla'" 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 Importance: Normal 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 This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C3B34E.64A4AA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit -----Original Message----- From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of David Allan Sent: Tuesday, November 25, 2003 10:08 AM To: 'stbryant@cisco.com'; Scott Kotrla Cc: erosen@cisco.com; 'mark seery'; pwe3@ietf.org Subject: RE: [PWE3] FCS retention in PWE3 > Stewart: >I think there is an aspect of your assertions that I am missing. CE to CE OAM tools are not in control >of the provider and IMO the provider asking the customer to diagnose the service is a non-starter. It is my understanding that at least several providers today have mechanisms that they provide to customers that allow them to test the PE-CE link from the PE if they suspect there is a problem (or check the link's status from the PE side), so I am not sure it is not such a "non-starter" as you characterize it. For example, in the L3 VPN case, I have seen end-customers (i.e.: those that buy the L3 VPN service) simply ping (using ICMP IP) betweeen the CEs to test connectivity and/or verify SLA on their own. When this fails, they can either call the provider or try the SPs web-based PE testing tool which might further isolate the problem using LSP ping and other things within the core, as well as to to ping the PE-CE. The only difference would be the inclusion of VCCV/LSP ping /trace on the core side. --Tom > PE to PE OAM tools have incomplete coverage in the PE and as the whole ECMP discussion highlights, is not payload and > therefore may not be subject to exactly the same transfer functions. PW OAM tools are typically single hop at the PW > level so IMO are rather limited in utility. >Key delta here is detection vs. diagnosis. FCS offers detection, and if done right can also provide a useful degree of fault isolation > (via ingress and egress checking). It is not clear to me that an OAM protocol helps the detection aspects in any useful timeframe > if the nature of the problem is inherently masked. I also am not grokking the reference to the use of crypto esp. in the context of > diagnosis once we've assumed a problem exists.... >What we are really discussing is the economics of service integrity, a.k.a. is the problem sufficently rare that only diagnosis is > required, and therefore it can be punted into reactive OAM tools and we can save that 1/8th sq. inch of silicon in the > forwarding plane. Personally I think there is a lot of value in a service that works, and self identifies when it is broken. > Ruthless optimization of the forwarding plane on the assumption that it just works really complicates life when it doesn't work.... >cheers >Dave > -----Original Message----- > From: Stewart Bryant [ mailto:stbryant@cisco.com] > Sent: Tuesday, November 25, 2003 5:47 AM > To: Scott Kotrla > Cc: erosen@cisco.com; 'mark seery'; pwe3@ietf.org > Subject: Re: [PWE3] FCS retention in PWE3 > > > > A question that I have raised before, and called up in my > applicability statement notes is whether VCCV (or similar) > allows us to diagnose the problem more accurately. > > VCCV run between the PEs will allow the SP to audit the PW's > path over the PSN. The only element not covered is the > circuit between the CE and the PE, and the different internal > data path between the VCCV generator/receiver and the PE-PSN > interface. If the customer also runs an OAM protocol, they > can audit from CE to CE and validate the whole SP PW path. > > Unlike the FCS approach the OAM could be signed with a > decent crypto and would not be fooled by short error bursts. > > If FCS is the right tool for the path audit we should use it, > but I am not convinced that it will do better than a purpose > designed OAM protocol. > > Stewart > > > Scott Kotrla wrote: > > > Why couldn't the corruption be occurring in the customer's > network? > > How are the provider and customer supposed to figure out > whose fault > > it is with certainty? Because all of the links are > checksummed, the > > error had to have occurred inside a device. But there is NO way to > > isolate whether it was a provider device or a customer > device. There > > are likely more customer devices in the path than carrier > devices, so > > it would seem more likely to be a customer problem. > > > > Is it not clear that this is a huge nightmare for a service > provider > > who deploys this in a large scale? I just don't get how > people cannot > > see how this could be useful in some SP networks. The blanket > > statement that it would NEVER be useful and shouldn't be an > OPTION is > > absurd. > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [ mailto:pwe3-admin@ietf.org] On Behalf Of > > Eric Rosen > > Sent: Monday, November 24, 2003 1:27 PM > > To: mark seery > > Cc: pwe3@ietf.org > > Subject: Re: [PWE3] FCS retention in PWE3 > > > > Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|-- > > > > Mark> wouldn't ports "b" and "c" be able to detect FCS errors > > Mark> before > > they > > Mark> entered the customers network, and at least provide an > > Mark> indication > > that > > Mark> the problem is in the operators network and not the > > customers, > > Mark> therefore narrowing down the problem of diagnosing TCP > > checksum > > Mark> errors? > > > > I don't think so. Presumably the frame is > ethernet-checksummed from > > its > > source to the ingress PE, and then is ethernet-checksummed again > > from the > > egress PE to its destination. The only place > where it is > > not > > ethernet-checksummed is in the SP network. So if the frame > actually > > arrives at the destination host with a bad TCP checksum, > chances seem > > high that the > > problem was in the operator's network. > > > > > > _______________________________________________ > > 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 > ------=_NextPart_000_005F_01C3B34E.64A4AA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On Behalf Of = David=20 Allan
Sent: Tuesday, November 25, 2003 10:08 AM
To:=20 'stbryant@cisco.com'; Scott Kotrla
Cc: erosen@cisco.com; 'mark = seery';=20 pwe3@ietf.org
Subject: RE: [PWE3] FCS retention in=20 PWE3

 > Stewart:<= /FONT>=20
 >I think there is an aspect = of your=20 assertions that I am missing. CE to CE OAM tools are not in = control  
 >of the provider and = IMO the=20 provider asking the customer to diagnose the service is a=20 non-starter.  
 
      It = is my=20 understanding that at least=20 several providers today
have mechanisms that = they provide to=20 customers that allow them
to test the PE-CE link = from the PE if=20 they suspect there is a
problem (or = check the=20 link's status from the PE side), so I=20
am not=20 sure it is not such a "non-starter" as you characterize = it. 
For example, in the L3 VPN = case, I have=20 seen
end-customers (i.e.: those that buy the = L3 VPN=20 service) simply ping  
 (using ICMP=20 IP) betweeen the = CEs =20 to test connectivity = and/or
verify SLA on = their=20 own. When this fails, they can either call the = provider=20 or  
 try the SPs=20 web-based PE testing tool  which=20 might further isolate the problem
 using LSP ping and other things within = the core,=20 as well as to to  ping the PE-CE.
The only difference would be the inclusion=20 of VCCV/LSP ping /trace=20 on the
core=20 side.
 
    --Tom 
 
 
 
 > PE to PE OAM = tools have=20 incomplete coverage in the PE and as the whole ECMP discussion = highlights, is=20 not payload and  
 > therefore may = not be=20 subject to exactly the same transfer functions. PW OAM tools are = typically=20 single hop at the PW  
 > level so IMO = are rather=20 limited in utility.
 >Key delta here is detection = vs.=20 diagnosis. FCS offers detection, and if done right can also provide a = useful=20 degree of fault isolation  
 > (via ingress = and egress=20 checking). It is not clear to me that an OAM protocol helps the = detection=20 aspects in any useful timeframe  
 > if the nature = of the=20 problem is inherently masked. I also am not grokking the reference to = the use of=20 crypto esp. in the context of  
 > diagnosis once = we've=20 assumed a problem=20 exists....
 >What we are really = discussing is the=20 economics of service integrity, a.k.a. is the problem sufficently rare = that only=20 diagnosis is  
 > required, and = therefore=20 it can be punted into reactive OAM tools and we can save that 1/8th sq. = inch of=20 silicon in the  
 > forwarding = plane.=20 Personally I think there is a lot of value in a service that works, and = self=20 identifies when it is broken.  
 > Ruthless = optimization of=20 the forwarding plane on the assumption that it just works really = complicates=20 life when it doesn't=20 work....
 >cheers 
 >Dave


 
> = -----Original=20 Message-----
> From: Stewart Bryant [mailto:stbryant@cisco.com]
>=20 Sent: Tuesday, November 25, 2003 5:47 AM
> To: Scott Kotrla =
> Cc:=20 erosen@cisco.com; 'mark seery'; pwe3@ietf.org
> Subject: Re: = [PWE3] FCS=20 retention in PWE3
>
>
>
> A question that I = have=20 raised before, and called up in my
> applicability statement = notes is=20 whether VCCV (or similar)
> allows us to diagnose the problem = more=20 accurately.
>
> VCCV run between the PEs will allow the SP = to=20 audit the PW's
> path over the PSN. The only element not covered = is the=20
> circuit between the CE and the PE, and the different internal =
>=20 data path between the VCCV generator/receiver and the PE-PSN
> = interface.=20 If the customer also runs an OAM protocol, they
> can audit from = CE to CE=20 and validate the whole SP PW path.
>
> Unlike the FCS = approach the=20 OAM could be signed with a
> decent crypto and would not be = fooled by=20 short error bursts.
>
> If FCS is the right tool for the = path=20 audit we should use it,
> but I am not convinced that it will do = better=20 than a purpose
> designed OAM protocol.
>
> Stewart =
>
>
> Scott Kotrla wrote:
>
> > = Why=20 couldn't the corruption be occurring in the customer's
> = network? =20
> > How are the provider and customer supposed to figure out =
>=20 whose fault
> > it is with certainty?  Because all of the = links=20 are
> checksummed, the
> > error had to have occurred = inside a=20 device. But there is NO way to
> > isolate whether it was a = provider=20 device or a customer
> device.  There
> > are = likely more=20 customer devices in the path than carrier
> devices, so
> = > it=20 would seem more likely to be a customer problem.
> >
> = > Is=20 it not clear that this is a huge nightmare for a service
> = provider=20
> > who deploys this in a large scale?  I just don't get = how=20
> people cannot
> > see how this could be useful in = some SP=20 networks.  The blanket
> > statement that it would NEVER = be=20 useful and shouldn't be an
> OPTION is
> > absurd. =
>=20 >
> > -----Original Message-----
> > From:=20 pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On=20 Behalf Of
> > Eric Rosen
> > Sent: Monday, November = 24, 2003=20 1:27 PM
> > To: mark seery
> > Cc: pwe3@ietf.org =
>=20 > Subject: Re: [PWE3] FCS retention in PWE3
> >
> = >=20 Mark> --|a-CE-b|--GbE--|PE|--PW--|PE|--GbE--|c-CE-d|--
> > =
>=20 > Mark> wouldn't ports  "b" and "c" be  able to detect = FCS =20 errors
> > Mark> before
> > they
> > = Mark>=20 entered the customers network, and at least provide an
> > = Mark>=20 indication
> > that
> > Mark> the  = problem  is=20 in  the  operators  network  and not  the =
> >=20 customers,
> > Mark> therefore  narrowing  = down =20 the  problem of  diagnosing  TCP
> > checksum =
>=20 > Mark> errors?
> >
> > I don't  think=20 so.   Presumably the frame  is
>=20 ethernet-checksummed  from
> > its
> > source = to =20 the ingress PE, and  then is ethernet-checksummed  again =
> >=20 from the
> > egress  PE   to  = its  =20 destination.   The  only   place 
> = where  it   is
> > not
> >=20 ethernet-checksummed is in the SP network.  So if the frame =
>=20 actually
> > arrives at the destination host with a  bad = TCP=20 checksum,
> chances seem
> > high that the
> = >=20 problem was in the operator's network.
> >
> > =
> >=20 _______________________________________________
> > pwe3 = mailing list=20
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >
> >=20 _______________________________________________
> > pwe3 = mailing list=20
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
> >
>
>
>=20 _______________________________________________
> pwe3 mailing = list=20
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
>
------=_NextPart_000_005F_01C3B34E.64A4AA80-- From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Luca Martini Subject: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 10:53:14 -0700 Organization: Cisco Systems Lines: 103 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 Tue Nov 25 18:54:06 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en To: pwe3@ietf.org X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 members, I have collected all the comments on the atm and ethernet encapsulation, drafts, as well as the control and maintenance protocol draft. Most are either spelling , punctuation, or english corrections which are not significant enought to spell out individually. But there is a minor text clarification below that does not change the technical design , but makes the reading easier. First , the title of the ATM draft does not fit: Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS Networks So has chaged to : Encapsulation Methods for Transport of ATM Over IP and MPLS Networks To fit in 72 columns. In the sequnce section: BEFORE: 4.3.4. Processing the sequence number field in the control word [snip] When a packet is received on that emulated VC, the sequence number should be processed as follows: - if the sequence number on the packet is 0, then the packet passes the sequence number check - otherwise if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order. - otherwise if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order. - otherwise the packet is out of order. If a packet passes the sequence number check, or is in order then, it can be delivered immediately. If the packet is in order, then the expected sequence number should be set using the algorithm: expected_sequence_number := packet_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number:= 1; Packets which are received out of order MAY be dropped or reordered at the discretion of the receiver. If a router PE2 does not support receive sequence number processing, then the sequence number field MAY be ignored. AFTER: 4.3.4. Processing the sequence number field in the control word [snip] When a packet is received on that emulated VC, the sequence number should be processed as follows: - if the sequence number on the packet is 0, then the packet passes the sequence number check. - otherwise if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order. - otherwise if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order. - otherwise the packet is out of order. If a packet is in order then, it can be delivered immediately. If the packet is in order, then the expected sequence number MUST be set using the algorithm: expected_sequence_number := packet_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number:= 1; Packets which are received out of order MAY be dropped or reordered at the discretion of the receiver. A simple extension of the above processing algorithm can be used to detect lost packets. If a router PE2 does not support receive sequence number processing, then the sequence number field MAY be ignored. This section is identical in the ethernet or atm draft, and should be identical in the frame-relay draft as well. Also Stewart, Yakov Stein and I discussed the concerns raised at the last ITU meeting , and concluded that this text is correct and needs no changes. Thanks. Luca Luca From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: mark seery Subject: Re: FCS retention in PWE3 Date: Tue, 25 Nov 2003 10:02:33 -0800 Lines: 57 Sender: pwe3-admin@ietf.org References: <005e01c3b378$4d7ab280$6701a8c0@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'David Allan'" , stbryant@cisco.com, "'Scott Kotrla'" , erosen@cisco.com, "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 19:11:18 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en To: tnadeau@cisco.com In-Reply-To: <005e01c3b378$4d7ab280$6701a8c0@amer.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 Thomas D. Nadeau wrote: > > -----Original Message----- > *From:* pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] *On Behalf Of > *David Allan > *Sent:* Tuesday, November 25, 2003 10:08 AM > *To:* 'stbryant@cisco.com'; Scott Kotrla > *Cc:* erosen@cisco.com; 'mark seery'; pwe3@ietf.org > *Subject:* RE: [PWE3] FCS retention in PWE3 > > > Stewart: > >I think there is an aspect of your assertions that I am missing. CE > to CE OAM tools are not in control > >of the provider and IMO the provider asking the customer to diagnose > the service is a non-starter. > > It is my understanding that at least several providers today > have mechanisms that they provide to customers that allow them > to test the PE-CE link from the PE if they suspect there is a > problem (or check the link's status from the PE side), so I > am not sure it is not such a "non-starter" as you characterize it. > For example, in the L3 VPN case, I have seen > end-customers (i.e.: those that buy the L3 VPN service) simply ping > (using ICMP IP) betweeen the CEs to test connectivity and/or > verify SLA on their own. When this fails, they can either call the > provider or > try the SPs web-based PE testing tool which might further isolate > the problem > using LSP ping and other things within the core, as well as > to to ping the PE-CE. > The only difference would be the inclusion of VCCV/LSP ping /trace on the > core side. > > --Tom Tom, I agree that is a useful diagnostic test. A few thoughts: -Service providers though need to know about a problem before their customer knows about it (or at least at the same time) -Intermittent problems are often hard to pin down, so historical information is useful. -Historical information can also be used as trending data to catch a problem before it gets too serious. -Many L3 VPNs run over a TDM circuit that has a path check, Scott is trying to move to Ethernet/dark fiber where there is no such capability. -There is a certain dynamic that is created when there is a financial transaction between a provider and a customer. Finger-pointing is inevitable, and there are implications WRT SLAs and credits. Most of the U.S. ILECs do not offer SLAs on their fiber Ethernet services today - would be nice to get beyond that (even if this is just one piece of the puzzle). mark From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Wei Luo Subject: Re: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 10:10:39 -0800 Lines: 121 Sender: pwe3-admin@ietf.org References: <3FC3970A.1060504@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 Tue Nov 25 19:12:08 2003 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 In the control draft Section 5.4.2, the following sentence should be removed as it did in the latest draft-martini: "Note that receiving a Label Withdraw should not cause a corresponding Label Release to be sent." ---Wei Luca Martini wrote: > WG members, > > I have collected all the comments on the atm and ethernet > encapsulation, drafts, as well as the control and maintenance protocol > draft. > Most are either spelling , punctuation, or english corrections which are > not significant enought to spell out individually. > But there is a minor text clarification below that does not change the > technical design , but makes the reading easier. > > First , the title of the ATM draft does not fit: > > Encapsulation Methods for Transport of ATM Cells/Frame Over IP and MPLS > Networks > So has chaged to : > Encapsulation Methods for Transport of ATM Over IP and MPLS Networks > > To fit in 72 columns. > > In the sequnce section: > > BEFORE: > 4.3.4. Processing the sequence number field in the control word > [snip] > When a packet is received on that emulated VC, the sequence number > should be processed as follows: > > - if the sequence number on the packet is 0, then the packet passes > the sequence number check > > - otherwise if the packet sequence number >= the expected sequence > number and the packet sequence number - the expected sequence > number < 32768, then the packet is in order. > > - otherwise if the packet sequence number < the expected sequence > number and the expected sequence number - the packet sequence > number >= 32768, then the packet is in order. > > - otherwise the packet is out of order. > > If a packet passes the sequence number check, or is in order then, it > can be delivered immediately. If the packet is in order, then the > expected sequence number should be set using the algorithm: > > expected_sequence_number := packet_sequence_number + 1 mod 2**16 > if (expected_sequence_number = 0) then expected_sequence_number:= 1; > > Packets which are received out of order MAY be dropped or reordered > at the discretion of the receiver. > > If a router PE2 does not support receive sequence number processing, > then the sequence number field MAY be ignored. > > > AFTER: > > 4.3.4. Processing the sequence number field in the control word > [snip] > When a packet is received on that emulated VC, the sequence number > should be processed as follows: > > - if the sequence number on the packet is 0, then the packet passes > the sequence number check. > > - otherwise if the packet sequence number >= the expected sequence > number and the packet sequence number - the expected sequence > number < 32768, then the packet is in order. > > - otherwise if the packet sequence number < the expected sequence > number and the expected sequence number - the packet sequence > number >= 32768, then the packet is in order. > > - otherwise the packet is out of order. > > If a packet is in order then, it can be delivered immediately. If the > packet is in order, then the expected sequence number MUST be set > using the algorithm: > > expected_sequence_number := packet_sequence_number + 1 mod 2**16 > if (expected_sequence_number = 0) then expected_sequence_number:= 1; > > > Packets which are received out of order MAY be dropped or reordered > at the discretion of the receiver. > > A simple extension of the above processing algorithm can be used to > detect lost packets. > > If a router PE2 does not support receive sequence number processing, > then the sequence number field MAY be ignored. > > > This section is identical in the ethernet or atm draft, and should be > identical in the frame-relay draft as well. > Also Stewart, Yakov Stein and I discussed the concerns raised at the > last ITU meeting , and concluded that this text is correct and needs no > changes. > > Thanks. > Luca > > > 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: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 12:44:01 -0700 Organization: Cisco Systems Lines: 139 Sender: pwe3-admin@ietf.org References: <3FC3970A.1060504@cisco.com> <3FC39B1F.7080008@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 Tue Nov 25 20:45:06 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en To: Wei Luo In-Reply-To: <3FC39B1F.7080008@cisco.com> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 Yep, that was missed thanks. ( BTW the original intent of this sentence was to have the word "immediately " at the end of it, not to violate rfc 3036 ) Luca Wei Luo wrote: > In the control draft Section 5.4.2, the following sentence should be > removed as it did in the latest draft-martini: > > "Note that receiving a Label Withdraw should not cause a corresponding > Label Release to be sent." > > ---Wei > > Luca Martini wrote: > >> WG members, >> >> I have collected all the comments on the atm and ethernet >> encapsulation, drafts, as well as the control and maintenance >> protocol draft. >> Most are either spelling , punctuation, or english corrections which >> are not significant enought to spell out individually. >> But there is a minor text clarification below that does not change >> the technical design , but makes the reading easier. >> >> First , the title of the ATM draft does not fit: >> >> Encapsulation Methods for Transport of ATM Cells/Frame Over IP and >> MPLS Networks >> So has chaged to : >> Encapsulation Methods for Transport of ATM Over IP and MPLS Networks >> >> To fit in 72 columns. >> >> In the sequnce section: >> >> BEFORE: >> 4.3.4. Processing the sequence number field in the control word >> [snip] >> When a packet is received on that emulated VC, the sequence number >> should be processed as follows: >> >> - if the sequence number on the packet is 0, then the packet passes >> the sequence number check >> >> - otherwise if the packet sequence number >= the expected sequence >> number and the packet sequence number - the expected sequence >> number < 32768, then the packet is in order. >> >> - otherwise if the packet sequence number < the expected sequence >> number and the expected sequence number - the packet sequence >> number >= 32768, then the packet is in order. >> >> - otherwise the packet is out of order. >> >> If a packet passes the sequence number check, or is in order then, it >> can be delivered immediately. If the packet is in order, then the >> expected sequence number should be set using the algorithm: >> >> expected_sequence_number := packet_sequence_number + 1 mod 2**16 >> if (expected_sequence_number = 0) then expected_sequence_number:= 1; >> >> Packets which are received out of order MAY be dropped or reordered >> at the discretion of the receiver. >> >> If a router PE2 does not support receive sequence number processing, >> then the sequence number field MAY be ignored. >> >> >> AFTER: >> >> 4.3.4. Processing the sequence number field in the control word >> [snip] >> When a packet is received on that emulated VC, the sequence number >> should be processed as follows: >> >> - if the sequence number on the packet is 0, then the packet passes >> the sequence number check. >> >> - otherwise if the packet sequence number >= the expected sequence >> number and the packet sequence number - the expected sequence >> number < 32768, then the packet is in order. >> >> - otherwise if the packet sequence number < the expected sequence >> number and the expected sequence number - the packet sequence >> number >= 32768, then the packet is in order. >> >> - otherwise the packet is out of order. >> >> If a packet is in order then, it can be delivered immediately. If the >> packet is in order, then the expected sequence number MUST be set >> using the algorithm: >> >> expected_sequence_number := packet_sequence_number + 1 mod 2**16 >> if (expected_sequence_number = 0) then expected_sequence_number:= 1; >> >> >> Packets which are received out of order MAY be dropped or reordered >> at the discretion of the receiver. >> >> A simple extension of the above processing algorithm can be used to >> detect lost packets. >> >> If a router PE2 does not support receive sequence number processing, >> then the sequence number field MAY be ignored. >> >> >> This section is identical in the ethernet or atm draft, and should be >> identical in the frame-relay draft as well. >> Also Stewart, Yakov Stein and I discussed the concerns raised at the >> last ITU meeting , and concluded that this text is correct and needs >> no changes. >> >> Thanks. >> Luca >> >> >> 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: "Busschbach, Peter B (Peter)" Subject: RE: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 14:45:37 -0500 Lines: 148 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" X-From: pwe3-admin@ietf.org Tue Nov 25 20:47:02 2003 Return-path: To: "'Luca Martini'" , pwe3@ietf.org X-Mailer: Internet Mail Service (5.5.2656.59) 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, If you are changing the text related to sequence checks anyway, you may want to take the comment below into account. Peter > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Tuesday, November 25, 2003 12:53 PM > To: pwe3@ietf.org > Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections > > > WG members, > > I have collected all the comments on the atm and ethernet > encapsulation, drafts, as well as the control and maintenance > protocol > draft. > Most are either spelling , punctuation, or english > corrections which are > not significant enought to spell out individually. > But there is a minor text clarification below that does not > change the > technical design , but makes the reading easier. > > First , the title of the ATM draft does not fit: > > Encapsulation Methods for Transport of ATM Cells/Frame Over > IP and MPLS > Networks > So has chaged to : > Encapsulation Methods for Transport of ATM Over IP and MPLS Networks > > To fit in 72 columns. > > In the sequnce section: > > BEFORE: > 4.3.4. Processing the sequence number field in the control word > [snip] > When a packet is received on that emulated VC, the sequence number > should be processed as follows: > > - if the sequence number on the packet is 0, then the > packet passes > the sequence number check > > - otherwise if the packet sequence number >= the > expected sequence > number and the packet sequence number - the expected sequence > number < 32768, then the packet is in order. > > - otherwise if the packet sequence number < the expected sequence > number and the expected sequence number - the packet sequence > number >= 32768, then the packet is in order. > > - otherwise the packet is out of order. > > If a packet passes the sequence number check, or is in > order then, it > can be delivered immediately. If the packet is in order, then the > expected sequence number should be set using the algorithm: > > expected_sequence_number := packet_sequence_number + 1 mod 2**16 > if (expected_sequence_number = 0) then > expected_sequence_number:= 1; > > Packets which are received out of order MAY be dropped or reordered > at the discretion of the receiver. > > If a router PE2 does not support receive sequence number > processing, > then the sequence number field MAY be ignored. > > > AFTER: > > 4.3.4. Processing the sequence number field in the control word > [snip] > When a packet is received on that emulated VC, the sequence number > should be processed as follows: > > - if the sequence number on the packet is 0, then the > packet passes > the sequence number check. > > - otherwise if the packet sequence number >= the > expected sequence > number and the packet sequence number - the expected sequence > number < 32768, then the packet is in order. > > - otherwise if the packet sequence number < the expected sequence > number and the expected sequence number - the packet sequence > number >= 32768, then the packet is in order. > > - otherwise the packet is out of order. > > If a packet is in order then, it can be delivered > immediately. If the > packet is in order, then the expected sequence number MUST be set > using the algorithm: > > expected_sequence_number := packet_sequence_number + 1 mod 2**16 > if (expected_sequence_number = 0) then > expected_sequence_number:= 1; > > > Packets which are received out of order MAY be dropped or reordered > at the discretion of the receiver. There should be two different algorithms: one for the case in which misordered packets are dropped and one for the case in which reordering takes place. The algorithm specified in the draft applies to the case in which packets are dropped. Stating at the end that out-of-order packets may be reordered doesn't make sense. Look at the following case: suppose the expected sequence number is 3 and a packet arrives with packet sequence number 4. According to your algorithm, the packet is in order and is delivered immediately and the expected sequence number becomes 5. Now suppose a packet with packet sequence number 3 arrives. This packet is out of order. However, it can not be reordered, because its successor has already been forwarded. It can only be dropped. > > A simple extension of the above processing algorithm can be used to > detect lost packets. > > If a router PE2 does not support receive sequence number > processing, > then the sequence number field MAY be ignored. > > > This section is identical in the ethernet or atm draft, and should be > identical in the frame-relay draft as well. > Also Stewart, Yakov Stein and I discussed the concerns raised at the > last ITU meeting , and concluded that this text is correct > and needs no > changes. > > Thanks. > Luca > > > 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: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 11:53:37 -0800 Lines: 407 Sender: pwe3-admin@ietf.org References: <002601c3b372$2c06e980$338c23a6@acer4wc5zk5t43> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 25 20:49:04 2003 Return-path: To: "'Scott Kotrla'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002601c3b372$2c06e980$338c23a6@acer4wc5zk5t43> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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, If switches in deployment were corrupting packets at the rate you observed in your lab the millions of switch ports that have been deployed simply would not be there. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 25, 2003 8:36 AM To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention So are you suggesting because a CRC-32 will miss 1 in 4 billion frames it is not useful to know? I don't need to catch every frame to know there is a problem. The standard Ethernet CRC protects the link and not the internal switch, and it is very difficult to put requirements on the internal working of a switch. As stated in a previous message: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." I am not worried about link errors. I am worried about corruption within switches. If switches have unknown failure modes that add unknown corruption, what besides a Path FCS will be able to determine that there is a problem. Once again, detection is at least 10 times as important as diagnosis. If we can come up with a better way to detect when (not if) switches are corrupting packets, I would be very interested in understanding the benefits of this approach. The service provider requirement can be succinctly stated as: The network shall be able to detect when (not if) switches are corrupting packets. Suggesting that switches will never unknowingly corrupt packets is wishing the problem away and is not an acceptable answer. Never is a very long time. Besides, out of the 100 or so switches I have worked with, I have already seen it happen. And I am not all that lucky. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Monday, November 24, 2003 2:05 PM To: stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention There seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 12:01:14 -0800 Lines: 419 Sender: pwe3-admin@ietf.org References: <002601c3b372$2c06e980$338c23a6@acer4wc5zk5t43> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 25 20:57:09 2003 Return-path: To: "'Scott Kotrla'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <002601c3b372$2c06e980$338c23a6@acer4wc5zk5t43> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 If you are not concerned about protecting the customer but merely locating repetitively failed switch then OAM-like operations and test should be sufficient. It remains the case that placing exactly the same error check algorithm on the outer CRC as the inner does not extend your fault coverage for the customer much. Switch faults will still be capable of bringing the entire network to a halt and sending the wrong packets to the wrong customers. Anyone who buys a network service from a provider with poor internals on the grounds that the outer CRC will protect him is being simply naive. I'll go further than that, if a salesman tries to sell me a service with an outer CRC I will know that I can't trust the network and simply should not buy. Moreover as I have pointed out it is perfectly in the spirit of the 802.1 standards that the switch recalculate both the inner and the outer CRC, and indeed where the format of the frame delievered to the custoomer changes through the network it will have to recalculate both. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 25, 2003 8:36 AM To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention So are you suggesting because a CRC-32 will miss 1 in 4 billion frames it is not useful to know? I don't need to catch every frame to know there is a problem. The standard Ethernet CRC protects the link and not the internal switch, and it is very difficult to put requirements on the internal working of a switch. As stated in a previous message: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." I am not worried about link errors. I am worried about corruption within switches. If switches have unknown failure modes that add unknown corruption, what besides a Path FCS will be able to determine that there is a problem. Once again, detection is at least 10 times as important as diagnosis. If we can come up with a better way to detect when (not if) switches are corrupting packets, I would be very interested in understanding the benefits of this approach. The service provider requirement can be succinctly stated as: The network shall be able to detect when (not if) switches are corrupting packets. Suggesting that switches will never unknowingly corrupt packets is wishing the problem away and is not an acceptable answer. Never is a very long time. Besides, out of the 100 or so switches I have worked with, I have already seen it happen. And I am not all that lucky. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Monday, November 24, 2003 2:05 PM To: stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention There seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pwe3-fcs-retention-00.txt Date: Tue, 25 Nov 2003 15:26:16 -0500 Lines: 79 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 Nov 25 21:27:26 2003 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 Frame Check Sequence Retention Author(s) : A. Malis Filename : draft-ietf-pwe3-fcs-retention-00.txt Pages : 6 Date : 2003-11-25 This document defines a mechanism for preserving frame FCS through Ethernet, Frame Relay, and HDLC pseudowires. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-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-fcs-retention-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-fcs-retention-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: Scott Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 14:21:12 -0600 Lines: 458 Sender: pwe3-admin@ietf.org References: <000b01c3b38d$d2231120$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 25 21:29:21 2003 Return-path: In-reply-to: <000b01c3b38d$d2231120$210110ac@corp.telseon.com> To: mick_seaman@ieee.org, stds-802-1@ieee.org, pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 Mick, So is your argument that I found the one switch that corrupts packets and MCI will never encounter another one? Or is your argument that the number of switches that MCI finds and the time spent troubleshooting those switches is not worth the amount of work needed to add an option to the standard? This problem is so difficult to diagnose without the right tools that switches would just be swapped out as "bad." If you can't diagnose, you simply start replacing switches until the network works, and if it is not your business to care, you don't worry about why things aren't working. These types of failures vary by implementation. An equipment provider that is having problems like this will fix it in future products. But this doesn't help the service provider who already has the switches in his network. If an equipment provider had these kinds of problems, do you think it would make them well known? So there are two options to dealing with the service provider requirement below. Either you say it is not a valid requirement or you propose solutions to fix it. I believe it is a valid requirement and I have proposed an end-to-end FCS that is never recalculated as a solution. I am open to discussing either the requirement or proposed solutions. Detailed analyses of how likely or unlikely this event is to happen across equipment from 100s of vendors is likely to be very difficult if not impossible. I find it very amusing that this simple topic of having an option to support service provider requirements could prompt such a heated and religious discussion. If only I had more time to put into this. I would love to find switches from all of the top equipment vendors that exhibited this behavior. Would that be enough to convince people that this is a valid concern? What exactly would it take to get this requirement to be seriously considered? Thanks, Scott -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Tuesday, November 25, 2003 1:54 PM To: 'Scott Kotrla'; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Scott, If switches in deployment were corrupting packets at the rate you observed in your lab the millions of switch ports that have been deployed simply would not be there. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 25, 2003 8:36 AM To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention So are you suggesting because a CRC-32 will miss 1 in 4 billion frames it is not useful to know? I don't need to catch every frame to know there is a problem. The standard Ethernet CRC protects the link and not the internal switch, and it is very difficult to put requirements on the internal working of a switch. As stated in a previous message: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." I am not worried about link errors. I am worried about corruption within switches. If switches have unknown failure modes that add unknown corruption, what besides a Path FCS will be able to determine that there is a problem. Once again, detection is at least 10 times as important as diagnosis. If we can come up with a better way to detect when (not if) switches are corrupting packets, I would be very interested in understanding the benefits of this approach. The service provider requirement can be succinctly stated as: The network shall be able to detect when (not if) switches are corrupting packets. Suggesting that switches will never unknowingly corrupt packets is wishing the problem away and is not an acceptable answer. Never is a very long time. Besides, out of the 100 or so switches I have worked with, I have already seen it happen. And I am not all that lucky. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Monday, November 24, 2003 2:05 PM To: stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention There seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: "Mick Seaman" Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 12:41:51 -0800 Lines: 488 Sender: pwe3-admin@ietf.org References: <000e01c3b391$abac4710$338c23a6@acer4wc5zk5t43> Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 25 21:38:09 2003 Return-path: To: "'Scott Kotrla'" , , X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000e01c3b391$abac4710$338c23a6@acer4wc5zk5t43> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal 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 Lets just consider the part of my argument that says that fault analysis tools should be designed to achieve a given coverage over a set of faults and not just comprise a random borrowed idea with extremely poor coverage but potentially large implementation consequence and costs to all. Again, if the existing CRC mechanisms do not adequately protect the packet the bridged network will fall apart. The bridges have to be designed so that they are adequate. Reasoning by analogy with SONET just doesn't cut it. By the way, I don't think that any service provider that doesn't exhaustively test and running a thorough commissioning process, either through their own labs or by vendor support backed by financial guarantees, on vendor equipment deserves to stay in business. Since you find the topic of adding options to standards amusing while to others of us standardisation and the engineering that supports it is a serious and time consuming activity I can only give up this thread of conversation. Mick -----Original Message----- From: Scott Kotrla [mailto:scott.kotrla@mci.com] Sent: Tuesday, November 25, 2003 12:21 PM To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Mick, So is your argument that I found the one switch that corrupts packets and MCI will never encounter another one? Or is your argument that the number of switches that MCI finds and the time spent troubleshooting those switches is not worth the amount of work needed to add an option to the standard? This problem is so difficult to diagnose without the right tools that switches would just be swapped out as "bad." If you can't diagnose, you simply start replacing switches until the network works, and if it is not your business to care, you don't worry about why things aren't working. These types of failures vary by implementation. An equipment provider that is having problems like this will fix it in future products. But this doesn't help the service provider who already has the switches in his network. If an equipment provider had these kinds of problems, do you think it would make them well known? So there are two options to dealing with the service provider requirement below. Either you say it is not a valid requirement or you propose solutions to fix it. I believe it is a valid requirement and I have proposed an end-to-end FCS that is never recalculated as a solution. I am open to discussing either the requirement or proposed solutions. Detailed analyses of how likely or unlikely this event is to happen across equipment from 100s of vendors is likely to be very difficult if not impossible. I find it very amusing that this simple topic of having an option to support service provider requirements could prompt such a heated and religious discussion. If only I had more time to put into this. I would love to find switches from all of the top equipment vendors that exhibited this behavior. Would that be enough to convince people that this is a valid concern? What exactly would it take to get this requirement to be seriously considered? Thanks, Scott -----Original Message----- From: Mick Seaman [mailto:mick_seaman@ieee.org] Sent: Tuesday, November 25, 2003 1:54 PM To: 'Scott Kotrla'; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Scott, If switches in deployment were corrupting packets at the rate you observed in your lab the millions of switch ports that have been deployed simply would not be there. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 25, 2003 8:36 AM To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention So are you suggesting because a CRC-32 will miss 1 in 4 billion frames it is not useful to know? I don't need to catch every frame to know there is a problem. The standard Ethernet CRC protects the link and not the internal switch, and it is very difficult to put requirements on the internal working of a switch. As stated in a previous message: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." I am not worried about link errors. I am worried about corruption within switches. If switches have unknown failure modes that add unknown corruption, what besides a Path FCS will be able to determine that there is a problem. Once again, detection is at least 10 times as important as diagnosis. If we can come up with a better way to detect when (not if) switches are corrupting packets, I would be very interested in understanding the benefits of this approach. The service provider requirement can be succinctly stated as: The network shall be able to detect when (not if) switches are corrupting packets. Suggesting that switches will never unknowingly corrupt packets is wishing the problem away and is not an acceptable answer. Never is a very long time. Besides, out of the 100 or so switches I have worked with, I have already seen it happen. And I am not all that lucky. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Monday, November 24, 2003 2:05 PM To: stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention There seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: Scott Kotrla Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 14:55:37 -0600 Lines: 468 Sender: pwe3-admin@ietf.org References: <000c01c3b38e$e2d53f60$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-From: pwe3-admin@ietf.org Tue Nov 25 21:57:11 2003 Return-path: In-reply-to: <000c01c3b38e$e2d53f60$210110ac@corp.telseon.com> To: mick_seaman@ieee.org, stds-802-1@ieee.org, pwe3@ietf.org X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 would not sell the customer a two FCS service. I would use the second FCS for fault detection. Most customers would have no clue this is going on. The second FCS protects against undetected internal switch malfunctions. How likely this increases fault detection is directly related to how likely switches are to unknowingly corrupt packets. I am still not exactly clear on your argument. Are you saying that the second FCS is extremely unlikely to catch an undetected internal switch error, or are you saying that undetected internal switch errors are extremely unlikely? I'm expecting the path of least resistance here. While it is possible to build boxes that purposefully try to break the rules, I wouldn't expect this to be the norm, since it would be more difficult, especially for switches in the middle which aren't expected to act on or be aware of the internal customer VLAN/FCS. In a MEF TRANS function, the customer Ethernet frame (including Customer VLAN tag) will never change. All changes will occur to the Service Tag, which is why a Service FCS cannot be relied upon for end-to-end error detection. If switches can do whatever they want internally, I'd say that trying to enforce a more complex incremental CRC32 calculation will be less enforceable than dual FCS. I have to admit, assuming everything will always work the way it is supposed to would make my life a lot simpler. If a customer calls and says service is not working, we'll just say that our network is not capable of malfunctioning and leave it at that. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Tuesday, November 25, 2003 2:01 PM To: 'Scott Kotrla'; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention If you are not concerned about protecting the customer but merely locating repetitively failed switch then OAM-like operations and test should be sufficient. It remains the case that placing exactly the same error check algorithm on the outer CRC as the inner does not extend your fault coverage for the customer much. Switch faults will still be capable of bringing the entire network to a halt and sending the wrong packets to the wrong customers. Anyone who buys a network service from a provider with poor internals on the grounds that the outer CRC will protect him is being simply naive. I'll go further than that, if a salesman tries to sell me a service with an outer CRC I will know that I can't trust the network and simply should not buy. Moreover as I have pointed out it is perfectly in the spirit of the 802.1 standards that the switch recalculate both the inner and the outer CRC, and indeed where the format of the frame delievered to the custoomer changes through the network it will have to recalculate both. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Tuesday, November 25, 2003 8:36 AM To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention So are you suggesting because a CRC-32 will miss 1 in 4 billion frames it is not useful to know? I don't need to catch every frame to know there is a problem. The standard Ethernet CRC protects the link and not the internal switch, and it is very difficult to put requirements on the internal working of a switch. As stated in a previous message: "The model of operation is simply a basis for describing the functionality of the MAC Bridge. It is in no way intended to constrain real implementations of a MAC Bridge; these may adopt any internal model of operation compatible with the externally visible behavior that this standard specifies. Conformance of equipment to this standard is purely in respect of observable protocol." I am not worried about link errors. I am worried about corruption within switches. If switches have unknown failure modes that add unknown corruption, what besides a Path FCS will be able to determine that there is a problem. Once again, detection is at least 10 times as important as diagnosis. If we can come up with a better way to detect when (not if) switches are corrupting packets, I would be very interested in understanding the benefits of this approach. The service provider requirement can be succinctly stated as: The network shall be able to detect when (not if) switches are corrupting packets. Suggesting that switches will never unknowingly corrupt packets is wishing the problem away and is not an acceptable answer. Never is a very long time. Besides, out of the 100 or so switches I have worked with, I have already seen it happen. And I am not all that lucky. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of Mick Seaman Sent: Monday, November 24, 2003 2:05 PM To: stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention There seems to be an undercurrent in this discussion that somehow an FCS-32 is good protection against arbitrary packet mangling. Sorry, not true. The FCS/CRC-32 is designed to protect against a limited number of changes in bits, and was designed against a noise error model that rated changes in more than a certain number of bits improbable. You can't reliably use the CRC to defend against a wider range of errors such as omission or replacement of whole bytes or words (which has been know to sporadically occur in DMA controllers designed close to their limits), or substitution of part of the frame for another frame (which might occur if frames were interleaved on a synchronous clock and the clock slipped a bit position once in a while for example). Nor does the FCS protect well against software errors where a relay system does something other than it is supposed to do when forwarding a frame. The protection offered by a CRC-32 against such events is little better than the chance of randomly guessing the right number in 2**32. To put that in perspective if all frames on a fully utilised 10 Gb/s link were errored you would get a frame with a good FCS about once every 20 minutes. Of course if all the frames were errored the link would probably come down, but spread around a network or many the errored 10Gb/s aggregate is more plausible. Now if you factor out all the errors that are going to get caught with the exact same CRC algorithm used on a link by link basis then the extra CRC is pretty much a waste of 4 bytes. At least use a different integrity check if you are serious! (and not one that the existing hardware is not going to accidentally emulate by accident when there is a software bug!). This discussion seems to be largely driven by philosophy, if it is going to go anywhere at all there better be an engineering component. Separately you are not going to get bit level transparency for a bridged network. In particular we have already established the layering model will not be broken to allow media specific frames (PAUSE, LACP) etc. to transit though bridges. Mick -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla Sent: Monday, November 24, 2003 9:40 AM To: neil.2.harrison@bt.com; nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention As a service provider, I want layers. I want to be as a transparent as possible. Throwing away the customer's FCS and introducing the possibility of undetected errors is not transparent. VLAN stacking isn't the best solution here for layer encapsulation, but it can work. MAC-in-MAC is architecturally a better fit because the whole customer frame goes into the new payload field, but wasting 12 bytes for dummy DA/SA that won't be used for TRANS (MEF layer) applications doesn't make a lot of sense. ETH layer functionality is the application of existing 802 technologies to service providers, so arguments about what exactly does or does not belong has value. TRANS layer functionality for physical Ethernet transport is new functionality that 802 was not designed for. But for service providers, this provides new requirements. The TRANS layer often refers to transport over SONET, but there is no reason why it shouldn't also support the model of transport over Ethernet, in which case the requirements are different from ETH requirements. If physical Ethernet is being used for point-to-point TRANS functionality, new features like a Path FCS are required. Otherwise, Ethernet over Fiber is not a viable alternative to Ethernet over SONET. In this context, it may be clearer how Stacked VLANs and PW are comparable. As a provider, I am looking for a way to tunnel customer ports or customer VLANs from point-to-point from end-to-end transparently across the access network. I am open to other alternatives. Ethernet TRANS should maintain customer FCS end-to-end as a separate layer from the service Ethernet Link FCS. As some background, what started MCI's quest for FCS retention was a lab infrastructure Ethernet switch that was corrupting packets and calculating a new FCS on packets where no changes should have been occurring. This was one of the top Ethernet switch vendors as provided by Gartner in 2002. This took days to troubleshoot, and as service providers, scared the Hell out of us. The idea of VLAN stacking, VLAN swapping, marking as discard eligible, and messing with packets in general seems to open up the possibility of such things happening even more. Thanks, Scott -----Original Message----- From: owner-stds-802-1@majordomo.ieee.org [mailto:owner-stds-802-1@majordomo.ieee.org] On Behalf Of neil.2.harrison@bt.com Sent: Friday, November 21, 2003 11:16 AM To: nfinn@cisco.com Cc: mark@interflect.com; stds-802-1@ieee.org; pwe3@ietf.org Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Norm....We are on the same page I am sure, just using different words....please see in-line. regards, Neil > Norman Finn wrote 21 November 2003 12:03 > > > Neil, > > I think Pat Thaler's reply helps to straighten out this > confusion, but let me > try, also. > > There is a *lot* of confusion about the words "end-to-end", > and about "transport layers". NH=> Agreed. G.805 and G.809 func arch really helps sort this out...as I hope was clear this week from Maarten's excellent analysis of the ethernet OAM issues at SG13. > There are lots of ends in this picture, and there are layers > and there are layers. NH=> Agreed.....just wish some more people grokked this stuff as it should help mitigate arch violates. > > An 802.1Q VLAN bridge, and by extension, a P802.1ad provider > bridge, does NOT supply a > "transport layer" in the same sense as IP-over-Ethernet or > Ethernet-over-IP. This is > because, at the data forwarding layers, VLAN tags are best > though of as extensions to > the address space, not as additional protocol layers. NH=> Understood and agree. > If you > want to call it a > "transport layer", feel free! NH=> No, that would be completely wrong....VLANs do *not* form a layer network in any way, shape or form. > But don't assume that VLANs > are equivalent to other > "transport layers". Data integrity, specifically, is > different in bridges. > > Routers provide "best effort" not only in frame delivery, but > in data integrity. There > is no upper limit specified for the probability of delivery > of a packet with undetected > errors. IP's response, if you demand a particular level of > data integrity, is that > your application must supply its own checksum. > > Bridges, however, are not routers! > > Bridges *do* guarantee a level of service. They manage to do > this by guaranteeing the > quality of each bridge, and by *demanding* the quality of > each link. Non-VLAN bridges, > VLAN bridges, and Provider Bridges all make that guarantee to > their users using this > method. The Customers of a Provider Bridge service are not > an "802.1Q application" > over an "802.1ad transport layer". They are, in the 802.1 > model, just endstations > attached to a bridge. The Customers' data is just as well > protected as an enterprise > bridges' endstations, as long as the model is maintained. > Adding an additional CRC > to end-to-end service, where the ends are Customers attached > to 802.1ad Provider > Bridges, is therefore pointless. Changing that model is as > silly as turning the model > for routing upside down. NH=> I agree with all this....so not quite sure what you think I am not understanding here. > > When a Pseudowire is used to connect two bridges, NH=> Similar to VLANs, a PW is *not* a layer network either. MPLS does create layer networks however....but I suspect that is not well understood by many. One of my colleagues, who like Maarten is a real expert in the func modelling detail, is formally describing MPLS right now...but of course MPLS is a not a singular layer network, it has many flavours and this work will clearly bring out the different arch behaviours. > the > "end-to-end" is now just those > two bridges. NH=> Agreed. If one drew out the proper func arch model one can see this immediately. > Those bridges are using that PW as an Ethernet > to carry their traffic. > The bridges demand that every wire be as reliable as an > Ethernet. That's the PW CRC > issue. NH=> Grokked totally. A PW is a form of adaptation function that lies between a client (here we are discussing ethernet) and MPLS (or IP if one is happy with a cnls server behaviour)...and then there are further layer networks below this, eg the VC4 layer network of SDH, until we hit the duct. The fact that a PW is not a layer network and not really necessary is neither here nor there....other than its just something else to manage. When the port on a bridge is not connected to an 'ethernet shared media' (orginal case), but some technology (any) then one simply has to adapt the ethernet PDU (*including its FCS*, as its part of the client ethernet CI) to the payload of the server layer. One should *not* be playing around with client layer network structures in a simple client->server adaptation process at all. So I am totally against all the 'Martini' PW compression stuff....the BW squeezing is simply not worth it (compared to other technolgies that will squander BW). So ! IMO the ethernet FCS is part of the ethernet's CI and should not be removed by *any* server layer technology. > > -- Norm > > neil.2.harrison@bt.com wrote: > > Norm....As per our discussion today face-face. I don't > really see what the problem is here. The client layer > network should not care about the server layer network (and > vice versa)....we need this layer independence for lots of > reasons. An ethernet traffic unit has a FCS. This should > simply be transported transparently in the payload area of > whatever the server layer is....and the server layer should > use its own (OAM) 'integrity mechanisms' irrespective of the > client. Problems arise when people start doing things like > client layer compression and thus forming inter-layer dependencies. > > > > Further, as we agreed today and as I posted on an earlier > mail to this thread, the ethernet FCS is a CRC that can be > linerarly updated for adaptation function changes (eg VLAN ID > change) on each link-connection (as provided by some server > layer trail technology) whilst preserving its end-end > intergrity check of the rest of the ethernet traffic unit > between its trail termination points. > > > > regards, Neil > > > > > >>-----Original Message----- > >>From: Norman Finn [mailto:nfinn@cisco.com] > >>Sent: 18 November 2003 08:56 > >>To: mark seery > >>Cc: stds-802-1@ieee.org; pwe3@ietf.org > >>Subject: Re: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > >> > >> > >>Mark, > >> > >>You say below, > >> > >> > but a PW will be running over a physical media itself > >>already, possibly > >> > even SONET............. > >> > >>Exactly! Here, the trail gets a bit murky. If I'm in total > >>control, and the PW > >>is running over known Ethernet links, then I can get away > >>without the CRC in the > >>PW. I have no problem whatsoever with the current definition > >>of PWs without CRC. > >> > >>But, if I don't have tight control over the physical media > >>over which the PW runs, > >>then I really need a CRC on the PW for the bridge to be able > >>to trust the "wire" > >>and thus provide the same level of data integrity that > >>bridges offer over physical > >>Ethernets. So, I claim that bridges need a CRC option on PWs. > >> > >>-- Norm > >> > >>mark seery wrote: > >> > >>>Norman Finn wrote: > >>> > >>> > >>>> > >>>>In other words, routers pass about $0.93 of the data > >>> > >>integrity buck to > >> > >>>>bridges, > >>>>and bridges pass about $0.75 of that to the data links. > >>> > >>The buck has > >> > >>>>to stop > >>>>somewhere, and the data link is where it stops. The PW > >>> > >>has to take > >> > >>>>the same > >>>>hit as the physical media. > >>>> > >>>>-- Norm > >>> > >>> > >>>but a PW will be running over a physical media itself > >> > >>already, possibly > >> > >>>even SONET............. > >>> > >>>mark > >>> > >>> > >>> > >>> > >> > >> > >> > >>_______________________________________________ > >>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: Luca Martini Subject: Re: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 14:51:11 -0700 Organization: Cisco Systems Lines: 193 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: pwe3@ietf.org, Yaakov Stein , Stewart Bryant X-From: pwe3-admin@ietf.org Tue Nov 25 22:52:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en To: "Busschbach, Peter B (Peter)" In-Reply-To: X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 good point. So this could be fixed in the following way: If a packet is in order then, it can be delivered immediately. If the packet is in order, then the expected sequence number MUST be set using the algorithm: to If the packet is in order, then the expected sequence number MUST be set using the algorithm: after all it is implied that a packet should be delivered at some point. This would give implementations the ability to reorder the packet if needed. the other options are to remove the "packet can be reordered" text, or actually have 2 algorithms. I think the above text should be sufficient for inter-operability. Luca Busschbach, Peter B (Peter) wrote: >Luca, > >If you are changing the text related to sequence checks anyway, you may want to take the comment below into account. > >Peter > > > >>-----Original Message----- >>From: Luca Martini [mailto:lmartini@cisco.com] >>Sent: Tuesday, November 25, 2003 12:53 PM >>To: pwe3@ietf.org >>Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections >> >> >>WG members, >> >>I have collected all the comments on the atm and ethernet >>encapsulation, drafts, as well as the control and maintenance >>protocol >>draft. >>Most are either spelling , punctuation, or english >>corrections which are >>not significant enought to spell out individually. >>But there is a minor text clarification below that does not >>change the >>technical design , but makes the reading easier. >> >>First , the title of the ATM draft does not fit: >> >>Encapsulation Methods for Transport of ATM Cells/Frame Over >>IP and MPLS >>Networks >>So has chaged to : >>Encapsulation Methods for Transport of ATM Over IP and MPLS Networks >> >>To fit in 72 columns. >> >>In the sequnce section: >> >>BEFORE: >>4.3.4. Processing the sequence number field in the control word >>[snip] >>When a packet is received on that emulated VC, the sequence number >> should be processed as follows: >> >> - if the sequence number on the packet is 0, then the >>packet passes >> the sequence number check >> >> - otherwise if the packet sequence number >= the >>expected sequence >> number and the packet sequence number - the expected sequence >> number < 32768, then the packet is in order. >> >> - otherwise if the packet sequence number < the expected sequence >> number and the expected sequence number - the packet sequence >> number >= 32768, then the packet is in order. >> >> - otherwise the packet is out of order. >> >> If a packet passes the sequence number check, or is in >>order then, it >> can be delivered immediately. If the packet is in order, then the >> expected sequence number should be set using the algorithm: >> >> expected_sequence_number := packet_sequence_number + 1 mod 2**16 >> if (expected_sequence_number = 0) then >>expected_sequence_number:= 1; >> >> Packets which are received out of order MAY be dropped or reordered >> at the discretion of the receiver. >> >> If a router PE2 does not support receive sequence number >>processing, >> then the sequence number field MAY be ignored. >> >> >>AFTER: >> >>4.3.4. Processing the sequence number field in the control word >>[snip] >> When a packet is received on that emulated VC, the sequence number >> should be processed as follows: >> >> - if the sequence number on the packet is 0, then the >>packet passes >> the sequence number check. >> >> - otherwise if the packet sequence number >= the >>expected sequence >> number and the packet sequence number - the expected sequence >> number < 32768, then the packet is in order. >> >> - otherwise if the packet sequence number < the expected sequence >> number and the expected sequence number - the packet sequence >> number >= 32768, then the packet is in order. >> >> - otherwise the packet is out of order. >> >> If a packet is in order then, it can be delivered >>immediately. If the >> packet is in order, then the expected sequence number MUST be set >> using the algorithm: >> >> expected_sequence_number := packet_sequence_number + 1 mod 2**16 >> if (expected_sequence_number = 0) then >>expected_sequence_number:= 1; >> >> >> Packets which are received out of order MAY be dropped or reordered >> at the discretion of the receiver. >> >> > >There should be two different algorithms: one for the case in which misordered packets are dropped and one for the case in which reordering takes place. > >The algorithm specified in the draft applies to the case in which packets are dropped. Stating at the end that out-of-order packets may be reordered doesn't make sense. > >Look at the following case: suppose the expected sequence number is 3 and a packet arrives with packet sequence number 4. According to your algorithm, the packet is in order and is delivered immediately and the expected sequence number becomes 5. Now suppose a packet with packet sequence number 3 arrives. This packet is out of order. However, it can not be reordered, because its successor has already been forwarded. It can only be dropped. > > > >> A simple extension of the above processing algorithm can be used to >> detect lost packets. >> >> If a router PE2 does not support receive sequence number >>processing, >> then the sequence number field MAY be ignored. >> >> >>This section is identical in the ethernet or atm draft, and should be >>identical in the frame-relay draft as well. >>Also Stewart, Yakov Stein and I discussed the concerns raised at the >>last ITU meeting , and concluded that this text is correct >>and needs no >>changes. >> >>Thanks. >>Luca >> >> >>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: neil.2.harrison@bt.com Subject: RE: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 22:22:22 -0000 Lines: 248 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 Tue Nov 25 23:23:04 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] ATM/Ethernet/Control drafts minor corrections Thread-Index: AcOznm2Pp1qr46EISmuWh5inuADkpgAAqiNQ To: , X-OriginalArrivalTime: 25 Nov 2003 22:22:23.0625 (UTC) FILETIME=[99671790:01C3B3A2] 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 Luca/Peter, I have some related questions that ought to be relevant to = interworking....and, as an operator, I'd like to know what is being = proposed here anyway: - At what level and over what 'period' of pkt loss and/or misordering, = as determined from the sequence numbers, is the PW entity considered to = have failed? - And at that point what consequent actions are taken? - What is the criteria in terms of good pkt reception, as determined = from the sequence numbers, is the PW assumed to have come out of its = failure state? regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On=20 > Behalf Of Luca > Martini > Sent: 25 November 2003 21:51 > To: Busschbach, Peter B (Peter) > Cc: pwe3@ietf.org; Yaakov Stein; Stewart Bryant > Subject: Re: [PWE3] ATM/Ethernet/Control drafts minor corrections >=20 >=20 > good point. >=20 > So this could be fixed in the following way: >=20 > If a packet is in order then, it can be delivered immediately. If the > packet is in order, then the expected sequence number MUST be set > using the algorithm: >=20 > to >=20 > If the packet is in order, then the expected sequence number=20 > MUST be set > using the algorithm: >=20 >=20 > after all it is implied that a packet should be delivered at=20 > some point. >=20 > This would give implementations the ability to reorder the=20 > packet if needed. >=20 > the other options are to remove the "packet can be reordered"=20 > text, or actually have 2 algorithms. > I think the above text should be sufficient for inter-operability. >=20 >=20 > Luca >=20 >=20 >=20 >=20 >=20 > Busschbach, Peter B (Peter) wrote: >=20 > >Luca, > > > >If you are changing the text related to sequence checks=20 > anyway, you may want to take the comment below into account. > > > >Peter > > > > =20 > > > >>-----Original Message----- > >>From: Luca Martini [mailto:lmartini@cisco.com] > >>Sent: Tuesday, November 25, 2003 12:53 PM > >>To: pwe3@ietf.org > >>Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections > >> > >> > >>WG members, > >> > >>I have collected all the comments on the atm and ethernet =20 > >>encapsulation, drafts, as well as the control and maintenance=20 > >>protocol=20 > >>draft. > >>Most are either spelling , punctuation, or english=20 > >>corrections which are=20 > >>not significant enought to spell out individually. > >>But there is a minor text clarification below that does not=20 > >>change the=20 > >>technical design , but makes the reading easier. > >> > >>First , the title of the ATM draft does not fit: > >> > >>Encapsulation Methods for Transport of ATM Cells/Frame Over=20 > >>IP and MPLS=20 > >>Networks > >>So has chaged to : > >>Encapsulation Methods for Transport of ATM Over IP and MPLS Networks > >> > >>To fit in 72 columns. > >> > >>In the sequnce section: > >> > >>BEFORE: > >>4.3.4. Processing the sequence number field in the control word > >>[snip] > >>When a packet is received on that emulated VC, the sequence number > >> should be processed as follows: > >> > >> - if the sequence number on the packet is 0, then the=20 > >>packet passes > >> the sequence number check > >> > >> - otherwise if the packet sequence number >=3D the=20 > >>expected sequence > >> number and the packet sequence number - the expected sequence > >> number < 32768, then the packet is in order. > >> > >> - otherwise if the packet sequence number < the=20 > expected sequence > >> number and the expected sequence number - the packet sequence > >> number >=3D 32768, then the packet is in order. > >> > >> - otherwise the packet is out of order. > >> > >> If a packet passes the sequence number check, or is in=20 > >>order then, it > >> can be delivered immediately. If the packet is in order, then the > >> expected sequence number should be set using the algorithm: > >> > >> expected_sequence_number :=3D packet_sequence_number + 1 mod = 2**16 > >> if (expected_sequence_number =3D 0) then=20 > >>expected_sequence_number:=3D 1; > >> > >> Packets which are received out of order MAY be dropped=20 > or reordered > >> at the discretion of the receiver. > >> > >> If a router PE2 does not support receive sequence number=20 > >>processing, > >> then the sequence number field MAY be ignored. > >> > >> > >>AFTER: > >> > >>4.3.4. Processing the sequence number field in the control word > >>[snip] > >> When a packet is received on that emulated VC, the sequence number > >> should be processed as follows: > >> > >> - if the sequence number on the packet is 0, then the=20 > >>packet passes > >> the sequence number check. > >> > >> - otherwise if the packet sequence number >=3D the=20 > >>expected sequence > >> number and the packet sequence number - the expected sequence > >> number < 32768, then the packet is in order. > >> > >> - otherwise if the packet sequence number < the=20 > expected sequence > >> number and the expected sequence number - the packet sequence > >> number >=3D 32768, then the packet is in order. > >> > >> - otherwise the packet is out of order. > >> > >> If a packet is in order then, it can be delivered=20 > >>immediately. If the > >> packet is in order, then the expected sequence number MUST be set > >> using the algorithm: > >> =20 > >> expected_sequence_number :=3D packet_sequence_number + 1 mod = 2**16 > >> if (expected_sequence_number =3D 0) then=20 > >>expected_sequence_number:=3D 1; > >> > >> > >> Packets which are received out of order MAY be dropped=20 > or reordered > >> at the discretion of the receiver. > >> =20 > >> > > > >There should be two different algorithms: one for the case=20 > in which misordered packets are dropped and one for the case=20 > in which reordering takes place. > > > >The algorithm specified in the draft applies to the case in=20 > which packets are dropped. Stating at the end that=20 > out-of-order packets may be reordered doesn't make sense. > > > >Look at the following case: suppose the expected sequence=20 > number is 3 and a packet arrives with packet sequence number=20 > 4. According to your algorithm, the packet is in order and is=20 > delivered immediately and the expected sequence number=20 > becomes 5. Now suppose a packet with packet sequence number 3=20 > arrives. This packet is out of order. However, it can not be=20 > reordered, because its successor has already been forwarded.=20 > It can only be dropped. > > > > =20 > > > >> A simple extension of the above processing algorithm can=20 > be used to > >> detect lost packets. > >> > >> If a router PE2 does not support receive sequence number=20 > >>processing, > >> then the sequence number field MAY be ignored. > >> > >> > >>This section is identical in the ethernet or atm draft, and=20 > should be=20 > >>identical in the frame-relay draft as well. > >>Also Stewart, Yakov Stein and I discussed the concerns=20 > raised at the=20 > >>last ITU meeting , and concluded that this text is correct=20 > >>and needs no=20 > >>changes. > >> > >>Thanks. > >>Luca > >> > >> > >>Luca > >> > >> > >> > >> > >> > >>_______________________________________________ > >>pwe3 mailing list > >>pwe3@ietf.org > >>https://www1.ietf.org/mailman/listinfo/pwe3 > >> > >> =20 > >> > > > >_______________________________________________ > >pwe3 mailing list > >pwe3@ietf.org > >https://www1.ietf.org/mailman/listinfo/pwe3 > > > > =20 > > >=20 >=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: "David Allan" Subject: RE: FCS retention in PWE3 Date: Tue, 25 Nov 2003 17:30:31 -0500 Lines: 21 Sender: pwe3-admin@ietf.org Cc: erosen@cisco.com, "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 23:33:02 2003 Return-path: To: "'tnadeau@cisco.com'" , stbryant@cisco.com, "'Scott Kotrla'" 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 think there is an aspect of your assertions that I am missing. CE to CE OAM tools are not in control >of the provider and IMO the provider asking the customer to diagnose the service is a non-starter. It is my understanding that at least several providers today have mechanisms that they provide to customers that allow them to test the PE-CE link from the PE if they suspect there is a problem (or check the link's status from the PE side), so I am not sure it is not such a "non-starter" as you characterize it. This assumes that ping replicates the circumstances of the problem such that ping working is reasonably authoritative indication that the problem is not in the CE or the PE-CE link. cheers Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "David Allan" Subject: RE: FCS retention in PWE3 Date: Tue, 25 Nov 2003 17:32:16 -0500 Lines: 56 Sender: pwe3-admin@ietf.org Cc: "'stbryant@cisco.com'" , Scott Kotrla , "'mark seery'" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Tue Nov 25 23:35:11 2003 Return-path: To: "'erosen@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 Eric: Comments in line.. > > FCS offers detection > > I don't really see any basis for this statement. If what > we are trying to detect is a malfunctioning switch, then we > need to consider the various ways in which a switch may > malfunction before we can state that FCS enables us to detect > the malfunctions. FCS is not a universal panacea, however if a misbehaving switch is corrupting information and offering it up as good, it can be detected and will be detected as part of normal operations. > For instance, a switch may malfunction by discarding > frames entirely, or perhaps by intermittently discarding > bursts of frames. FCS would not detect this sort of > malfunction. Given the way switches work, this is a more > likely malfunction than overwriting the frame data. IMO mechanisms exist (e.g. sequence numbers, packet/octet counts) to find discard (which may also be a result of congestion). > > In the particular case of PW, a switch may malfunction > by incorrectly > manipulating the PSN header during transit. This is a > much more likely > malfunction than overwriting the frame data. Carrying the > customer's FCS to the remote edge won't detect this at all. No but that would manifest itself in other forms, such as sequencing problems etc. > FCS may be good for detecting burst errors on a > transmission medium, but I see no reason to believe that it > has a high probability of detecting errors that might be > caused by malfunctioning switches. > > > CE to CE OAM tools are not in control of the provider and IMO the > > provider asking the customer to diagnose the service is a > non-starter. > > I agree with this, but note that with the usual ethernet > switching equipment it would be the egress CE that would > detect any FCS failure that is caused > by problems in the provider network. So any specification > of an option for > carrying the customer's FCS should REQUIRE that the egress > PE validate the FCS. That certainly would be a BCP. Dave From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Busschbach, Peter B (Peter)" Subject: RE: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 18:04:14 -0500 Lines: 240 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain Cc: pwe3@ietf.org, Yaakov Stein , Stewart Bryant X-From: pwe3-admin@ietf.org Wed Nov 26 00:05:06 2003 Return-path: To: "'Luca Martini'" X-Mailer: Internet Mail Service (5.5.2656.59) 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, If I had to implement a reordering algorithm, I would make a distinction between two cases: - packet seq# = expected seq# - packet seq# > expected seq# In the second case, I would not increase the expected seq#, but just store the packet and set a flag to indicate that out-of-order packets are stored for transmission. In other words, I would not follow the text that you suggest below. However, I have not implemented a reordering algorithm and don't intend to do so. Is there any vendor who has? If we believe it is important to define exactly how reordering is done, I think we should start with existing implementations. Peter > -----Original Message----- > From: Luca Martini [mailto:lmartini@cisco.com] > Sent: Tuesday, November 25, 2003 4:51 PM > To: Busschbach, Peter B (Peter) > Cc: pwe3@ietf.org; Yaakov Stein; Stewart Bryant > Subject: Re: [PWE3] ATM/Ethernet/Control drafts minor corrections > > > good point. > > So this could be fixed in the following way: > > If a packet is in order then, it can be delivered immediately. If the > packet is in order, then the expected sequence number MUST be set > using the algorithm: > > to > > If the packet is in order, then the expected sequence number > MUST be set > using the algorithm: > > > after all it is implied that a packet should be delivered at > some point. > > This would give implementations the ability to reorder the > packet if needed. > > the other options are to remove the "packet can be reordered" > text, or actually have 2 algorithms. > I think the above text should be sufficient for inter-operability. > > > Luca > > > > > > Busschbach, Peter B (Peter) wrote: > > >Luca, > > > >If you are changing the text related to sequence checks > anyway, you may want to take the comment below into account. > > > >Peter > > > > > > > >>-----Original Message----- > >>From: Luca Martini [mailto:lmartini@cisco.com] > >>Sent: Tuesday, November 25, 2003 12:53 PM > >>To: pwe3@ietf.org > >>Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections > >> > >> > >>WG members, > >> > >>I have collected all the comments on the atm and ethernet > >>encapsulation, drafts, as well as the control and maintenance > >>protocol > >>draft. > >>Most are either spelling , punctuation, or english > >>corrections which are > >>not significant enought to spell out individually. > >>But there is a minor text clarification below that does not > >>change the > >>technical design , but makes the reading easier. > >> > >>First , the title of the ATM draft does not fit: > >> > >>Encapsulation Methods for Transport of ATM Cells/Frame Over > >>IP and MPLS > >>Networks > >>So has chaged to : > >>Encapsulation Methods for Transport of ATM Over IP and MPLS Networks > >> > >>To fit in 72 columns. > >> > >>In the sequnce section: > >> > >>BEFORE: > >>4.3.4. Processing the sequence number field in the control word > >>[snip] > >>When a packet is received on that emulated VC, the sequence number > >> should be processed as follows: > >> > >> - if the sequence number on the packet is 0, then the > >>packet passes > >> the sequence number check > >> > >> - otherwise if the packet sequence number >= the > >>expected sequence > >> number and the packet sequence number - the expected sequence > >> number < 32768, then the packet is in order. > >> > >> - otherwise if the packet sequence number < the > expected sequence > >> number and the expected sequence number - the packet sequence > >> number >= 32768, then the packet is in order. > >> > >> - otherwise the packet is out of order. > >> > >> If a packet passes the sequence number check, or is in > >>order then, it > >> can be delivered immediately. If the packet is in order, then the > >> expected sequence number should be set using the algorithm: > >> > >> expected_sequence_number := packet_sequence_number + 1 mod 2**16 > >> if (expected_sequence_number = 0) then > >>expected_sequence_number:= 1; > >> > >> Packets which are received out of order MAY be dropped > or reordered > >> at the discretion of the receiver. > >> > >> If a router PE2 does not support receive sequence number > >>processing, > >> then the sequence number field MAY be ignored. > >> > >> > >>AFTER: > >> > >>4.3.4. Processing the sequence number field in the control word > >>[snip] > >> When a packet is received on that emulated VC, the sequence number > >> should be processed as follows: > >> > >> - if the sequence number on the packet is 0, then the > >>packet passes > >> the sequence number check. > >> > >> - otherwise if the packet sequence number >= the > >>expected sequence > >> number and the packet sequence number - the expected sequence > >> number < 32768, then the packet is in order. > >> > >> - otherwise if the packet sequence number < the > expected sequence > >> number and the expected sequence number - the packet sequence > >> number >= 32768, then the packet is in order. > >> > >> - otherwise the packet is out of order. > >> > >> If a packet is in order then, it can be delivered > >>immediately. If the > >> packet is in order, then the expected sequence number MUST be set > >> using the algorithm: > >> > >> expected_sequence_number := packet_sequence_number + 1 mod 2**16 > >> if (expected_sequence_number = 0) then > >>expected_sequence_number:= 1; > >> > >> > >> Packets which are received out of order MAY be dropped > or reordered > >> at the discretion of the receiver. > >> > >> > > > >There should be two different algorithms: one for the case > in which misordered packets are dropped and one for the case > in which reordering takes place. > > > >The algorithm specified in the draft applies to the case in > which packets are dropped. Stating at the end that > out-of-order packets may be reordered doesn't make sense. > > > >Look at the following case: suppose the expected sequence > number is 3 and a packet arrives with packet sequence number > 4. According to your algorithm, the packet is in order and is > delivered immediately and the expected sequence number > becomes 5. Now suppose a packet with packet sequence number 3 > arrives. This packet is out of order. However, it can not be > reordered, because its successor has already been forwarded. > It can only be dropped. > > > > > > > >> A simple extension of the above processing algorithm can > be used to > >> detect lost packets. > >> > >> If a router PE2 does not support receive sequence number > >>processing, > >> then the sequence number field MAY be ignored. > >> > >> > >>This section is identical in the ethernet or atm draft, and > should be > >>identical in the frame-relay draft as well. > >>Also Stewart, Yakov Stein and I discussed the concerns > raised at the > >>last ITU meeting , and concluded that this text is correct > >>and needs no > >>changes. > >> > >>Thanks. > >>Luca > >> > >> > >>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: Luca Martini Subject: Re: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 16:08:22 -0700 Organization: Cisco Systems Lines: 323 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2EB7@i2km07-ukbr.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: busschbach@lucent.com, pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 26 00:10:04 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en To: neil.2.harrison@bt.com In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2EB7@i2km07-ukbr.domain1.systemhost.net> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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.2.harrison@bt.com wrote: >Luca/Peter, I have some related questions that ought to be relevant to interworking....and, as an operator, I'd like to know what is being proposed here anyway: >- At what level and over what 'period' of pkt loss and/or misordering, as determined from the sequence numbers, is the PW entity considered to have failed? > > This is an implementation specific detail , not part of the protocol. You should probably ask your router vendors how they handle this situation. ;-) I believe that the methods described in the VCCV draft are probably more appropriate to determine if there is packet loss on the PW path then using the sequence number. The sequence number is used to avoid delivering packets out of order. >- And at that point what consequent actions are taken? > > this is again an implementation specific detail. >- What is the criteria in terms of good pkt reception, as determined from the sequence numbers, is the PW assumed to have come out of its failure state? > > same as above. Luca >regards, Neil > > > >>-----Original Message----- >>From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On >>Behalf Of Luca >>Martini >>Sent: 25 November 2003 21:51 >>To: Busschbach, Peter B (Peter) >>Cc: pwe3@ietf.org; Yaakov Stein; Stewart Bryant >>Subject: Re: [PWE3] ATM/Ethernet/Control drafts minor corrections >> >> >>good point. >> >>So this could be fixed in the following way: >> >>If a packet is in order then, it can be delivered immediately. If the >>packet is in order, then the expected sequence number MUST be set >>using the algorithm: >> >>to >> >>If the packet is in order, then the expected sequence number >>MUST be set >>using the algorithm: >> >> >>after all it is implied that a packet should be delivered at >>some point. >> >>This would give implementations the ability to reorder the >>packet if needed. >> >>the other options are to remove the "packet can be reordered" >>text, or actually have 2 algorithms. >>I think the above text should be sufficient for inter-operability. >> >> >>Luca >> >> >> >> >> >>Busschbach, Peter B (Peter) wrote: >> >> >> >>>Luca, >>> >>>If you are changing the text related to sequence checks >>> >>> >>anyway, you may want to take the comment below into account. >> >> >>>Peter >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Luca Martini [mailto:lmartini@cisco.com] >>>>Sent: Tuesday, November 25, 2003 12:53 PM >>>>To: pwe3@ietf.org >>>>Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections >>>> >>>> >>>>WG members, >>>> >>>>I have collected all the comments on the atm and ethernet >>>>encapsulation, drafts, as well as the control and maintenance >>>>protocol >>>>draft. >>>>Most are either spelling , punctuation, or english >>>>corrections which are >>>>not significant enought to spell out individually. >>>>But there is a minor text clarification below that does not >>>>change the >>>>technical design , but makes the reading easier. >>>> >>>>First , the title of the ATM draft does not fit: >>>> >>>>Encapsulation Methods for Transport of ATM Cells/Frame Over >>>>IP and MPLS >>>>Networks >>>>So has chaged to : >>>>Encapsulation Methods for Transport of ATM Over IP and MPLS Networks >>>> >>>>To fit in 72 columns. >>>> >>>>In the sequnce section: >>>> >>>>BEFORE: >>>>4.3.4. Processing the sequence number field in the control word >>>>[snip] >>>>When a packet is received on that emulated VC, the sequence number >>>> should be processed as follows: >>>> >>>> - if the sequence number on the packet is 0, then the >>>>packet passes >>>> the sequence number check >>>> >>>> - otherwise if the packet sequence number >= the >>>>expected sequence >>>> number and the packet sequence number - the expected sequence >>>> number < 32768, then the packet is in order. >>>> >>>> - otherwise if the packet sequence number < the >>>> >>>> >>expected sequence >> >> >>>> number and the expected sequence number - the packet sequence >>>> number >= 32768, then the packet is in order. >>>> >>>> - otherwise the packet is out of order. >>>> >>>> If a packet passes the sequence number check, or is in >>>>order then, it >>>> can be delivered immediately. If the packet is in order, then the >>>> expected sequence number should be set using the algorithm: >>>> >>>> expected_sequence_number := packet_sequence_number + 1 mod 2**16 >>>> if (expected_sequence_number = 0) then >>>>expected_sequence_number:= 1; >>>> >>>> Packets which are received out of order MAY be dropped >>>> >>>> >>or reordered >> >> >>>> at the discretion of the receiver. >>>> >>>> If a router PE2 does not support receive sequence number >>>>processing, >>>> then the sequence number field MAY be ignored. >>>> >>>> >>>>AFTER: >>>> >>>>4.3.4. Processing the sequence number field in the control word >>>>[snip] >>>>When a packet is received on that emulated VC, the sequence number >>>> should be processed as follows: >>>> >>>> - if the sequence number on the packet is 0, then the >>>>packet passes >>>> the sequence number check. >>>> >>>> - otherwise if the packet sequence number >= the >>>>expected sequence >>>> number and the packet sequence number - the expected sequence >>>> number < 32768, then the packet is in order. >>>> >>>> - otherwise if the packet sequence number < the >>>> >>>> >>expected sequence >> >> >>>> number and the expected sequence number - the packet sequence >>>> number >= 32768, then the packet is in order. >>>> >>>> - otherwise the packet is out of order. >>>> >>>> If a packet is in order then, it can be delivered >>>>immediately. If the >>>> packet is in order, then the expected sequence number MUST be set >>>> using the algorithm: >>>> >>>> expected_sequence_number := packet_sequence_number + 1 mod 2**16 >>>> if (expected_sequence_number = 0) then >>>>expected_sequence_number:= 1; >>>> >>>> >>>> Packets which are received out of order MAY be dropped >>>> >>>> >>or reordered >> >> >>>> at the discretion of the receiver. >>>> >>>> >>>> >>>> >>>There should be two different algorithms: one for the case >>> >>> >>in which misordered packets are dropped and one for the case >>in which reordering takes place. >> >> >>>The algorithm specified in the draft applies to the case in >>> >>> >>which packets are dropped. Stating at the end that >>out-of-order packets may be reordered doesn't make sense. >> >> >>>Look at the following case: suppose the expected sequence >>> >>> >>number is 3 and a packet arrives with packet sequence number >>4. According to your algorithm, the packet is in order and is >>delivered immediately and the expected sequence number >>becomes 5. Now suppose a packet with packet sequence number 3 >>arrives. This packet is out of order. However, it can not be >>reordered, because its successor has already been forwarded. >>It can only be dropped. >> >> >>> >>> >>> >>> >>>> A simple extension of the above processing algorithm can >>>> >>>> >>be used to >> >> >>>> detect lost packets. >>>> >>>> If a router PE2 does not support receive sequence number >>>>processing, >>>> then the sequence number field MAY be ignored. >>>> >>>> >>>>This section is identical in the ethernet or atm draft, and >>>> >>>> >>should be >> >> >>>>identical in the frame-relay draft as well. >>>>Also Stewart, Yakov Stein and I discussed the concerns >>>> >>>> >>raised at the >> >> >>>>last ITU meeting , and concluded that this text is correct >>>>and needs no >>>>changes. >>>> >>>>Thanks. >>>>Luca >>>> >>>> >>>>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 >>> >>> >>> >>> >>> >>_______________________________________________ >>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: neil.2.harrison@bt.com Subject: RE: ATM/Ethernet/Control drafts minor corrections Date: Tue, 25 Nov 2003 23:37:01 -0000 Lines: 26 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 Nov 26 00:39:04 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] ATM/Ethernet/Control drafts minor corrections Thread-Index: AcOzqRiWc8v4f/EaRZe21ydMokpoKwAAjPRg To: X-OriginalArrivalTime: 25 Nov 2003 23:37:02.0742 (UTC) FILETIME=[072A1B60:01C3B3AD] 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 Thanks Luca. Please see below. regards, Neil Luca Martini wrote 25 November 2003 23:08 > > >- At what level and over what 'period' of pkt loss and/or=20 > misordering, as determined from the sequence numbers, is the=20 > PW entity considered to have failed? > > =20 > > > This is an implementation specific detail , not part of the protocol. NH=3D> This seems like a cop-out response to me. I don't see why we = can't have clarity on how the protocol handles this situation since as = an operator: (i) I want to be sure 2 different suppliers boxes interwork consistently = and (ii) the behaviour seen by clients is consistent/known; ...and as a potential customer (ie if I leased such a PW service): (iii) I would like to know what behaviour to expect. > You should probably ask your router vendors how they handle this=20 > situation. ;-) NH=3D> Ok, so I am asking you in your new job as you supply to BT....so = I'd be grateful if you could please respond off-list and in private = then. Thanks. From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: "Thomas D. Nadeau" Subject: RE: FCS retention in PWE3 Date: Tue, 25 Nov 2003 19:31:28 -0500 Organization: Cisco Systems, inc. Lines: 49 Sender: pwe3-admin@ietf.org References: Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: , "'mark seery'" , X-From: pwe3-admin@ietf.org Wed Nov 26 01:33:04 2003 Return-path: To: "'David Allan'" , , "'Scott Kotrla'" 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 Importance: Normal 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 >-----Original Message----- >From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On >Behalf Of David Allan >Sent: Tuesday, November 25, 2003 5:31 PM >To: 'tnadeau@cisco.com'; stbryant@cisco.com; 'Scott Kotrla' >Cc: erosen@cisco.com; 'mark seery'; pwe3@ietf.org >Subject: RE: [PWE3] FCS retention in PWE3 > > >Hi Tom: > > >I think there is an aspect of your assertions that I am >missing. CE to CE >OAM tools are not in control > >of the provider and IMO the provider asking the customer to >diagnose the >service is a non-starter. > > > It is my understanding that at least several providers today >have mechanisms that they provide to customers that allow them >to test the PE-CE link from the PE if they suspect there is a >problem (or check the link's status from the PE side), so I >am not sure it is not such a "non-starter" as you characterize it. > > >This assumes that ping replicates the circumstances of the >problem such that ping working is reasonably authoritative >indication that the problem is not in the CE or the PE-CE link. Well, for the real networks I am refering to, it seems to be an authoritative enough indication, so I don't see why it isn't in this case. :P --Tom >cheers >Dave > >_______________________________________________ >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: Ali Sajassi Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Tue, 25 Nov 2003 18:24:20 -0800 Lines: 103 Sender: pwe3-admin@ietf.org References: <002601c3b372$2c06e980$338c23a6@acer4wc5zk5t43> <000c01c3b38e$e2d53f60$210110ac@corp.telseon.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-From: pwe3-admin@ietf.org Wed Nov 26 03:26:08 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: , "'Scott Kotrla'" , , In-Reply-To: <000c01c3b38e$e2d53f60$210110ac@corp.telseon.com> References: <002601c3b372$2c06e980$338c23a6@acer4wc5zk5t43> 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 ask the question of service applicability for FCS retention some time ago and I didn't get a clear answer so let me ask again. When talking about FCS retention, which I of the following four Ethernet services do you have in mind ? 1) port-based point-to-point Ethernet service 2) vlan-based point-to-point Ethernet service 3) port-based Ethernet bridge service (multipoint) 4) vlan-based Ethernet bridge service (multipoint) In vlan-based service, the customer vlan is used as service delimiter and is NOT the same at the two ends of the service - e.g., just like frame relay or ATM where DLCI or VPI/VCI are not the same at two ends. Requiring that the VLANs be the same at the two ends, imposes unnecessary restriction in customer provisioning model. Therefore, FCS retention is not viable for applications where customer VLAN is used as service delimiter. Also any bridge service (port-based or vlan-based) doesn't require FCS retention by the definition of the bridge service itself. So, the only applicable service for this FCS retention stuff (and I doubt viability of it), is for port-based point-to-point service. However, I would like to ask the following question: How do you catch the errors introduced by the switches for the other services ??? Given that the same set of networking gears is to support all four Ethernet services, are you suggesting that we only need to solve the problem for a single service and not to worry about other service type !!! Or are you suggesting that you only offer a single service and thus you don't have to worry about other services !!! As I mentioned previously, a better approach is to solve the problem for all the Ethernet services - whether it is through OAM mechanisms or through internal switch check-sum or a combination of two or whatever. But the point is we should try to address the issue for ALL service types. -Ali At 12:01 PM 11/25/2003 -0800, Mick Seaman wrote: >If you are not concerned about protecting the customer but merely locating >repetitively failed switch then OAM-like operations and test should be >sufficient. It remains the case that placing exactly the same error check >algorithm on the outer CRC as the inner does not extend your fault coverage >for the customer much. Switch faults will still be capable of bringing the >entire network to a halt and sending the wrong packets to the wrong >customers. Anyone who buys a network service from a provider with poor >internals on the grounds that the outer CRC will protect him is being simply >naive. I'll go further than that, if a salesman tries to sell me a service >with an outer CRC I will know that I can't trust the network and simply >should not buy. > >Moreover as I have pointed out it is perfectly in the spirit of the 802.1 >standards that the switch recalculate both the inner and the outer CRC, and >indeed where the format of the frame delievered to the custoomer changes >through the network it will have to recalculate both. > >Mick > >-----Original Message----- >From: owner-stds-802-1@majordomo.ieee.org >[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla >Sent: Tuesday, November 25, 2003 8:36 AM >To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org >Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > >So are you suggesting because a CRC-32 will miss 1 in 4 billion frames >it is not useful to know? I don't need to catch every frame to know >there is a problem. > >The standard Ethernet CRC protects the link and not the internal switch, >and it is very difficult to put requirements on the internal working of >a switch. As stated in a previous message: > >"The model of operation is simply a basis for describing the >functionality of the MAC Bridge. It is in no way intended to constrain >real implementations of a MAC Bridge; these may adopt any internal model >of operation compatible with the externally visible behavior that this >standard specifies. Conformance of equipment to this standard is purely >in respect of observable protocol." > >I am not worried about link errors. I am worried about corruption >within switches. If switches have unknown failure modes that add >unknown corruption, what besides a Path FCS will be able to determine >that there is a problem. Once again, detection is at least 10 times as >important as diagnosis. If we can come up with a better way to detect >when (not if) switches are corrupting packets, I would be very >interested in understanding the benefits of this approach. > >The service provider requirement can be succinctly stated as: > >The network shall be able to detect when (not if) switches are >corrupting packets. Suggesting that switches will never unknowingly >corrupt packets is wishing the problem away and is not an acceptable >answer. Never is a very long time. Besides, out of the 100 or so >switches I have worked with, I have already seen it happen. And I am >not all that lucky. > >Thanks, > >Scott From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: RE: ATM/Ethernet/Control drafts minor corrections Date: Wed, 26 Nov 2003 09:12:53 +0200 Lines: 151 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-From: pwe3-admin@ietf.org Wed Nov 26 08:15:14 2003 Return-path: To: "'Luca Martini'" , 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 Luca and all, I'd like to repeat my previous comment regarding lack of default mode (port with service-delimiting VLAN tags, port with VLAN tags that are not service-delimiting, tagged) in the Ethernet encapsulation draft. 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: Luca Martini [mailto:lmartini@cisco.com] > Sent: Tuesday, November 25, 2003 7:53 PM > To: pwe3@ietf.org > Subject: [PWE3] ATM/Ethernet/Control drafts minor corrections > > > WG members, > > I have collected all the comments on the atm and ethernet > encapsulation, drafts, as well as the control and maintenance > protocol > draft. > Most are either spelling , punctuation, or english > corrections which are > not significant enought to spell out individually. > But there is a minor text clarification below that does not > change the > technical design , but makes the reading easier. > > First , the title of the ATM draft does not fit: > > Encapsulation Methods for Transport of ATM Cells/Frame Over > IP and MPLS > Networks > So has chaged to : > Encapsulation Methods for Transport of ATM Over IP and MPLS Networks > > To fit in 72 columns. > > In the sequnce section: > > BEFORE: > 4.3.4. Processing the sequence number field in the control word > [snip] > When a packet is received on that emulated VC, the sequence number > should be processed as follows: > > - if the sequence number on the packet is 0, then the > packet passes > the sequence number check > > - otherwise if the packet sequence number >= the > expected sequence > number and the packet sequence number - the expected sequence > number < 32768, then the packet is in order. > > - otherwise if the packet sequence number < the expected sequence > number and the expected sequence number - the packet sequence > number >= 32768, then the packet is in order. > > - otherwise the packet is out of order. > > If a packet passes the sequence number check, or is in > order then, it > can be delivered immediately. If the packet is in order, then the > expected sequence number should be set using the algorithm: > > expected_sequence_number := packet_sequence_number + 1 mod 2**16 > if (expected_sequence_number = 0) then > expected_sequence_number:= 1; > > Packets which are received out of order MAY be dropped or reordered > at the discretion of the receiver. > > If a router PE2 does not support receive sequence number > processing, > then the sequence number field MAY be ignored. > > > AFTER: > > 4.3.4. Processing the sequence number field in the control word > [snip] > When a packet is received on that emulated VC, the sequence number > should be processed as follows: > > - if the sequence number on the packet is 0, then the > packet passes > the sequence number check. > > - otherwise if the packet sequence number >= the > expected sequence > number and the packet sequence number - the expected sequence > number < 32768, then the packet is in order. > > - otherwise if the packet sequence number < the expected sequence > number and the expected sequence number - the packet sequence > number >= 32768, then the packet is in order. > > - otherwise the packet is out of order. > > If a packet is in order then, it can be delivered > immediately. If the > packet is in order, then the expected sequence number MUST be set > using the algorithm: > > expected_sequence_number := packet_sequence_number + 1 mod 2**16 > if (expected_sequence_number = 0) then > expected_sequence_number:= 1; > > > Packets which are received out of order MAY be dropped or reordered > at the discretion of the receiver. > > A simple extension of the above processing algorithm can be used to > detect lost packets. > > If a router PE2 does not support receive sequence number > processing, > then the sequence number field MAY be ignored. > > > This section is identical in the ethernet or atm draft, and should be > identical in the frame-relay draft as well. > Also Stewart, Yakov Stein and I discussed the concerns raised at the > last ITU meeting , and concluded that this text is correct > and needs no > changes. > > Thanks. > Luca > > > 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: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Wed, 26 Nov 2003 10:26:53 -0000 Lines: 205 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 Nov 26 11:28:11 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcOzxLdrlIGC+MiSToq+ZRQbJ7jNJQAOQLJQ To: , , X-OriginalArrivalTime: 26 Nov 2003 10:26:54.0287 (UTC) FILETIME=[CFEFB5F0:01C3B407] 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 Ali, The way I would answer (some of) your questions is as follows: - according to the func arch draft Rec (G.8010) being developed for = ethernet, the eth FCS belongs to the link-connection adaptation = function.....not the end-end (ie between eth flow trail term points) = characteristic information. You may recall Juergen corrected me on this = a couple of days ago. - this means if any of the traffic unit that is covered by the FCS = changes at a link-level then the FCS will need to be updated to reflect = the changes. CRCs are linear functions, and it can shown mathematically = that a known change to specific bits in the traffic unit can be = corrected by an update of the FCS and only the FCS, ie there is no need = to recalculate the FCS over the entire traffic unit. This is no = different in principle to the HEC function that protects the ATM header = (but only the ATM header) since the VPI/VCI label usually changes on = link-connections. One can consider the eth VLAN field in a similar = manner, ie known changes to the VLAN field can be reflected as updates = of the FCS. - the lesson that I take away from the above observations is that = architecturally it makes more sense to have 2 different CRCs, (i) one = protecting only the CI that goes between trail term points transparently = (ie never changes on link-connections) and (ii) one protecting only the = link-connection specific part of the client traffic unit that can change = on link-connections (so this needs a linear update per link connection). - When ethernet was first designed the above issues were never = considered....and in particular there was no VLAN field. We cannot now = go back and change this IMO. However, the FCS does still belong to the = eth client and IMO it should never be discarded in some arbitrary manner = by a server layer. I use the word 'arbitrary' here since I have noted = different behaviours specified in G.8010 which I don't think is a good = idea, eg for all co-cs server technologies the carriage of the eth FCS = is a 'must', for an ATM co-ps server layer the carriage of the FCS is = 'optional', and for an MPLS co-ps server it currently says it can be = 'removed'. A client and server layer network should be = independent.....so having different behaviours dependent on the server = layer mode and/or specific technology is not a logical behaviour to me. = IMO the default behaviour of the server layer should always be to carry = the client layer traffic unit transparently. regards, Neil > -----Original Message----- > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Ali > Sajassi > Sent: 26 November 2003 02:24 > To: mick_seaman@ieee.org; 'Scott Kotrla'; stds-802-1@ieee.org; > pwe3@ietf.org > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention >=20 >=20 > I ask the question of service applicability for FCS retention=20 > some time ago=20 > and I didn't get a clear answer so let me ask again. When=20 > talking about FCS=20 > retention, which I of the following four Ethernet services do=20 > you have in=20 > mind ? >=20 > 1) port-based point-to-point Ethernet service > 2) vlan-based point-to-point Ethernet service > 3) port-based Ethernet bridge service (multipoint) > 4) vlan-based Ethernet bridge service (multipoint) >=20 > In vlan-based service, the customer vlan is used as service=20 > delimiter and=20 > is NOT the same at the two ends of the service - e.g., just=20 > like frame=20 > relay or ATM where DLCI or VPI/VCI are not the same at two=20 > ends. Requiring=20 > that the VLANs be the same at the two ends, imposes=20 > unnecessary restriction=20 > in customer provisioning model. Therefore, FCS retention is=20 > not viable for=20 > applications where customer VLAN is used as service delimiter. >=20 > Also any bridge service (port-based or vlan-based) doesn't=20 > require FCS=20 > retention by the definition of the bridge service itself. >=20 > So, the only applicable service for this FCS retention stuff=20 > (and I doubt=20 > viability of it), is for port-based point-to-point service.=20 > However, I=20 > would like to ask the following question: >=20 > How do you catch the errors introduced by the switches for the other=20 > services ??? Given that the same set of networking gears is=20 > to support all=20 > four Ethernet services, are you suggesting that we only need=20 > to solve the=20 > problem for a single service and not to worry about other=20 > service type !!!=20 > Or are you suggesting that you only offer a single service=20 > and thus you=20 > don't have to worry about other services !!! >=20 > As I mentioned previously, a better approach is to solve the=20 > problem for=20 > all the Ethernet services - whether it is through OAM=20 > mechanisms or through=20 > internal switch check-sum or a combination of two or=20 > whatever. But the=20 > point is we should try to address the issue for ALL service types. >=20 > -Ali >=20 > At 12:01 PM 11/25/2003 -0800, Mick Seaman wrote: >=20 > >If you are not concerned about protecting the customer but=20 > merely locating > >repetitively failed switch then OAM-like operations and test=20 > should be > >sufficient. It remains the case that placing exactly the=20 > same error check > >algorithm on the outer CRC as the inner does not extend your=20 > fault coverage > >for the customer much. Switch faults will still be capable=20 > of bringing the > >entire network to a halt and sending the wrong packets to the wrong > >customers. Anyone who buys a network service from a provider=20 > with poor > >internals on the grounds that the outer CRC will protect him=20 > is being simply > >naive. I'll go further than that, if a salesman tries to=20 > sell me a service > >with an outer CRC I will know that I can't trust the network=20 > and simply > >should not buy. > > > >Moreover as I have pointed out it is perfectly in the spirit=20 > of the 802.1 > >standards that the switch recalculate both the inner and the=20 > outer CRC, and > >indeed where the format of the frame delievered to the=20 > custoomer changes > >through the network it will have to recalculate both. > > > >Mick > > > >-----Original Message----- > >From: owner-stds-802-1@majordomo.ieee.org > >[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla > >Sent: Tuesday, November 25, 2003 8:36 AM > >To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org > >Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > > >So are you suggesting because a CRC-32 will miss 1 in 4=20 > billion frames > >it is not useful to know? I don't need to catch every frame to know > >there is a problem. > > > >The standard Ethernet CRC protects the link and not the=20 > internal switch, > >and it is very difficult to put requirements on the internal=20 > working of > >a switch. As stated in a previous message: > > > >"The model of operation is simply a basis for describing the > >functionality of the MAC Bridge. It is in no way intended to=20 > constrain > >real implementations of a MAC Bridge; these may adopt any=20 > internal model > >of operation compatible with the externally visible behavior=20 > that this > >standard specifies. Conformance of equipment to this=20 > standard is purely > >in respect of observable protocol." > > > >I am not worried about link errors. I am worried about corruption > >within switches. If switches have unknown failure modes that add > >unknown corruption, what besides a Path FCS will be able to determine > >that there is a problem. Once again, detection is at least=20 > 10 times as > >important as diagnosis. If we can come up with a better way=20 > to detect > >when (not if) switches are corrupting packets, I would be very > >interested in understanding the benefits of this approach. > > > >The service provider requirement can be succinctly stated as: > > > >The network shall be able to detect when (not if) switches are > >corrupting packets. Suggesting that switches will never unknowingly > >corrupt packets is wishing the problem away and is not an acceptable > >answer. Never is a very long time. Besides, out of the 100 or so > >switches I have worked with, I have already seen it happen. And I am > >not all that lucky. > > > >Thanks, > > > >Scott >=20 >=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: Luca Martini Subject: Re: MPLS PWs over IP: Text for draft-ietf-pwe3-control-protocol-04.txt Date: Wed, 26 Nov 2003 10:49:26 -0700 Organization: Cisco Systems Lines: 101 Sender: pwe3-admin@ietf.org References: <20031125141941.K43991@sapphire.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , "W. Mark Townsley" , "Eric Rosen (erosen)" , pwe3@ietf.org X-From: pwe3-admin@ietf.org Wed Nov 26 18:51:08 2003 Return-path: User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.4) Gecko/20030630 X-Accept-Language: en-us, en To: Rahul Aggarwal In-Reply-To: <20031125141941.K43991@sapphire.juniper.net> X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) 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 a significant change , which is past the last call of the document. In addition to that, this design competes with other work already submitted to MPLS WG. The pwe3 control draft already states : " The PSN tunnel can itself be an LSP, but it could equally well be an IP tunnel, a GRE tunnel, an IPsec tunnel, or any other sort of tunnel which can carry MPLS packets." it is not in the scope of this document, or WG charter, to specify how to carry MPLS in GRE,Ipsec etc. I believe that we should take this work to the MPLS wg as standrads track draft. Tks. Luca Rahul Aggarwal wrote: >Hi Luca, > >Following up on the discussion on MPLS PWs over IP at the last IETF, here >is suggested text for draft-ietf-pwe3-control-protocol-04.txt. It applies >to section 3. Please let me know what you think. > >Thanks, >rahul > >------------------------------------------------------------------------------- >3. The Pseudowire Label > >..... > >So when PE1 sends a layer 2 PDU to PE2, it first pushes a PW label on > its label stack, thereby creating an MPLS packet. It then (if PE1 is > not adjacent to PE2) encapsulates that MPLS packet in a PSN tunnel > header. (If the PSN tunnel is an LSP, this is just a matter of > pushing on a second label.) The PW label is not visible again until > the MPLS packet reaches PE2. PE2's disposition of the packet is based > on the PW label. > > > >Note that the PW label must always be at the bottom of the packet's >label stack and labels MUST be allocated from the per-platform label >space > > > >If the PSN tunnel is an MPLS LSP, then putting on a PSN tunnel encapsulation >is a matter of pushing an additional MPLS label on the packet. This >upper MPLS label is the MPLS LSP label that causes the packet to be >delivered to the egress of the PW i.e PE2. > >In order to enable MPLS PWs to be deployed when there are non-MPLS routers >along the path between ingress and egress PE routers, it may be desirable >to use an IP or GRE PSN tunnel. In this case MPLS-in-IP or MPLS-in-GRE >[MPLS-OVER-IP-GRE] encapsulation is used to turn the MPLS PW packet into >an IP packet. The IP source address will be the address of the PW ingress >and the IP destination address will be the address of the PW egress. The >net effect is that a MPLS PW packet gets sent through a dynamically >created IP or GRE PSN tunnel. The egress PE decapsulates the MPLS-in-IP >or MPLS-in-GRE packets as in [MPLS-OVER-IP-GRE] and processes the >resulting MPLS PW packets. > >It may also be desirable to use an IPsec PSN tunnel [RFC2402, RFC2406] to >enable MPLS PW packets to be carried securely over non-MPLS networks. >One possible mechanism to achieve this is that the ingress PE creates an >MPLS-in-IP or MPLS-in-GRE encapsulated packet, as above. If required the >ingress PE then sets up a IPsec Security Association to the egress PE. >Appropriate IPsec procedures are then applied generating a packet with an >IP header followed by an IPsec header followed by MPLS-in-IP or MPLS-in-GRE >encapsulated MPLS PW packet. The egress PE applies the necessary IPsec >procedures to the arriving IPsec packets and recovers the contained >MPLS-in-IP or MPLS-in-GRE packets, which are then appropriately processed. > > > > >[MPLS-OVER-IP-GRE] "Encapsulating MPLS in IP or GRE", T. Worster, > Rekhter Y., Rosen E., draft-ietf-mpls-in-ip-or-gre-03.txt >[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC > 2402, November 1998. > >[RFC2406] Kent,S. and R. Atkinson, "IP Encapsulating Security Payload > (ESP)", RFC 2406, November 1998. > > > > > > > > > > > > > From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Ali Sajassi Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Wed, 26 Nov 2003 12:10:30 -0800 Lines: 231 Sender: pwe3-admin@ietf.org References: <0536FC9B908BEC4597EE721BE6A3538904EF2EC2@i2km07-ukbr.domai n1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: X-From: pwe3-admin@ietf.org Wed Nov 26 21:12:06 2003 Return-path: X-Sender: sajassi@airborne.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: , , , In-Reply-To: <0536FC9B908BEC4597EE721BE6A3538904EF2EC2@i2km07-ukbr.domai n1.systemhost.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 Hi Neil, At 10:26 AM 11/26/2003 +0000, neil.2.harrison@bt.com wrote: >Hi Ali, > >The way I would answer (some of) your questions is as follows: > >- according to the func arch draft Rec (G.8010) being developed for >ethernet, the eth FCS belongs to the link-connection adaptation >function.....not the end-end (ie between eth flow trail term points) >characteristic information. You may recall Juergen corrected me on this a >couple of days ago. > >- this means if any of the traffic unit that is covered by the FCS >changes at a link-level then the FCS will need to be updated to reflect >the changes. CRCs are linear functions, and it can shown mathematically >that a known change to specific bits in the traffic unit can be corrected >by an update of the FCS and only the FCS, ie there is no need to >recalculate the FCS over the entire traffic unit. This is no different in >principle to the HEC function that protects the ATM header (but only the >ATM header) since the VPI/VCI label usually changes on >link-connections. One can consider the eth VLAN field in a similar >manner, ie known changes to the VLAN field can be reflected as updates of >the FCS. Yes and this is the intended mechanism for bridges and it is reflected in Appendix F of 802.1D as I mentioned in one of my previous emails. >- the lesson that I take away from the above observations is that >architecturally it makes more sense to have 2 different CRCs, (i) one >protecting only the CI that goes between trail term points transparently >(ie never changes on link-connections) and (ii) one protecting only the >link-connection specific part of the client traffic unit that can change >on link-connections (so this needs a linear update per link connection). So in the context of our discussions, given that the PEs are intended to provide transport functionality with respect to Ethernet services and not interworking, then it means any FCS to be added for the CI portion is the job of the CE and not the PE - this is analogous to ATM and FR transport where you don't expect the ATM switch or FR switch to add a CRC for the payload. >- When ethernet was first designed the above issues were never >considered....and in particular there was no VLAN field. We cannot now go >back and change this IMO. However, the FCS does still belong to the eth >client and IMO it should never be discarded in some arbitrary manner by a >server layer. I use the word 'arbitrary' here since I have noted >different behaviours specified in G.8010 which I don't think is a good >idea, eg for all co-cs server technologies the carriage of the eth FCS is >a 'must', for an ATM co-ps server layer the carriage of the FCS is >'optional', and for an MPLS co-ps server it currently says it can be >'removed'. A client and server layer network should be independent.....so >having different behaviours dependent on the server layer mode and/or >specific technology is not a logical behaviour to me. IMO the default >behaviour of the server layer should always be to carry the client layer >traffic unit transparently. And in terms of bridge applications, the client layer (user data) doesn't have FCS (the FCS belongs to the server layer - the MAC layer) and the client layer FCS (if needed) is the responsibility of the application and not the bridge. So if you want to have a new encapsulation on the CE side (similar to 1483/1490 that can have FCS for client data), then that a separate issue but we shouldn't impose such requirement on the bridges. Regards, Ali >regards, Neil > > > > -----Original Message----- > > From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of Ali > > Sajassi > > Sent: 26 November 2003 02:24 > > To: mick_seaman@ieee.org; 'Scott Kotrla'; stds-802-1@ieee.org; > > pwe3@ietf.org > > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > I ask the question of service applicability for FCS retention > > some time ago > > and I didn't get a clear answer so let me ask again. When > > talking about FCS > > retention, which I of the following four Ethernet services do > > you have in > > mind ? > > > > 1) port-based point-to-point Ethernet service > > 2) vlan-based point-to-point Ethernet service > > 3) port-based Ethernet bridge service (multipoint) > > 4) vlan-based Ethernet bridge service (multipoint) > > > > In vlan-based service, the customer vlan is used as service > > delimiter and > > is NOT the same at the two ends of the service - e.g., just > > like frame > > relay or ATM where DLCI or VPI/VCI are not the same at two > > ends. Requiring > > that the VLANs be the same at the two ends, imposes > > unnecessary restriction > > in customer provisioning model. Therefore, FCS retention is > > not viable for > > applications where customer VLAN is used as service delimiter. > > > > Also any bridge service (port-based or vlan-based) doesn't > > require FCS > > retention by the definition of the bridge service itself. > > > > So, the only applicable service for this FCS retention stuff > > (and I doubt > > viability of it), is for port-based point-to-point service. > > However, I > > would like to ask the following question: > > > > How do you catch the errors introduced by the switches for the other > > services ??? Given that the same set of networking gears is > > to support all > > four Ethernet services, are you suggesting that we only need > > to solve the > > problem for a single service and not to worry about other > > service type !!! > > Or are you suggesting that you only offer a single service > > and thus you > > don't have to worry about other services !!! > > > > As I mentioned previously, a better approach is to solve the > > problem for > > all the Ethernet services - whether it is through OAM > > mechanisms or through > > internal switch check-sum or a combination of two or > > whatever. But the > > point is we should try to address the issue for ALL service types. > > > > -Ali > > > > At 12:01 PM 11/25/2003 -0800, Mick Seaman wrote: > > > > >If you are not concerned about protecting the customer but > > merely locating > > >repetitively failed switch then OAM-like operations and test > > should be > > >sufficient. It remains the case that placing exactly the > > same error check > > >algorithm on the outer CRC as the inner does not extend your > > fault coverage > > >for the customer much. Switch faults will still be capable > > of bringing the > > >entire network to a halt and sending the wrong packets to the wrong > > >customers. Anyone who buys a network service from a provider > > with poor > > >internals on the grounds that the outer CRC will protect him > > is being simply > > >naive. I'll go further than that, if a salesman tries to > > sell me a service > > >with an outer CRC I will know that I can't trust the network > > and simply > > >should not buy. > > > > > >Moreover as I have pointed out it is perfectly in the spirit > > of the 802.1 > > >standards that the switch recalculate both the inner and the > > outer CRC, and > > >indeed where the format of the frame delievered to the > > custoomer changes > > >through the network it will have to recalculate both. > > > > > >Mick > > > > > >-----Original Message----- > > >From: owner-stds-802-1@majordomo.ieee.org > > >[mailto:owner-stds-802-1@majordomo.ieee.org]On Behalf Of Scott Kotrla > > >Sent: Tuesday, November 25, 2003 8:36 AM > > >To: mick_seaman@ieee.org; stds-802-1@ieee.org; pwe3@ietf.org > > >Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention > > > > > > > > > > > >So are you suggesting because a CRC-32 will miss 1 in 4 > > billion frames > > >it is not useful to know? I don't need to catch every frame to know > > >there is a problem. > > > > > >The standard Ethernet CRC protects the link and not the > > internal switch, > > >and it is very difficult to put requirements on the internal > > working of > > >a switch. As stated in a previous message: > > > > > >"The model of operation is simply a basis for describing the > > >functionality of the MAC Bridge. It is in no way intended to > > constrain > > >real implementations of a MAC Bridge; these may adopt any > > internal model > > >of operation compatible with the externally visible behavior > > that this > > >standard specifies. Conformance of equipment to this > > standard is purely > > >in respect of observable protocol." > > > > > >I am not worried about link errors. I am worried about corruption > > >within switches. If switches have unknown failure modes that add > > >unknown corruption, what besides a Path FCS will be able to determine > > >that there is a problem. Once again, detection is at least > > 10 times as > > >important as diagnosis. If we can come up with a better way > > to detect > > >when (not if) switches are corrupting packets, I would be very > > >interested in understanding the benefits of this approach. > > > > > >The service provider requirement can be succinctly stated as: > > > > > >The network shall be able to detect when (not if) switches are > > >corrupting packets. Suggesting that switches will never unknowingly > > >corrupt packets is wishing the problem away and is not an acceptable > > >answer. Never is a very long time. Besides, out of the 100 or so > > >switches I have worked with, I have already seen it happen. And I am > > >not all that lucky. > > > > > >Thanks, > > > > > >Scott > > > > > > _______________________________________________ > > 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: neil.2.harrison@bt.com Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Wed, 26 Nov 2003 20:53:54 -0000 Lines: 97 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 Nov 26 21:55:17 2003 Return-path: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message Thread-Topic: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Thread-Index: AcO0WVqrx6doBQTxQgGa0Tj6FvOPkAAAVmdw To: , , X-OriginalArrivalTime: 26 Nov 2003 20:53:55.0045 (UTC) FILETIME=[67A7D150:01C3B45F] 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 Ali, Ali Sajassi wrote 26 November 2003 20:10 >=20 > >- the lesson that I take away from the above=20 > observations is that=20 > >architecturally it makes more sense to have 2 different=20 > CRCs, (i) one=20 > >protecting only the CI that goes between trail term points=20 > transparently=20 > >(ie never changes on link-connections) and (ii) one=20 > protecting only the=20 > >link-connection specific part of the client traffic unit=20 > that can change=20 > >on link-connections (so this needs a linear update per link=20 > connection). >=20 > So in the context of our discussions, given that the PEs are=20 > intended to=20 > provide transport functionality with respect to Ethernet=20 > services and not=20 > interworking, then it means any FCS to be added for the CI=20 > portion is the=20 > job of the CE and not the PE - this is analogous to ATM and=20 > FR transport=20 > where you don't expect the ATM switch or FR switch to add a=20 > CRC for the=20 > payload. NH=3D> I tend to think in terms of G.805 func arch and not boxes, ie it = is the func arch (eg where layer networks start and end) that is most = important, not a 'CE' or 'PE' badge. I look at this stuff very simply: = The FCS of eth belongs to the traffic unit of the eth layer = network....not any other layer network. Where the eth client gets = encapsulated (let's say in MPLS) is where the LSP trail starts (this can = be any box)....and there is an LSP trail term point where they get = decapsulated. (Yes I know folks also add a PW header but this is not a = layer network, simply an adaptation function). This is simply = client/server encapulation and well defined in G.805. If we carry the = eth clinet over any server layer, you mentioned ATM or FR (but I could = also add PDH, SDH, etc), then exactly the same applies. If one plays = about with any aspect of the client layer traffic unit (usually some = form of compression), and thus suffers a loss of client layer CI = transparency, there is usually some price to be paid. So, IMO, unless = there are quite compelling reasons (like the cost of BW has gone through = the roof) don't touch the client layer at all. >=20 >=20 > >- When ethernet was first designed the above issues were never=20 > >considered....and in particular there was no VLAN field. We=20 > cannot now go=20 > >back and change this IMO. However, the FCS does still=20 > belong to the eth=20 > >client and IMO it should never be discarded in some=20 > arbitrary manner by a=20 > >server layer. I use the word 'arbitrary' here since I have noted=20 > >different behaviours specified in G.8010 which I don't think=20 > is a good=20 > >idea, eg for all co-cs server technologies the carriage of=20 > the eth FCS is=20 > >a 'must', for an ATM co-ps server layer the carriage of the FCS is=20 > >'optional', and for an MPLS co-ps server it currently says it can be=20 > >'removed'. A client and server layer network should be=20 > independent.....so=20 > >having different behaviours dependent on the server layer=20 > mode and/or=20 > >specific technology is not a logical behaviour to me. IMO=20 > the default=20 > >behaviour of the server layer should always be to carry the=20 > client layer=20 > >traffic unit transparently. >=20 > And in terms of bridge applications, the client layer (user=20 > data) doesn't=20 > have FCS (the FCS belongs to the server layer - the MAC=20 > layer) NH=3D> This, I think, is the key issue of contention Ali (and why = various people see the situation differently). If we take the LLC/MAC = split then you have a valid point. It's also pretty similar (if you = think about it) to the ATM_cell/AAL_X split. However, I would tend to = look at the LLC/MAC as 'joined at the hip' sub-layers, ie they must go = together...and I don't know of any std which allows the LLC part to sent = on anything without its MAC part (but please correct me if you know = otherwise). There is not the same binding IMO between the ATM_cell and = the AAL_X.....I can easily imagine AAL_X being carried over some other = server layer network....and in fact Yaakov S has considered this for = AAL1 (TDM) over MPLS for example. The fact folks are now proposing to send the eth frames over WAN = technologies is a problem of our making, not the orgins of eth with how = it viewed what would be the MAC layer.....so these aspects were never = clearly diveroced or considered before AFAIK. And which is why on = balance, I still err of the side of caution with the view that the FCS = should be carried as the default behaviour. regards, Neil From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Sasha Vainshtein Subject: A comment on the siganling part of draft-ietf-pwe3-fcs-retention- 00.txt Date: Thu, 27 Nov 2003 09:20:10 +0200 Lines: 46 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Cc: "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Thu Nov 27 08:22:19 2003 Return-path: To: "Andrew G. Malis (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 Andy and all, IMHO, there is a couple of (inor) problems with the proposed signaling of FCS retention in draft-ietf-pwe3-fcs-retention-00.txt. 1. PEs only signal that they agree to receive retained FCS as the proposed interface attribute does not have any value, just an ID. This is OK with Ethernet, but the draft also discusses FR (port mode), HDLC and PPP - and, AFAIK, these may use 16-bit or 32-bit FCS (even if 32-bit FCS is rare). Surely retaining a 16-bit FCS value coming from the AC at one end of the PW will not be of much use at the other end if the corresponding AC uses 32-bit FCS! This problem is easy to fix by adding VALUE to the proposed attribute. This value would specify the FCS type used by the AC in question (e.g., Ethernet, 16-bit HDLC, 32-bit HDLC), and limiting applicability of retention to the case when the two ACs use the same kind of FCS. (The size of the attribute should be increased accordingly to account for this value). 2. It would also be nice to specify that a PE includes the FCS retention attribute if it is capable of both receiving (as in the text) and SENDING retained FCS. This would prevent bizarre situations where both PEs have agreed to RECEIVE retained FCS (and hence presumably expect FCS in the PW packets) without one (and possibly both) really SENDING it. Of course, the signaling could be also enhanced to allow independent FCS retention in each direction of the PW, but this hardly seems justified. My 2c. ---------------------------------------------------------------------------- -------- 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: "Andrew G. Malis" Subject: Re: A comment on the signaling part of draft-ietf-pwe3-fcs-retention- 00.txt Date: Thu, 27 Nov 2003 10:52:58 -0500 Lines: 49 Sender: pwe3-admin@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Andrew G. Malis (E-mail)" , "PWE3 WG (E-mail)" X-From: pwe3-admin@ietf.org Thu Nov 27 16:54:05 2003 Return-path: X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1 To: Sasha Vainshtein In-Reply-To: References: X-OriginalArrivalTime: 27 Nov 2003 15:53:17.0102 (UTC) FILETIME=[929DE4E0:01C3B4FE] 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, Thanks for your comments. Replies inline. >IMHO, there is a couple of (minor) problems with the proposed >signaling of FCS retention in draft-ietf-pwe3-fcs-retention-00.txt. > >1. PEs only signal that they agree to receive retained FCS as the proposed > interface attribute does not have any value, just an ID. This is OK with > Ethernet, but the draft also discusses FR (port mode), HDLC and PPP - > and, AFAIK, these may use 16-bit or 32-bit FCS (even if 32-bit FCS is > rare). > Surely retaining a 16-bit FCS value coming from the AC at one end of > the PW > will not be of much use at the other end if the corresponding AC uses > 32-bit FCS! > > This problem is easy to fix by adding VALUE to the proposed attribute. > This value would specify the FCS type used by the AC in question (e.g., > Ethernet, 16-bit HDLC, 32-bit HDLC), and limiting applicability of > retention > to the case when the two ACs use the same kind of FCS. (The size of > the attribute > should be increased accordingly to account for this value). Thanks - that's a really good suggestion. We'll include that in the next revision. >2. It would also be nice to specify that a PE includes the FCS retention >attribute if it is capable of both receiving (as in the text) and SENDING >retained >FCS. > > This would prevent bizarre situations where both PEs have agreed to > RECEIVE > retained FCS (and hence presumably expect FCS in the PW packets) without > one (and possibly both) really SENDING it. That's also a good clarification to make explicit. > Of course, the signaling could be also enhanced to allow independent > FCS retention > in each direction of the PW, but this hardly seems justified. Yeah, and it's also much harder to keep backwards compatibility, so we'll keep the current requirement of using it in both directions, or neither. Thanks again, Andy From pwe3-admin@ietf.org Wed Dec 27 16:41:46 2006 From: Maarten.Vissers@alcatel.de Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention Date: Thu, 27 Nov 2003 17:54:25 +0100 Lines: 142 Sender: pwe3-admin@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-From: pwe3-admin@ietf.org Thu Nov 27 17:56:07 2003 Return-path: To: pwe3@ietf.org, stds-802-1@ieee.org X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 X-MIMETrack: Serialize by Router on DEMAIL02/DE/ALCATEL(Release 5.0.11 |July 24, 2002) at 11/27/2003 17:54:28, Serialize complete at 11/27/2003 17:54:28 X-Alcanet-virus-scanned: hARGsSZo028464 at mailrelay1.alcatel.de 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 far as I have understood the game of Ethernet over Transport, it is not opportune to change the basic ethernet frame format and behaviour. In that sense we simply have to accept the MAC FCS as is, as well as the dropping of corrupted frames at the input port of a bridge or EPL. In this environment, the FCS is related to the ETH link (G.8010) and allows detection of errors introduced during transport over the link. Any ETH link should support FCS... i.e. ETH links supported by Ethernet PHYs (obvious), SDH VC-n(-Xv/Xc) or OTN ODUk(-Xv) (G.7041), ATM VC (RFC2684, select the option to inlcude FCS) and also MPLS (to be fixed). What is now left are errors introduced during the forwarding through and processing in equipment. I.e. when there is an equipment fault... I can imagine that equipment adds equipment specific CRC (may re-use FCS) or BIP to the signal and checks this (to detect possible faults) before preparing the frame for transport over the egressing ETH link. Such capability could be assumed to be a major requirement for such equipment in a carrier network, and equipment non-compliant to this requirement is not installed in such network. Note - Isn't this error detection capability described in 6.3.7/802.1D? If this route is followed, we can continue with the current definition of ethernet (only fix EoMPLS); i.e. no need to introduce a second CRC and change the basic MAC frame. Regards, Maarten Sent by: owner-stds-802-1@majordomo.ieee.org 26-11-2003 21:53 To: , , cc: Maarten VISSERS/DE/ALCATEL@ALCATEL Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention Hi Ali, Ali Sajassi wrote 26 November 2003 20:10 > > >- the lesson that I take away from the above > observations is that > >architecturally it makes more sense to have 2 different > CRCs, (i) one > >protecting only the CI that goes between trail term points > transparently > >(ie never changes on link-connections) and (ii) one > protecting only the > >link-connection specific part of the client traffic unit > that can change > >on link-connections (so this needs a linear update per link > connection). > > So in the context of our discussions, given that the PEs are > intended to > provide transport functionality with respect to Ethernet > services and not > interworking, then it means any FCS to be added for the CI > portion is the > job of the CE and not the PE - this is analogous to ATM and > FR transport > where you don't expect the ATM switch or FR switch to add a > CRC for the > payload. NH=> I tend to think in terms of G.805 func arch and not boxes, ie it is the func arch (eg where layer networks start and end) that is most important, not a 'CE' or 'PE' badge. I look at this stuff very simply: The FCS of eth belongs to the traffic unit of the eth layer network....not any other layer network. Where the eth client gets encapsulated (let's say in MPLS) is where the LSP trail starts (this can be any box)....and there is an LSP trail term point where they get decapsulated. (Yes I know folks also add a PW header but this is not a layer network, simply an adaptation function). This is simply client/server encapulation and well defined in G.805. If we carry the eth clinet over any server layer, you mentioned ATM or FR (but I could also add PDH, SDH, etc), then exactly the same applies. If one plays about with any aspect of the client layer traffic unit (usually some form of compression), and thus suffers a loss of client layer CI transparency, there is usuall! y some price to be paid. So, IMO, unless there are quite compelling reasons (like the cost of BW has gone through the roof) don't touch the client layer at all. > > > >- When ethernet was first designed the above issues were never > >considered....and in particular there was no VLAN field. We > cannot now go > >back and change this IMO. However, the FCS does still > belong to the eth > >client and IMO it should never be discarded in some > arbitrary manner by a > >server layer. I use the word 'arbitrary' here since I have noted > >different behaviours specified in G.8010 which I don't think > is a good > >idea, eg for all co-cs server technologies the carriage of > the eth FCS is > >a 'must', for an ATM co-ps server layer the carriage of the FCS is > >'optional', and for an MPLS co-ps server it currently says it can be > >'removed'. A client and server layer network should be > independent.....so > >having different behaviours dependent on the server layer > mode and/or > >specific technology is not a logical behaviour to me. IMO > the default > >behaviour of the server layer should always be to carry the > client layer > >traffic unit transparently. > > And in terms of bridge applications, the client layer (user > data) doesn't > have FCS (the FCS belongs to the server layer - the MAC > layer) NH=> This, I think, is the key issue of contention Ali (and why various people see the situation differently). If we take the LLC/MAC split then you have a valid point. It's also pretty similar (if you think about it) to the ATM_cell/AAL_X split. However, I would tend to look at the LLC/MAC as 'joined at the hip' sub-layers, ie they must go together...and I don't know of any std which allows the LLC part to sent on anything without its MAC part (but please correct me if you know otherwise). There is not the same binding IMO between the ATM_cell and the AAL_X.....I can easily imagine AAL_X being carried over some other server layer network....and in fact Yaakov S has considered this for AAL1 (TDM) over MPLS for example. The fact folks are now proposing to send the eth frames over WAN technologies is a problem of our making, not the orgins of eth with how it viewed what would be the MAC layer.....so these aspects were never clearly diveroced or considered before AFAIK. And which is why on balance, I still err of the side of caution with the view that the FCS should be carried as the default behaviour. regards, Neil