Subject: RE: last call on control and ethernet drafts.

From: "David Allan" <[email-masked]>
Date: Mon, 27 Oct 2003 10:21:47 -0500

IMHO sufficient case has been made for inclusion of the option to carry
native FCS e2e for Ethernet and FR. This requires changes to the control,
Ethernet and FR drafts that are not currently reflected in the drafts in
last call. 

I cannot support the drafts going forward as they stand.

cheers
Dave

---

From: "David Allan" <[email-masked]>
Date: Mon, 27 Oct 2003 14:42:45 -0500

Eric:

Perhaps the chairs should encourage a bit more genetic diversity in the
respondents before making a decision. ;-)

Dave

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]] 
> Sent: Monday, October 27, 2003 10:46 AM
> To: Allan, David [CAR:NS00:EXCH]
> Cc: 'Danny McPherson'; [email-masked]
> Subject: Re: [PWE3] last call on control and ethernet drafts. 
> 
> 
> 
> > IMHO sufficient case has been made for inclusion of the option to 
> > carry native FCS e2e for Ethernet and FR.
> 
> Are you claiming that there is a consensus in favor of that?  
> I hardly think so, but of course the chairs will decide. 
> 
> 
> 
> 
> 
>

---

From: Mark Seery <[email-masked]>
Date: Mon, 27 Oct 2003 12:11:49 -0800 (PST)

As a data point, non-PWE Ethernet transport applications I have been involved
in have not always seen it necessary to burn bandwidth on carrying the FCS e2e
depending on a) what other error checking was contained in the underlying
transport protocol b) the scarcity of bandwidth on the access links. The
problem occurs on lower-speed links (say below 2 Mbps) where you are already
adding overhead via transport headers (and potentially fragmentation headers)
and you are trying to bound latency, head of line blocking,......

but I haven't followed the discussion on this subject in this WG so just a data
point.....

-mark

--- David Allan <[email-masked]> wrote:
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Matt Squire" <[email-masked]>
Date: Mon, 27 Oct 2003 18:26:52 -0500

> 
> > If it's not in the RFC, then it'll end up being implemented as 
> > a proprietary feature. 
> 
> My suggestion then  would be to write up this option  as a 
> separate internet
> draft so  that it can advance  (or not) on  its own, without 
> holding  up the
> base spec.   
> 

Here's another voice in favor of Eric's suggestion.  Let it live or die on its own, and let the base capabilities move forward quickly.

- Matt

---

From: Scott Kotrla <[email-masked]>
Date: Mon, 27 Oct 2003 17:59:48 -0600

Equipment providers are fairly biased in their feelings here, since it
is based on the capabilities (or lack thereof) of existing hardware.
Hence we have equipment providers both for and against the changes to
the draft.  

Service providers would seem to be less biased, and it seems like
service providers are in favor of the addition to the draft.  Unless
there are service providers against keeping the FCS, it would seem like
it's a pretty simple decision.  Not adding a feature required to make
the draft usable because some vendors' existing hardware doesn't support
it seems like a bad decision for everybody.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Christopher N. "Nick" Del Regno 
Sent: Monday, October 27, 2003 4:52 PM
To: [email-masked]; 'Andrew G. Malis'
Cc: 'David Allan'; 'Danny McPherson'; [email-masked]
Subject: RE: [PWE3] last call on control and ethernet drafts.

The last thing I remember was that we were going to table the
discussions
and allot some time during the Nov. IETF PWE session. Now, with the
proposed
last call for these effected drafts, we need to raise the issue again. 

1)  While I have tried to explain why we, as a service provider, need to
retain the L2 FCS (Ethernet and Frame Relay), I haven't seen any details
on
the testing complexity assertion; only the assertion itself.  I would
think
that those implementations which cannot retain the FCS would have two
behaviors: a) if LDP indicates no FCS retention, then the PW is setup,
or b)
if LDP indicates FCS retention, the PW is rejected. If this is the case,
then the implementation would be considered compliant. Further, only a
single additional Interface Parameter is required, limiting the impact
on
the testing associated with the PW control protocol. 

2)  I certainly understand the need to freeze a standard at some point
in
order to have a stable document to take to a standard. However, as the
changes proposed are relatively minor in nature, and apply to 3 drafts
in
the same stage of standardization, it seems to be more sensible to
include
these enhancements now instead of creating 3 new drafts/RFCs shortly
after
the originals are final. 

3)  Providing an E2E checksum is not new. If one considers traditional
IP
networking, we don't trust the network to deliver packets without error.
While IP has a checksum, it only protects the header. As such, both TCP
&
UDP have a packet checksum to protect the payload. If, as some have
contended, the routing equipment is reliable, then an E2E checksum would
not
be required since there is error detection on the wire thanks to the
Layer 2
protocol. If we were to follow the example of TCP & UDP, then we should
propose a checksum for the pseudo wire, either as a FCS trailer or
within a
control word, since there is no checksum (header or payload) in MPLS and
PWE3. I am not suggesting this. I am only suggesting that by retaining
the
FCS which is already present on ingress, I can achieve my E2E error
check
requirements without dramatically changing the protocol. 

4) If memory serves, and it may not, I didn't see any SPs voicing
opposition
to this, except of course for Luca, who is now at Cisco.  Andy has
referenced other SPs asking for FCS retention as well. From what I can
remember, it was primarily a vocal equipment manufacturer voicing
objection.

5) I know of at least 4 equipment providers who can/do support this in
existing hardware. Should this be added to the drafts, then example
implementations for RFC approval should not be an issue either. 

We should not proceed to Last Call, much less RFC, until this is
settled,
one way or the other, through active discussion/debate instead of what
is
effectively a pocket veto. 

