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

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

Christopher N. "Nick" DelRegno wrote:
> I agree that this does apply only to the "port-mode" encapsulation options
> as any switching of VLANs, DLCIs, etc renders the customer FCS moot.
> However, that doesn't mean that it is not important in the port modes.
> 
> I am very open to suggestions regarding other ways to ensure the reliabile
> delivery of PW data end-to-end.  I DO NOT want to inspect packets at every
> intermediate node.  I may, however, need to inspect packets at the egress to
> ensure that PW transit was error-free.  I really don't want to rely on
> customer phone calls to signal an error in the network.
> 
> Nick
> 

You could also run VCCV from PE to PE. It will look to the network just
like a PW packet, but originates and terminates on your PEs. The only
exposure that you have is the path through the input card to the switch
fabric and the path from the switching fabric to the ouput linecard.
The picture can then be completed by the customer running their
own OAM procedure which would test their interface to and from the
PE fabric.

Stewart

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart
> Bryant
> Sent: Monday, September 22, 2003 3:56 PM
> To: Andrew G. Malis
> Cc: PWE3 WG (E-mail)
> Subject: Re: [PWE3] RE: re: pwe3-ethernet-encap - FCS... (redux)
> 
> 
> 
> Andrew G. Malis wrote:
> 
> 
>>Stewart,
>>
>>I have been recently been asked by more than one service provider for 
>>this ability.  I'm sure others have been as well.   The real issue is 
>>end-to-end assurance to the end customer that what is received is 
>>identical to what was transmitted, and being able to match the 
>>capabilities of alternative transports, such as GFP. 
> 
> 
> Yes I know that the SP are asking their vendors for this. What I am
> unclear about is why.
> 
> What is special about frame-relay over PW that did not apply to native
> frame-relay, and does not apply to frame-relay over PW with DLCI
> re-write?
> 
> What is special about ethernet over PW that does not apply to VLAN
> over PW, or even VLAN native?
> 
> By carrying the FCS you only get the added protection in a subset of
> the modes, and even then, I can speculate on a one bit memory error, or
> a minor configuration error that will undo even that until it is too
> late.
> 
> I am not saying that we should not do this, just that we should
> understand the problem that we are trying to solve, the extent
> to which this solves that problem, and the alternatives.
> 
> 
>>I would rather not 
>>have to implement this as a proprietary extension to the RFCs, although 
>>in the end that's what will happen (and I'm sure by multiple vendors) if 
>>necessary.
> 
> 
> Nor would anyone.
> 
> 
>>Dave had a succinct summary of the necessary text.  Would it be 
>>preferable to have a separate draft that defines the new interface 
>>parameter TLV and LDP status value, and we simply modify the encaps 
>>drafts to simply say that stripping the FCS on ingress is the default 
>>action (rather than the required action)?  That way, only people that 
>>implement the new draft need to test that particular functionality.
>>
> 
> 
> No, if we do this, the right way is to add the text that Dave describes,
> but lets also make sure that this is the necessary and sufficient
> solution to the problem.
> 
> Stewart
> 
> 
>>Thanks,
>>Andy
>>
>>-------
>>
>>At 9/22/2003 08:19 PM +0100, Stewart Bryant wrote:
>>
>>
>>>This is a small change to the specs and it is tempting to just let
>>>it go by on the nod. However it does introduce some complexity, in
>>>that it effects the control plane, the forwarding plane, gives
>>>rise to another set of interoperability tests, and is one more
>>>parameter to configure at each end.
>>>
>>>The only use that I can see for the mechanism is that it
>>>potentially detects one class of failure in a broken box, and then
>>>only when running in a simple repeater mode.
>>>
>>>Before just saying yes, I therefore think that we need to do
>>>some due diligence on the idea by asking the following questions:
>>>
>>>1) What level of increased fault coverage do we actually get?
>>>
>>>2) Is there a simpler mechanism of achieving the same fault coverage?
>>>
>>>Then we need to determine if the net gain is worth the next cost,
>>>and act accordingly.
>>>
>>>Regards
>>>
>>>Stewart
>>
>>
>>
>>
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
>

---

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

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 24 Sep 2003 11:57:16 +0100

<snip>

> I may, however, need to inspect packets at the egress to
> ensure that PW transit was error-free.

<end snip>

Nick

Do you need this to be a PW function, or is it something
that you as an SP would do outside the PW sub-system,
(by for example sniffing the packets delivered to the
customer)?

Stewart