Subject: RE: RE: [802.1] 802.1ad Customer FCS Retention

From: Ali Sajassi <[email-masked]>
Date: Mon, 01 Dec 2003 00:12:38 -0800

Neil,

Please refer to the comments in line ...

At 08:53 PM 11/26/2003 +0000, [email-masked] wrote:
>Hi Ali,
>
>Ali Sajassi wrote 26 November 2003 20:10
><snip>
> >
> > >-       the lesson that I take away from the above
> > observations is that
> > >architecturally it makes more sense to have 2 different
> > CRCs, (i) one
> > >protecting only the CI that goes between trail term points
> > transparently
> > >(ie never changes on link-connections) and (ii) one
> > protecting only the
> > >link-connection specific part of the client traffic unit
> > that can change
> > >on link-connections (so this needs a linear update per link
> > connection).
> >
> > So in the context of our discussions, given that the PEs are
> > intended to
> > provide transport functionality with respect to Ethernet
> > services and not
> > interworking, then it means any FCS to be added for the CI
> > portion is the
> > job of the CE and not the PE - this is analogous to ATM and
> > FR transport
> > where you don't expect the ATM switch or FR switch to add a
> > CRC for the
> > payload.
>NH=> I tend to think in terms of G.805 func arch and not boxes, ie it is 
>the func arch (eg where layer networks start and end) that is most 
>important, not a 'CE' or 'PE' badge.  I look at this stuff very 
>simply:  The FCS of eth belongs to the traffic unit of the eth layer 
>network....not any other layer network.

Based on your previous suggestion, there should be two FCS - one for the CI 
data and the other for link layer. Well, bridges take care of the FCS for 
the link layer and that makes sense since VLANs can be manipulated by the 
bridges (add/deleted) and they can serve as service delimiter. So any FCS 
that needs to be added for CI portion should be done by the client-layer 
application similar to 1483/1490 encap.

>   Where the eth client gets encapsulated (let's say in MPLS) is where the 
> LSP trail starts (this can be any box)....and there is an LSP trail term 
> point where they get decapsulated. (Yes I know folks also add a PW header 
> but this is not a layer network, simply an adaptation function).  This is 
> simply client/server encapulation and well defined in G.805.  If we carry 
> the eth clinet over any server layer, you mentioned ATM or FR (but I 
> could also add PDH, SDH, etc), then exactly the same applies.

No PDH and SDH are different. These are port-based Ethernet service; 
whereas, I was talking about vlan-based services (e.g., each VLAN is a VC) 
and making analogy between VLAN-id in Ethernet and DLCI in FR or VPI/VCI in 
ATM.

>NH=> This, I think, is the key issue of contention Ali (and why various 
>people see the situation differently).  If we take the LLC/MAC split then 
>you have a valid point.  It's also pretty similar (if you think about it) 
>to the ATM_cell/AAL_X split.  However, I would tend to look at the LLC/MAC 
>as 'joined at the hip' sub-layers, ie they must go together...and I don't 
>know of any std which allows the LLC part to sent on anything without its 
>MAC part (but please correct me if you know otherwise).

LLC is basically used for management and control traffic (e.g., xSTP, GxRP, 
LLDP, etc.) and NOT for data traffic. The data traffic that gets switched 
in a bridge doesn't go through LLC sub-layer. Given that the customer data 
only gets switched through the bridge and doesn't get terminated by the 
bridge, hence my point of a bridge only being responsible at the MAC layer 
for the customer data.

>  There is not the same binding IMO between the ATM_cell and the 
> AAL_X.....I can easily imagine AAL_X being carried over some other server 
> layer network....and in fact Yaakov S has considered this for AAL1 (TDM) 
> over MPLS for example.

All I am trying to point out is that there is a difference between FCS for 
CI and FCS for the link layer. In case of FR, you can have these two FCSs 
and the FCS for the CI portion is responsibility of the application that 
does the encapsulation and not the FR switch that does the switching.

>The fact folks are now proposing to send the eth frames over WAN 
>technologies is a problem of our making, not the orgins of eth with how it 
>viewed what would be the MAC layer.....so these aspects were never clearly 
>diveroced or considered before AFAIK.  And which is why on balance, I 
>still err of the side of caution with the view that the FCS should be 
>carried as the default behaviour.

Which FCS :-)

Regards,
Ali

>regards, Neil
><snipped to end>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 01 Dec 2003 09:56:38 +0000

Sasha

>>Perhaps the best way for a customer to validate the PW is
>>with an OAM protocol that runs between the CEs, rather than
>>trying to discover the problem implicitly through the FCS?
>>
> 
> [Sasha] I am not sure this is the correct approach since it would mean
> that the customer is aware of the fact that connection between CE devices
> passes through a PW and has to modify CEs accordingly.  
> 