Regards, 
Nick Del Regno 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
Rosen
Sent: Monday, October 27, 2003 3:02 PM
To: Andrew G. Malis
Cc: David Allan; 'Danny McPherson'; [email-masked]
Subject: Re: [PWE3] last call on control and ethernet drafts.

> I think there was enough positive response to this on the list to at
the 
> very least include this as an optional capability

As I recall,  there was an equal amount of negative  response on the
grounds
that having  this option would  add complexity without actually  solving
the
stated problem. 

> If it's not in the RFC, then it'll end up being implemented as 

My suggestion then  would be to write up this option  as a separate
internet
draft so  that it can advance  (or not) on  its own, without holding  up
the
base spec.

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 28 Oct 2003 10:17:02 +0200

Nick and all,
Please see a couple of comments inline.
Hopefully they will useful.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Christopher N. "Nick" Del Regno [mailto:[email-masked]]
> Sent: Tuesday, October 28, 2003 12:52 AM
... snipped ...
>
> 1)  While I have tried to explain why we, as a service 
> provider, need to retain the L2 FCS (Ethernet and Frame Relay), 
>
The current FR draft supports two modes: one-to-one (default) and port.
In the one-to-one mode the FR header is stripped at the PW ingress
and regenrated (including a possible DLCI value swap) so that only 
FR payload and signaling bits (C/R, DE, FECN and BECN) are carried 
over the PW with the latter being carried in the PW CW. 
IMO, this means that carrying the native FR FCS in this
mode is meaningless. It is only applicable to the FR PW port
mode which is at the moment OPTIONAL.

I'd like to remind you that this has been one of the most
contentious issues with the FR draft (which originally
did not have the port mode at all), and that the current
text seems to reflect the WG consensus in this regard.

Hence I'd like to understand whether your statement above 
should be interpreted as "we, as a SP, cannot use the 
FR PWs in the one-to-one mode"? And if so, whether this
is a consensus among the SPs on that?

The current Ethernet draft supports sevefal modes including
raw mode that strips service delimiting VLAN tags at ingress
and regenerates them (with posssible VLAN ID swapping) at egress. 

As above, carrying the native Ethernet FCS in this mode 
is meaningless (I believe this has been noted in one of the 
previous email threads on the subject). The current text
does not seem to specify whether this mode is mandatory or
optional. But It would be nice to understand whether your
statement should be reinterpreted wrt to this mode.

... snipped ...
> 3)  Providing an E2E checksum is not new. If one considers 
> traditional IP
> While IP has a checksum, it only protects the header. As 
> such, both TCP &
> UDP have a packet checksum to protect the payload. 
>
Note that UDP has an option for disabling the checksum mechanism, and,
AFAIK, this option is widely deployed.
... snipped to the end ...

---

From: Akiva Sadovski <[email-masked]>
Date: Tue, 28 Oct 2003 10:44:01 +0200

Sasha,Nick and all,
  please see my brief comment inline

thanks,
  Akiva Sadovski

> From: Sasha Vainshtein 
> Sent: Tuesday, October 28, 2003 10:17 AM
> To: 'Christopher N. "Nick" Del Regno '
> Cc: 'David Allan'; 'Danny McPherson'; [email-masked]; 'Andrew 
> G. Malis'; [email-masked]
  IMHO we have the same problem with the FR PW port mode. From
draft-ietf-pwe3-frame-relay-01.txt:
<quote>
FR port mode provides transport between two PEs of a complete FR
frame excluding the opening and closing flags and the Frame check
sequence (FCS) and with bit/byte stuffing undone."
<endquote>
we'll have to slightly modify the current FR draft to "prevent" FCS
stripping
in port mode... As well as ITU-T X.84.

---

From: "Christopher N. \"Nick\" Del Regno " <[email-masked]>
Date: Tue, 28 Oct 2003 08:48:23 -0600

While carrying the FCS has the most obvious meaning in the port modes of FR
and Ethernet encapsulation, it has less meaning in VLAN and DLCI mode, but
not necessarily none. For Frame Relay, port mode is of greatest interest
since I don't have to worry about terminating my customer's LMI. As such,
retaining my customer's FCS is of great interest to me because it allows me
to have a level of error checking as I reassemble the frames upon egress.
Further, in DLCI mode where I am not changing the DLCI upon egress, I can
similarly check the validity of the frame. In the case where I translate the
DLCI upon PW egress, the FCS can no longer be used as an end-to-end error
check, and therefore has little value. 

Similarly, Ethernet port mode is of great interest to me as it allows me to
tunnel all of the customer's VLANs to my service edge, reducing the
complexity of the aggregating network and its associated provisioning.
Again, maintaining the FCS has meaning as an error detection mechanism. 

To answer your inline question, we will use different modes in different
parts of the network. In the core, one-to-one can be used to connect
regional frame relay switches together without the need to main LMI
adjacencies. In an aggregation network, we will use port mode to maintain
the LMI adjacency between my customer device and my Frame Relay service
edge. When connecting a customer to an IP edge router, we would use port
mode to maintain LMI as well as to simplify provisioning. This is true for
Ethernet as well except for the LMI of course. 

I would recommend that if FCS retention is not optional in the base draft
then for port mode for both Ethernet and FR, the FCS be kept by default.
Otherwise the ingress and egress PEs have to do far more packet processing
(stripping and calculating the new FCS, respectively) than is required for
what is essentially a "trunk" connection. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sasha
Vainshtein
Sent: Tuesday, October 28, 2003 2:17 AM
To: 'Christopher N. "Nick" Del Regno '
Cc: 'David Allan'; 'Danny McPherson'; [email-masked]; 'Andrew G. Malis';
[email-masked]
Subject: RE: [PWE3] last call on control and ethernet drafts.

Nick and all,

With best regards,
                                   Sasha Vainshtein

... snipped ...

... snipped ...