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

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 22 Sep 2003 13:56:20 -0400

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,
>
>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
>
> > -----Original Message-----
> > From: Luca Martini [mailto:[email-masked]]
> > Sent: Friday, September 19, 2003 12:05 PM
> > 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
> >
> >
> > Shahram Davari wrote:
> > > 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:
> > >>
> > >>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
> > >>
> > >>
> > >>_______________________________________________
> > >>pwe3 mailing list
> > >>[email-masked]
> > >>https://www1.ietf.org/mailman/listinfo/pwe3
> > >>
> > >
> > >
> > > _______________________________________________
> > > pwe3 mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/pwe3
> > >
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Sep 2003 20:19:15 +0100

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: "Andrew G. Malis" <[email-masked]>
Date: Mon, 22 Sep 2003 15:55:16 -0400

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.  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.

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.

Thanks,
Andy

-------

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Sep 2003 21:55:30 +0100

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

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 23 Sep 2003 10:43:56 +0200

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:
> drafts.  I don't think this has been mentioned yet, but we should add it 
> to the HDLC-PPP draft as well.
> 
> Thanks,
> Andy
> 
> --------
> 
>> packet switched solutions than MPLS because they claim 
>> MPLS-encapsulation is not transparent.
>>
>> Peter
>>

---

From: Ali Sajassi <[email-masked]>
Date: Tue, 23 Sep 2003 11:26:47 -0700

I'd also like to better understand the real advantage of adding the FCS 
option for Ethernet. We all know the disadvantages of it as pointed out 
earlier - e.g., standard Ether Phy/MAC chips don't support it, 
switches/bridges don't support it, additional hw/sw development and testing 
needed to support such feature, etc.

However, if the real advantage of FCS option is to provide some protection 
during PE forwarding, then majority of devices have certain protection 
mechanisms that can catch these error. Now, considering somewhere along the 
PE forwarding path under very rare conditions an error can happen that it 
can't be detected and that would be the reason for FCS option according to 
FCS proponent. However, I would argue that if the probability of occurrence 
of this error is similar to the probability of un-detected errors provided 
by 16-bit FCS, then we haven't accomplish much by carrying FCS across. 
That's why applications have their own FCS.

So before insisting on having FCS option, lets try to see how much do we 
gain by it. I wonder if this problem was of any significance, then we would 
have real problem with bridged LAN networks since the same argument applies 
there and we know that is not the case !!

-Ali