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

From: Eric Rosen <[email-masked]>
Date: Mon, 27 Oct 2003 16:01:35 -0500

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

---

From: Danny McPherson <[email-masked]>
Date: Mon, 27 Oct 2003 16:08:12 -0700

> that having  this option would  add complexity without actually  

Yes, this is what I observed.

> draft so  that it can advance  (or not) on  its own, without holding  

I like this idea.  I see that Andy and Dave have volunteered,
so perhaps we can consider this issue addressed.

-danny

---

From: "Christopher N. \"Nick\" Del Regno " <[email-masked]>
Date: Mon, 27 Oct 2003 16:51:50 -0600

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.

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 27 Oct 2003 17:55:34 -0500

Eric,

>draft so  that it can advance  (or not) on  its own, without holding  up the

I think that's a fine solution. We'll have a separate draft that defines a 
new interface parameter TLV for included FCS and an LDP status value for 
"non-supported FCS option".  We will still need to very slightly modify the 
current Ethernet encaps draft to simply say that stripping the FCS on 
ingress is the default action (rather than the required action).

Dave and I will be happy to co-author the new draft, which we can have out 
in short order, when the new draft blackout is lifted following the 
Minneapolis meeting.

Thanks,
Andy

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 27 Oct 2003 18:14:37 -0500

Danny,

We're working on it now ... :-)

Remember that this requires a slight modification of the current Ethernet 
encaps draft to simply say that stripping the FCS on ingress is the default 
action rather than the required action.

Thanks,
Andy

---------