Subject: RE: last call on control and ethernet drafts

From: Scott Kotrla <[email-masked]>
Date: Wed, 12 Nov 2003 15:12:41 -0700

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:[email-masked]] 
Sent: Wednesday, November 12, 2003 2:39 PM
To: Scott Kotrla
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] last call on control and ethernet drafts

(I may have had HTML reenabled previously by mistake - my apologies if I
did). 
 
" <snip> Scott Kotrla <[email-masked]> 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.
 
" <snip> 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.

---

From: mark seery <[email-masked]>
Date: Wed, 12 Nov 2003 14:33:14 -0800

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: Ali Sajassi <[email-masked]>
Date: Wed, 12 Nov 2003 22:25:23 -0800

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:
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

---

From: mark seery <[email-masked]>
Date: Thu, 13 Nov 2003 00:16:44 -0800

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