Subject: RE: last call on control and ethernet drafts

From: Scott Kotrla <[email-masked]>
Date: Sun, 09 Nov 2003 22:42:36 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of Ali
Sajassi
Sent: Friday, November 07, 2003 9:33 PM
To: Luca Martini; [email-masked]
Cc: [email-masked]; 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
>>>[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: Ali Sajassi <[email-masked]>
Date: Mon, 10 Nov 2003 21:16:33 -0800

>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

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