Subject: RE: re: pwe3-ethernet-encap - FCS... (redux)

From: "David Allan" <[email-masked]>
Date: Wed, 17 Sep 2003 15:42:55 -0400

Group:
 
Seems to me that the FCS discussion on the list last April SHOULD have
resolved to having an option of carrying native 
Ethernet/FR FCS across a PW, however this has never been reflected in the
drafts.
 
I'd like to suggest:
- modifying the Ethernet (sect 3.1.1) and FR drafts (fig 3, sects 7.4.2,
10.1 etc.), to make this an option, 
- modifying the interface parameters TLV in the signalling draft to make
including FCS an option (default is no FCS for   
  backwards compatibility). 
IMO an LDP status value ('non-supported FCS option') in the IANA draft would
complete things.
 
Dave

---

From: Shahram Davari <[email-masked]>
Date: Thu, 18 Sep 2003 08:21:47 -0700

Hi Dave,

I support your proposal. In fact by comparison the GFP encapsulation
keeps the Ethernet FCS.

Yours,
-Shahram

>-----Original Message-----
>From: David Allan [mailto:[email-masked]]
>Sent: Wednesday, September 17, 2003 3:43 PM
>To: PWE3 WG (E-mail)
>Subject: [PWE3] RE: re: pwe3-ethernet-encap - FCS... (redux)
>
>
>Group:
> 
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: Luca Martini <[email-masked]>
Date: Fri, 19 Sep 2003 10:04:58 -0600

I oppose having more options that would either never be used , or require new 
hardware updates.
However, I will update the design with WG input but right now  I think this is 
pretty much a tie for FCS and against.
We have a significant operational experience with ethernet PW not carrying the 
FCS. And also please note that BCP (rfc3518) has this option, but all 
implementations I know of are not carrying the FCS. So far this has not been an 
issue at all.

Luca

---

From: "Christopher N. \"Nick\" DelRegno" <[email-masked]>
Date: Fri, 19 Sep 2003 15:41:09 -0500

Luca:

To your points:

1)  FCS Retention WOULD be used.  We would not propose this capability if we
never intended to use it.  While you may have no application for FCS
Retention, we do.  If it is not an option in the PWE3 RFC, then we will have
to use it as a MCI-specific feature.  However, as it is not a major change
in the draft, and since other carriers could use this functionality as well,
it only makes sense to add it in.

2)  We have conversed with several equipment suppliers who can support this
today.  They don't advertise the fact because it is not a part of the draft.
However, should it be added to the draft, it could be a differentiator.  Due
to NDA restraints, I will not name the vendors who support this, however
they can identify themselves.

>From a pseudowire perspective, I would be much more interested in
understanding the arguments for NOT supporting this.  Just because an
Ethernet switch doesn't retain the customer FCS, doesn't mean that there
aren't applications where FCS retention is desirable.  Having the option
negotiable via LDP Interface Parameters means that equipment that can
support FCS Retention can interwork with those that don't.

Regards,
Nick DelRegno

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca
Martini
Sent: Friday, September 19, 2003 11:05 AM
To: Shahram Davari
Cc: 'David Allan'; PWE3 WG (E-mail)
Subject: Re: [PWE3] RE: re: pwe3-ethernet-encap - FCS... (redux)

I oppose having more options that would either never be used , or require
new 
hardware updates.
However, I will update the design with WG input but right now  I think this
is 
pretty much a tie for FCS and against.
We have a significant operational experience with ethernet PW not carrying
the 
FCS. And also please note that BCP (rfc3518) has this option, but all 
implementations I know of are not carrying the FCS. So far this has not been
an 
issue at all.

Luca

---

From: "Christopher N. \"Nick\" DelRegno" <[email-masked]>
Date: Fri, 19 Sep 2003 15:39:55 -0500

Dave:

Thanks for bringing this up again.  I was just about to, but you beat me to
the punch.

While there may be reasons for discarding the FCS, there are also reasons to
keep the FCS.  

Therefore, I restate my support for the option of FCS Retention within the
respective Ethernet and Frame Relay encapsulation and transport drafts.  

Regards,
Nick

Christopher N. "Nick" DelRegno, Advisory Engineer
MCI, Global Access Technology Development

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David
Allan
Sent: Wednesday, September 17, 2003 2:43 PM
To: PWE3 WG (E-mail)
Subject: [PWE3] RE: re: pwe3-ethernet-encap - FCS... (redux)