The customer is of course aware of the connection, because they
are buying a CE to CE link. One of the purposes of an OAM is to
audit and diagnose a link, and that is what it would be doing.
The difference is that with an OAM they would be diagnosing the
problem explicitly, and not implicitly.

Stewart

---

From: [email-masked]
Date: Mon, 1 Dec 2003 11:59:23 -0000

Hi Ali.....just a small remark.  regards, Neil

Ali Sajassi wrote 01 December 2003 08:13
<snipped>
> and making analogy between VLAN-id in Ethernet and DLCI in FR 
NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), DLCI (FR) or a 'label' (MPLS) are all examples of link-connection identifiers.  These entities have no network currency until/unless they are associated with some parent trail entity (no matter how that is created).  A VLAN ID is not a link-connection identifier.  It is more like a 'name', in that it subdivides the total MAC address population into contained sub-spaces of MAC addresses (that belong to a given VLAN).  I suppose it could be used in other ways, but that is my understanding of its native architectural significance.

regards, Neil
<snipped

---

From: [email-masked]
Date: Mon, 1 Dec 2003 15:08:55 -0000

Stewart,

Stewart wrote 01 December 2003 13:37
<snipped>
> > NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), 
> > DLCI (FR) or a 'label' (MPLS) are all examples of link-connection 
> > identifiers.  These entities have no network currency until/unless 
> > they are associated with some parent trail entity (no matter 
> > how that is created).  
> 
> Here you are talking about the inner label. The outer label
> would normally be an abbreviation for an IP address.
NH=> I think we need a better explantion as to what is actually going on here.  All co-ps/cs technologies work in essentially the same way.  If we take the largest subnetwork (G.805 sense) then the network access points are where it's addresses are located.  These are also intrinsically bound to trail termination functions.  The link-connections in co-ps/cs networks use labels that only have local (link) signficance.  When a trail is established between the network addressed access points than a series of concatenated link-connections and subnetworks (the smallest subnetwork being a node/switch in the technology of relevance) is created.....the link-connection IDs have no network currency before this, ie they sit in a pool waiting to be allocated (and are reuturned to the pool when the trail is torn-down).  So in all co-ps/cs technologies then 'yes' one could say a label points to some distant access point address.....and since the labels are a series of related/concatenated links then this pointing to a distant destination address carries all the way to the access point at the trail source.

This is also why mp2p is a deprecated topology in the co-ps/cs modes.....though in the co-cs mode you simply can't physically create this violation, but you can force it in the co-ps mode.  Merging means we have lost transparency and integrity of the CI, ie we no longer uniquely know the source.  Which is why we are forced to run an extra p2p LSP above the mp2p construct to recover from the arch violation of this mode.  So the fact that the semantics of the label (ie inner vs outer) is now altered is simply a consequence of this arch violation.  Also note that IP belongs to the cnls mode and never has this problem....that is, the cnls mode always muxes and never merges....why?...because each traffic unit carries the full network DA/SA pair.....and that is indeed the signature of the cnls mode.
> 
> > A VLAN ID is not a link-connection 
> > identifier.  It is more like a 'name', in that it 
> > subdivides the total MAC address population into contained 
> > sub-spaces of MAC addresses (that belong to a given VLAN).  
> 
> Isn't it a virtual network identifier.
NH=> Yes, that was my point above saying it is a more like a 'name'....its not a link-connection ID in the same sense as VPI/VCI, DLCIs and MPLS labels are.

Stewart....I think we are wandering off topic now....so if this is to continue I suggest we change the title.

regards, Neil

---

From: Ali Sajassi <[email-masked]>
Date: Mon, 01 Dec 2003 11:33:54 -0800

Hi Neil, Hopefully my last comment on this subject :-) regards,Ali

At 11:59 AM 12/1/2003 +0000, [email-masked] wrote:
>NH=> I don't think this analogy is valid.  A VPI/VCI (ATM), DLCI (FR) or a 
>'label' (MPLS) are all examples of link-connection identifiers.  These 
>entities have no network currency until/unless they are associated with 
>some parent trail entity (no matter how that is created).  A VLAN ID is 
>not a link-connection identifier.

Maybe we should first reach agreement on the type of Ethernet services 
before discussing the mechanisms to take care of these services. Both EVPL 
and EVPLAN services (based on MEF and ITU documents) use VLAN as service 
delimiter (connection identifier) to support muxed UNI just like FR and ATM.

>  It is more like a 'name', in that it subdivides the total MAC address 
> population into contained sub-spaces of MAC addresses (that belong to a 
> given VLAN).  I suppose it could be used in other ways, but that is my 
> understanding of its native architectural significance.

