Subject: pwe3-ethernet-encap - FCS (requirements)

From: Scott Kotrla <[email-masked]>
Date: Wed, 24 Sep 2003 14:00:35 -0500

Stewart,
 
I'd rephrase 3 to say "modified."  Inspecting for errors in the SP
network is part of offering an SLA.
 
I think 6 is not necessarily always true.  1-5 may not apply to services
where VLANs are locally significant because I am doing aggregation at
the VLAN layer.  However, I may do a VLAN-tagged PW mapping and have no
need to rewrite the VLAN tag anywhere, meaning that I am never having to
change the customer packet, similar to a port mode mapping.  Here's an
example:
 
VLAN1-----PE1__________P__________PE2-----VLAN1
VLAN2                  |
                       |
                       |
                       |__________PE3-----VLAN2
 
Coming into a port on PE1, VLAN1 could be mapped to a PW on an LSP to
PE2, while VLAN2 could be mapped to a PW on an LSP to PE3.  Even though
this is not a port-mode mapping, I see no reason why maintaining the FCS
here would be any different than maintaining the FCS in a port-mode
mapping.
 
I would reword 6 to say:
 
6) Requirements 1-5 do not apply to all non-port mode services, but they
can apply in certain instances, depending on service architecture.
 
Thanks,
 
Scott
 
-----Original Message-----
1) Packet at egress must be identical to packet at ingress.
 
2) Frames delivered across the PW with the same probability
of undetected error as provided by the CRC of the originating
packet.
 
3) Customer traffic must not be inspected.
 
4) The network operator to be able to detect errors in PW traffic
induced by their network at same time, or before the customer
detects.
 
5) Mechanism to detect the problem must be confined to the PE.
 
Non-requirements
 
6) Requirements 1..5 do not apply to non-port mode services.
 
My questions:
 
a) Have I stated the above requirements correctly?
 
b) Are there any additional requirements?
 
c) Are there any additional non-requirements?
 
d) Why item 6?

---

From: "David Allan" <[email-masked]>
Date: Thu, 25 Sep 2003 09:05:08 -0400

I think it is useful to capture the requirements, BUT a brief analysis can
only draw ONE conclusion w.r.t. the solution space:

If the goal is to ensure that requirement 1 is met, then a means of auditing
the PE transfer functions needs to exist. This means the audit mechanism
must be be able to compare what was received by the ingress from a CE and
sent by the egress to a CE. Ideally the terminating CE is the final arbiter
of the success of the transfer functions. This drastically limits the set of
solutions to what is already on the wire....aka the FCS of the service
tunneled over the PW.

If we agree that carrying the FCS across the PW ONLY has utility when the
PEs do not re-write any fields in the datagram (we trust the P LSRs) then
this suggests port mode for FR and any variation of Ethernet in which the
payload (including any q tags) are transferred untouched.

cheers
Dave

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 25 Sep 2003 09:57:33 -0400

> From: David Allan [mailto:[email-masked]]
> Sent: Thursday, September 25, 2003 9:05 AM
> To: 'Scott Kotrla'; 'Stewart Bryant'
> Cc: [email-masked]
> Subject: RE: [PWE3] pwe3-ethernet-encap - FCS (requirements)
> 
> 

Dave,

Does this mean that a Service Provider who wants to offer a fully transparent VPWS cannot add a Service Delimiting VLAN tag on the Attachment Circuit?

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

---

From: "David Allan" <[email-masked]>
Date: Thu, 25 Sep 2003 10:49:37 -0400

Hi Peter:

Good point, I'll rephrase ;-)

If we agree that carrying the FCS across the PW ONLY has utility when the
PEs do not modify any fields in the datagram received from the ingress CE
prior to presentation to the egress CE (we trust the P LSRs), then this
suggests port mode for FR and any variation of Ethernet in which the payload
sent by the ingress CE (including any q tags) are transferred untouched.

cheers
Dave

> From: Busschbach, Peter B (Peter) [mailto:[email-masked]] 
> Sent: Thursday, September 25, 2003 9:58 AM
> To: Allan, David [CAR:NS00:EXCH]; 'Scott Kotrla'; 'Stewart Bryant'
> Cc: [email-masked]
> Does this mean that a Service Provider who wants to offer a 
> fully transparent VPWS cannot add a Service Delimiting VLAN 
> tag on the Attachment Circuit?
> 
> Peter
> > 
> > cheers
> > Dave
> >

---

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Thu, 25 Sep 2003 11:21:50 -0400

Thanks, Dave.

Just to be clear: the words "transferred untouched" should be interpreted as: the native frame shall not be modified nor shall additional tags be added.

I am not trying to be overly precise, but I personally had never realized that the use of Service Delimiting tags is incompatible with end-to-end transparancy.

Peter

> Sent: Thursday, September 25, 2003 10:50 AM
> To: 'Busschbach, Peter B (Peter)'; 'Scott Kotrla'; 'Stewart Bryant'
> Cc: [email-masked]