Group:

I'd like to suggest:
 
Dave

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Fri, 19 Sep 2003 12:48:00 -0400

Luca,

I am also in favor of adding the option to carry the native Ethernet FCS.

1) I think it is the better solution for VPWS

2) I have seen efforts in other standardization bodies to push other packet switched solutions than MPLS because they claim MPLS-encapsulation is not transparent.

Peter 

> From: Luca Martini [mailto:[email-masked]]
> Sent: Friday, September 19, 2003 12:05 PM
> To: Shahram Davari

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 22 Sep 2003 22:41:59 +0200

Andy and Stewart,
The following consideration could be useful
for the evaluation proposed by Stewart.

There is substantial deployment experience with
Ethernet over PPP, FR and AAL5. All these cases
support two modes of operation - with and without FCS. 

Luca has said recently that PPP deployments do not 
use the option to carry FCS.

It would be very useful,IMO, to know what is 
actually used in Ethernet over FR and AAL5.
If the trend is not to carry FCS in these cases,
I would be tempted to conclude that Ethernet over
PW can safely skip this option altogether (and,
of course, vice versa).

(GFP deployments cannot provide any input since the
ITU-T G.7041 supports just one mode - include the FCS:-)

----------------------------------------------------------------------------
--------
With best regards,
                          Sasha Vainshtein
email:   [email-masked] <mailto:[email-masked]> 
phone:  +972-3-7659993 (office)
            +972-8-9254948 (home)
            +972-58-674833 (cellular)

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Monday, September 22, 2003 9:19 PM
> To: Andrew G. Malis
> Cc: PWE3 WG (E-mail)
> This is a small change to the specs and it is tempting to just let
> it go by on the nod. However it does introduce some complexity, in
> that it effects the control plane, the forwarding plane, gives
> rise to another set of interoperability tests, and is one more
> parameter to configure at each end.
> 
> The only use that I can see for the mechanism is that it
> potentially detects one class of failure in a broken box, and then
> only when running in a simple repeater mode.
> 
> Before just saying yes, I therefore think that we need to do
> some due diligence on the idea by asking the following questions:
> 
> 1) What level of increased fault coverage do we actually get?
> 
> 2) Is there a simpler mechanism of achieving the same fault coverage?
> 
> Then we need to determine if the net gain is worth the next cost,
> and act accordingly.
> 
> Regards
> 
> Stewart
> 
>

---

From: "Christopher N. \"Nick\" DelRegno" <[email-masked]>
Date: Tue, 23 Sep 2003 12:14:52 -0500

> Also, now that the symptoms of the disease are well-known, isn't it that
> much more likely to be diagnosed more quickly if it occurs in the future,
> even without changing current FCS behaviour?

The problem is that the symptoms are neither well known nor easily
diagnosed.  Since the egress device (LER) will calculate a new FCS, the
symptom may not be apparent until the packet reaches the customer router or
even as far as the customer end station.  

IP at least has a header check, so should the corruption occur within the IP
header, the customer router will drop the packet.  However, on large
packets, it is unlikely that the corruption will occur in the header.  If it
occurs elsewhere in the packet, the TCP check will detect the problem.
However, this will not occur until the packet has reached the customer end
station.  True, the packet will be dropped, but how, as a service provider,
do I detect that there is a problem?  If I am handing off to something other
than a router, then the symptom appears deeper in my customer's network,
without my knowledge.

I have seen interesting analogies and examples given.  I have one of my own.
In the IP network, we don't trust the underlying network to deliver the
packets without error.  As such, TCP and UDP have their own checksum in
order to ensure end-to-end data consistency.  Why now do we propose that the
network is reliable and therefore no end-to-end data consistency mechanism
is required for PWs?

In order to mitigate the problem, it would seem that I have two solutions to
this problem:

1)  Participate in detailed design reviews with every equipment vendor in my
network to ensure that there is no way their box can corrupt my encapsulated
traffic (which is impossible), or

2)  add the option to the encapsulating protocol which allows me to detect
such corruption.

It seems the second option is the better solution to ensure ubiquitous
coverage while ensuring interoperability.