Not really. VLAN-id doesn't necessary divide the MAC address space.  Each 
VLAN-id can make use of the entire MAC address space in the IVL mode and 
IVL mode is the one that to be used to guarantee the independent operations 
of different services multiplexed over the  same UNI.

-Ali

---

From: [email-masked]
Date: Mon, 1 Dec 2003 10:49:49 -0700

Most traffic already has two levels of protection - though one is a checksum rather than a CRC. While VLAN tags weren't contemplated in the initial development of Ethernet, routers were. The appropriate layer for end-to-end protection is the network layer (or higher such as iSCSI's CRC or TCP checksum) and not the link layer. Even if one had a second CRC, I doubt that one could guarantee over time that there would be no other changes made to the packet. For example, there could be cases where the MAC address is translated or layer 3 funcionality could change MAC address and IP fields.

The MAC isn't the right place to add the protection being asked for. With the stated concern being checking for equipment malfunction rather than extreme high confidence of detecting every altered packet, checksums are good enough.

Pat

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Ali Sajassi
Sent: Wednesday, November 26, 2003 12:11 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention

Hi Neil,

At 10:26 AM 11/26/2003 +0000, [email-masked] wrote:
>Hi Ali,
>
>The way I would answer (some of) your questions is as follows:
>
>-       according to the func arch draft Rec (G.8010) being developed for 
>ethernet, the eth FCS belongs to the link-connection adaptation 
>function.....not the end-end (ie between eth flow trail term points) 
>characteristic information.  You may recall Juergen corrected me on this a 
>couple of days ago.
>
>-       this means if any of the traffic unit that is covered by the FCS 
>changes at a link-level then the FCS will need to be updated to reflect 
>the changes.  CRCs are linear functions, and it can shown mathematically 
>that a known change to specific bits in the traffic unit can be corrected 
>by an update of the FCS and only the FCS, ie there is no need to 
>recalculate the FCS over the entire traffic unit.  This is no different in 
>principle to the HEC function that protects the ATM header (but only the 
>ATM header) since the VPI/VCI label usually changes on 
>link-connections.  One can consider the eth VLAN field in a similar 
>manner, ie known changes to the VLAN field can be reflected as updates of 
>the FCS.

Yes and this is the intended mechanism for bridges and it is reflected in 
Appendix F of 802.1D as I mentioned in one of my previous emails.

>-       the lesson that I take away from the above observations is that 
>architecturally it makes more sense to have 2 different CRCs, (i) one 
>protecting only the CI that goes between trail term points transparently 
>(ie never changes on link-connections) and (ii) one protecting only the 
>link-connection specific part of the client traffic unit that can change 
>on link-connections (so this needs a linear update per link connection).

So in the context of our discussions, given that the PEs are intended to 
provide transport functionality with respect to Ethernet services and not 
interworking, then it means any FCS to be added for the CI portion is the 
job of the CE and not the PE - this is analogous to ATM and FR transport 
where you don't expect the ATM switch or FR switch to add a CRC for the 
payload.

>-       When ethernet was first designed the above issues were never 
>considered....and in particular there was no VLAN field.  We cannot now go 
>back and change this IMO.  However, the FCS does still belong to the eth 
>client and IMO it should never be discarded in some arbitrary manner by a 
>server layer.  I use the word 'arbitrary' here since I have noted 
>different behaviours specified in G.8010 which I don't think is a good 
>idea, eg for all co-cs server technologies the carriage of the eth FCS is 
>a 'must', for an ATM co-ps server layer the carriage of the FCS is 
>'optional', and for an MPLS co-ps server it currently says it can be 
>'removed'.  A client and server layer network should be independent.....so 
>having different behaviours dependent on the server layer mode and/or 
>specific technology is not a logical behaviour to me.  IMO the default 
>behaviour of the server layer should always be to carry the client layer 
>traffic unit transparently.

And in terms of bridge applications, the client layer (user data) doesn't 
have FCS (the FCS belongs to the server layer - the MAC layer) and the 
client layer FCS (if needed) is the responsibility of the application and 
not the bridge. So if you want to have a new encapsulation on the CE side 
(similar to 1483/1490 that can have FCS for client data), then that a 
separate issue but we shouldn't impose such requirement on the bridges.

Regards,
Ali

