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

From: Eric Rosen <[email-masked]>
Date: Tue, 23 Sep 2003 14:38:09 -0400

Nick> In some cases, we have to demonstrate that we do not inspect or change
Nick> any customer information. 

How do you  demonstrate that you do not  "inspect" any customer information?
Presumably  if you  were to  send  the PWE3  packets on  an ethernet  during
transit, you'd have to compute a checksum for the encapsulated packet, which
would require inspection of the entire packet.

Nick> Some of these  customers DO NOT allow for the changing  of ANY bits in
Nick> the Ethernet frame. 

Well, the same FCS will get regenerated at the other end ;-)

Seriously,  I'm  not sure  I  understand  this  customer requirement,  taken
literally it would  seem to require that there be a  zero probability of bit
errors.  Or  are you saying that these  customers regard the FCS  as part of
the  customer information  that  should not  be  changed?  But  then if  the
customer put on a bad FCS, he'd want  you to present him with the bad FCS at
the  other end,  and you  wouldn't be  able to  use the  FCS  for diagnostic
purposes. 

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

End-to-end integrity  checking is always  important, but what  we're talking
about  here  is "edge-to-edge".   An  IP  datagram  may travel  through  the
networks  of  many providers,  but  each  provider  does not  perform  error
checking at its egress.  

Are your customers using protocols like LAT or Netbeui which depend entirely
on the ethernet FCS for their error checking?

Nick> I agree  that this  does apply only  to the  "port-mode" encapsulation
Nick> options 

It's difficult to see why port mode would need this if other modes do not. 

Nick> I really don't want to rely on customer phone calls to signal an error
Nick> in the network.  

The salient question  is: how much additional coverage do  you really get by
carrying the ethernet FCS across the PW?

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 23 Sep 2003 19:47:04 +0100

Christopher N. "Nick" DelRegno wrote:

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

This is what VCCV is designed to diagnose. Do you need it extended
to provide other facilities?

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

Firstly I would assume that if the user cared about reliability they were
checksumming their own packets.

Secondly if we feel the need to do more, we should do it for all modes
not port to port, because exactly the same arguments hold.

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

3) Run an end to end audit of the path

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

for port to port mode only

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

Under non-fault conditions you will not change them. Under fault
conditions all bets are off anyway.

How do you avoid inspection on native packets in a packet network?

> As such, today, one
> has to either provision separate physical connections for those customers or
> use a non-standard encapsulation mechanism.  

Don't you really need to run IPsec to get the level of opaqueness
and integrity that you are looking for?

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

Stewart

> 
> -----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,
>>>
>>>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
>>
>>
>>
>>_______________________________________________
>>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: Wed, 24 Sep 2003 08:19:49 +0100

Please can we park the proposed solutions for a while
and agree on the requirements.

As I understand the requirements they are:

1) Packet at egress must be identical to packet at ingress.

2) Frames delivered across the PW with the same probability
of undetected error as provided by the CRC of the originating
packet.

3) Customer traffic must not be inspected.

4) The network operator to be able to detect errors in PW traffic
induced by their network at same time, or before the customer
detects.

5) Mechanism to detect the problem must be confined to the PE.

Non-requirements

6) Requirements 1..5 do not apply to non-port mode services.

My questions:

a) Have I stated the above requirements correctly?

b) Are there any additional requirements?

c) Are there any additional non-requirements?

d) Why item 6?

Stewart