The other reason for retaining the FCS is pure transparency, as noted
elsewhere in this discussion.  There are customers who want Ethernet
"private lines."  Some of these customers DO NOT allow for the changing of
ANY bits in the Ethernet frame.  In some cases, we have to demonstrate that
we do not inspect or change any customer information.  As such, today, one
has to either provision separate physical connections for those customers or
use a non-standard encapsulation mechanism.  In retaining the FCS, I can
provide a transparent circuit for my customer while leveraging the same
infrastructure as my non-transparent, switched circuits.

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of W. Mark
Townsley
Sent: Tuesday, September 23, 2003 3:44 AM
To: Andrew G. Malis
Cc: PWE3 WG (E-mail)
Subject: Re: [PWE3] RE: re: pwe3-ethernet-encap - FCS... (redux)

Perhaps an interesting data point, millions of PPP sessions are tunneled
over IP 
networks everyday, and I have not seen a single implementation which does
_not_ 
strip the PPP FCS as it enters the L2TP tunnel (as per RFC guidelines).

I'm not opposed to carrying the FCS per se, particularly if it had been done

this way since day one. But, I do question changing a maturing protocol,
adding 
a configuration option, increasing the associated testing and
interoperability 
matrix, etc. to protect what is arguably a rare circumstance of buggy
hardware. 
Is the cure loaded with more potential problems than the disease? Also, now
that 
the symptoms of the disease are well-known, isn't it that much more likely
to be 
diagnosed more quickly if it occurs in the future, even without changing
current 
FCS behaviour?

$0.02,

- Mark

Andrew G. Malis wrote:
> I agree with Peter, Shahram, Nick, and Dave - we should add the changes 
> summarized by Dave to add the option to both Ethernet and Frame Relay 
> drafts.  I don't think this has been mentioned yet, but we should add it 
> to the HDLC-PPP draft as well.
> 
> Thanks,
> Andy
> 
> --------
> 
> At 9/19/2003 12:48 PM -0400, Busschbach, Peter B (Peter) wrote:
> 
>> Luca,
>>
>> 2) I have seen efforts in other standardization bodies to push other 
>> packet switched solutions than MPLS because they claim 
>> MPLS-encapsulation is not transparent.
>>
>> Peter
>>

---

From: "Christopher N. \"Nick\" DelRegno" <[email-masked]>
Date: Tue, 23 Sep 2003 12:21:22 -0500

I agree that this does apply only to the "port-mode" encapsulation options
as any switching of VLANs, DLCIs, etc renders the customer FCS moot.
However, that doesn't mean that it is not important in the port modes.

I am very open to suggestions regarding other ways to ensure the reliabile
delivery of PW data end-to-end.  I DO NOT want to inspect packets at every
intermediate node.  I may, however, need to inspect packets at the egress to
ensure that PW transit was error-free.  I really don't want to rely on
customer phone calls to signal an error in the network.

Nick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart
Bryant
Sent: Monday, September 22, 2003 3:56 PM
To: Andrew G. Malis
Cc: PWE3 WG (E-mail)
Subject: Re: [PWE3] RE: re: pwe3-ethernet-encap - FCS... (redux)

Andrew G. Malis wrote:

> Stewart,
> 
> I have been recently been asked by more than one service provider for 
> this ability.  I'm sure others have been as well.   The real issue is 
> end-to-end assurance to the end customer that what is received is 
> identical to what was transmitted, and being able to match the 
> capabilities of alternative transports, such as GFP. 

Yes I know that the SP are asking their vendors for this. What I am
unclear about is why.

What is special about frame-relay over PW that did not apply to native
frame-relay, and does not apply to frame-relay over PW with DLCI
re-write?

What is special about ethernet over PW that does not apply to VLAN
over PW, or even VLAN native?

By carrying the FCS you only get the added protection in a subset of
the modes, and even then, I can speculate on a one bit memory error, or
a minor configuration error that will undo even that until it is too
late.

I am not saying that we should not do this, just that we should
understand the problem that we are trying to solve, the extent
to which this solves that problem, and the alternatives.

> I would rather not 
> have to implement this as a proprietary extension to the RFCs, although 
> in the end that's what will happen (and I'm sure by multiple vendors) if 
> necessary.

Nor would anyone.

> 
> Dave had a succinct summary of the necessary text.  Would it be 
> preferable to have a separate draft that defines the new interface 
> parameter TLV and LDP status value, and we simply modify the encaps 
> drafts to simply say that stripping the FCS on ingress is the default 
> action (rather than the required action)?  That way, only people that 
> implement the new draft need to test that particular functionality.
> 