>regards, Neil
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]On Behalf Of Ali
> > Sajassi
> > Sent: 26 November 2003 02:24
> > To: [email-masked]; 'Scott Kotrla'; [email-masked];
> > [email-masked]
> > Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> >
> >
> > I ask the question of service applicability for FCS retention
> > some time ago
> > and I didn't get a clear answer so let me ask again. When
> > talking about FCS
> > retention, which I of the following four Ethernet services do
> > you have in
> > mind ?
> >
> > 1) port-based point-to-point Ethernet service
> > 2) vlan-based point-to-point Ethernet service
> > 3) port-based Ethernet bridge service (multipoint)
> > 4) vlan-based Ethernet bridge service (multipoint)
> >
> > In vlan-based service, the customer vlan is used as service
> > delimiter and
> > is NOT the same at the two ends of the service - e.g., just
> > like frame
> > relay or ATM where DLCI or VPI/VCI are not the same at two
> > ends. Requiring
> > that the VLANs be the same at the two ends, imposes
> > unnecessary restriction
> > in customer provisioning model. Therefore, FCS retention is
> > not viable for
> > applications where customer VLAN is used as service delimiter.
> >
> > Also any bridge service (port-based or vlan-based) doesn't
> > require FCS
> > retention by the definition of the bridge service itself.
> >
> > So, the only applicable service for this FCS retention stuff
> > (and I doubt
> > viability of it), is for port-based point-to-point service.
> > However, I
> > would like to ask the following question:
> >
> > How do you catch the errors introduced by the switches for the other
> > services ??? Given that the same set of networking gears is
> > to support all
> > four Ethernet services, are you suggesting that we only need
> > to solve the
> > problem for a single service and not to worry about other
> > service type !!!
> > Or are you suggesting that you only offer a single service
> > and thus you
> > don't have to worry about other services !!!
> >
> > As I mentioned previously, a better approach is to solve the
> > problem for
> > all the Ethernet services - whether it is through OAM
> > mechanisms or through
> > internal switch check-sum or a combination of two or
> > whatever. But the
> > point is we should try to address the issue for ALL service types.
> >
> > -Ali
> >
> > At 12:01 PM 11/25/2003 -0800, Mick Seaman wrote:
> >
> > >If you are not concerned about protecting the customer but
> > merely locating
> > >repetitively failed switch then OAM-like operations and test
> > should be
> > >sufficient. It remains the case that placing exactly the
> > same error check
> > >algorithm on the outer CRC as the inner does not extend your
> > fault coverage
> > >for the customer much. Switch faults will still be capable
> > of bringing the
> > >entire network to a halt and sending the wrong packets to the wrong
> > >customers. Anyone who buys a network service from a provider
> > with poor
> > >internals on the grounds that the outer CRC will protect him
> > is being simply
> > >naive. I'll go further than that, if a salesman tries to
> > sell me a service
> > >with an outer CRC I will know that I can't trust the network
> > and simply
> > >should not buy.
> > >
> > >Moreover as I have pointed out it is perfectly in the spirit
> > of the 802.1
> > >standards that the switch recalculate both the inner and the
> > outer CRC, and
> > >indeed where the format of the frame delievered to the
> > custoomer changes
> > >through the network it will have to recalculate both.
> > >
> > >Mick
> > >
> > >-----Original Message-----
> > >From: [email-masked]
> > >[mailto:[email-masked]]On Behalf Of Scott Kotrla
> > >Sent: Tuesday, November 25, 2003 8:36 AM
> > >To: [email-masked]; [email-masked]; [email-masked]
> > >Subject: RE: [PWE3] RE: [802.1] 802.1ad Customer FCS Retention
> > >
> > >
> > >
> > >So are you suggesting because a CRC-32 will miss 1 in 4
> > billion frames
> > >it is not useful to know?  I don't need to catch every frame to know
> > >there is a problem.
> > >
> > >The standard Ethernet CRC protects the link and not the
> > internal switch,
> > >and it is very difficult to put requirements on the internal
> > working of
> > >a switch.  As stated in a previous message:
> > >
> > >"The model of operation is simply a basis for describing the
> > >functionality of the MAC Bridge. It is in no way intended to
> > constrain
> > >real implementations of a MAC Bridge; these may adopt any
> > internal model
> > >of operation compatible with the externally visible behavior
> > that this
> > >standard specifies. Conformance of equipment to this
> > standard is purely
> > >in respect of observable protocol."
> > >
> > >I am not worried about link errors.  I am worried about corruption
> > >within switches.  If switches have unknown failure modes that add
> > >unknown corruption, what besides a Path FCS will be able to determine
> > >that there is a problem.  Once again, detection is at least
> > 10 times as
> > >important as diagnosis.  If we can come up with a better way
> > to detect
> > >when (not if) switches are corrupting packets, I would be very
> > >interested in understanding the benefits of this approach.
> > >
> > >The service provider requirement can be succinctly stated as:
> > >
> > >The network shall be able to detect when (not if) switches are
> > >corrupting packets.  Suggesting that switches will never unknowingly
> > >corrupt packets is wishing the problem away and is not an acceptable
> > >answer.  Never is a very long time.  Besides, out of the 100 or so
> > >switches I have worked with, I have already seen it happen.  And I am
> > >not all that lucky.
> > >
> > >Thanks,
> > >
> > >Scott
> >
> >
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> >

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