No, if we do this, the right way is to add the text that Dave describes,
but lets also make sure that this is the necessary and sufficient
solution to the problem.

Stewart

> Thanks,
> Andy
> 
> -------
> 
> At 9/22/2003 08:19 PM +0100, Stewart Bryant wrote:
>

---

From: "David Allan" <[email-masked]>
Date: Tue, 23 Sep 2003 14:56:18 -0400

Lets frame this discussion slightly differently.....

Sources of problems detectable by carrying additional FCS

1) poor implementation or subtle fault in a PE. In this case carrying FCS in
the PW will not help for other than port mode (assuming the problem exists
prior to FCS computation). Don't think VCCV or other OAM probing will help
much here either ;-). So definite value add for port mode (coverage is
CE-to-CE). I assume the FCS is actually checked at both PEs (e.g. was it
right in the first place before PWing).

2) poor implementation or a subtle fault in a P. Carrying FCS in the PW will
detect this for all modes. OAM probes MAY (operative word being MAY) also be
corrupted by the same problem (along with a lot of other stuff). 

3) One in a million link error not detected by link checksum.....wow,
incredibly rare and not likely pathological, presumably carrying the
original FCS merely pushes out the overall hamming distance (or whatever
other metric for redundancy you choose to apply) and these "hell freezes
over" events are detected more often. 

I also read with some interest the paper that came up last time around
("When the IP and TCP checksums disagree") which is a direct analogy to the
problem situation we are discussing. IMHO there are lots of precedents for
e2e detection at any given layer.

cheers
Dave

> Sent: Tuesday, September 23, 2003 2:07 PM
> To: Christopher N. "Nick" DelRegno
> Cc: [email-masked]
> Christopher N. "Nick" DelRegno wrote:
> 
> > I agree that this does apply only to the "port-mode" encapsulation 
> > options as any switching of VLANs, DLCIs, etc renders the 
> customer FCS 
> > moot. However, that doesn't mean that it is not important 
> in the port 
> > modes.
> > 
> > I am very open to suggestions regarding other ways to ensure the 
> > reliabile delivery of PW data end-to-end.  I DO NOT want to inspect 
> > packets at every intermediate node.  I may, however, need 
> to inspect 
> > packets at the egress to ensure that PW transit was error-free.  I 
> > really don't want to rely on customer phone calls to signal 
> an error 
> > in the network.
> > 
> 
> You could also run VCCV from PE to PE. It will look to the 
> network just like a PW packet, but originates and terminates 
> on your PEs. The only exposure that you have is the path 
> through the input card to the switch fabric and the path from 
> the switching fabric to the ouput linecard. The picture can 
> then be completed by the customer running their own OAM 
> procedure which would test their interface to and from the PE fabric.
> 
> Stewart
> 
> > Nick
> > 
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of 
> > Stewart Bryant
> > the modes, and even then, I can speculate on a one bit 
> memory error, 
> > or a minor configuration error that will undo even that until it is 
> > too late.
> > 
> > understand the problem that we are trying to solve, the extent to 
> > which this solves that problem, and the alternatives.
> > 
> > 
> >>I would rather not
> > No, if we do this, the right way is to add the text that Dave 
> > describes, but lets also make sure that this is the necessary and 
> > sufficient solution to the problem.
> > 
> > Stewart
> > 
> > 
> >>Thanks,
> >>Andy
> >>
> >>-------
> >>
> >>>This is a small change to the specs and it is tempting to 
> just let it 
> >>>go by on the nod. However it does introduce some 
> complexity, in that 
> >>>it effects the control plane, the forwarding plane, gives rise to 
> >>>another set of interoperability tests, and is one more 
> parameter to 
> >>>configure at each end.
> >>>
> potentially 
> >>>detects one class of failure in a broken box, and then only when 
> >>>running in a simple repeater mode.
> >>>
> >>>Before just saying yes, I therefore think that we need to 
> do some due 
> >>>diligence on the idea by asking the following questions:
> >>>
> >>>Then we need to determine if the net gain is worth the 
> next cost, and 
> >>>act accordingly.
> >>>
> >>>Regards
> >>>
> >>>Stewart
> >>
> >>
> >>
> >>
> > 
> >