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

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

mark seery wrote:
> Stewart Bryant wrote:
> 
>>
>>>> If you assume a PW to be a sort of bridge,
>>>
>>>
>>>
>>> NH=> A PW is for sure not a bridge!  A PW is an adaptation funtion 
>>> that lies between a client layer network and a server layer network 
>>> of MPLS or IP.  
>>
>>
>>
>> Neil
>>
>> Surely that is just one way to model the PW? Can't a PW also be
>> modelled as a repeater with certain internal delay and error
>> characteristics.
>>
>> Stewart
>>
>> _____________________________________________
>> pwe3 mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/pwe3
> 
> 
> Stewart,
> 
> I have worked on equipment that transported Ethernet over a tunnel, 
> without doing bridging, and the Ethernet testers have commented to me 
> "this is a repeater". So I think the analogy you make is intuitive for 
> Ethernet people. It is not technically correct because of the formal 
> definition of repeaters (IMO), but in spirit it is. 

Remember PWE3 never set out to provide perfect emulation. Our charter
was to provide adequate emulation, and describe in an applicability
statement the issues associated with the approximation.

> The more difficult 
> issue is that repeaters have 802 on ingress and egress, so if we are to 
> extend this analogy, then a PW is an internal connection within the 
> "virtual repeater" that is not part of a formal 802 model, other than it 
> should not introduce errors greater than some prescription.

The PW does have the same interface on both ends (even if the wire
ends in a virtual interface).

> 
> All Neil is suggesting is that the internal connection is "transporting" 
> the ethernet layer, and he is further arguing for a principle of layer 
> encapsulation (similar to object encapsulation in software) which is 
> very similar in spirit to the principle of minimum intervention sited in 
> the PW architecture document (3.3.5). All that is left is to argue about 
> whether the FCS belongs to the layer being transported.
> 

The original reason that FCS was stripped off was because PW was conceived
as a method of carrying minority traffic over the Internet, and many
equipments earmarked to provide this service (from a number of vendors)
were thought to be incapable of re-configuration to carry FCS. Now you
can question whether newer higher volume demands have emerged since PWE3
started, and the response from the WG has been that we should baseline
what we have and then consider the new requirements.

> I would assume a real 802 repeater would not strip the FCS, so if we 
> were to take the analogy to the extreme, we would not strip the FCS here 
> either, but of course as this is not a real repeater function, so we are 
> left with balancing the models and requirements of at multiple views: 
> IEEE, IP, IP-MPLS, ITU, carrier operations/engineering.
> 

Indeed, and after several years of design, discussion between the
vendors and the SPs, and early deployment experience, all that has
emerged in the way of practical problems is one single bridge
failing in a lab environment. I do not know the specifics of the
problem but I would suspect that if that failure had happened
in a production environment, the IGP would have recovered the
situation and the NMS would have pointed the finger.

So now lets turn back to the matter in hand.

1) Under what circumstances is the approximation inadequate (Please
    can we have this answer in the form of text for our applicability
    statements).

2) What is the best engineering solution to those shortcomings, and
    why?

> In a later email you say:
> 
> "For the PW to be an adaptation function, one would have to assert hat 
> the contents of the PW had some meaning within the PSN.  I don't beleive 
> it has, because we never communicate any context information to any 
> object in the PSN (either by signalling or  self description) which it 
> can use to interpret the contents of the PW."
> 
> If we were to assert that the contents of the PW had some meaning within 
> the PSN, I would suggest that would be an interworking function, not an 
> adaptation function.
> 

You are correct, it is an adaptation, not an interworking, but remember
we only ever set out to approximate the adaptation.

Stewart

---

From: mark seery <[email-masked]>
Date: Mon, 01 Dec 2003 08:38:23 -0800

Stewart,

Thanks for the constructive and informative response.

Some comments inline.

mark

Stewart Bryant wrote:

>> "this is a repeater". So I think the analogy you make is intuitive 
>> for Ethernet people. It is not technically correct because of the 
>> formal definition of repeaters (IMO), but in spirit it is. 
>
>

mark==> I have no problem with this in principle - I believe a market 
place works best when there are clear alternatives; and certainly 
respect the right of the IETF community to inform its working groups. 
The only problem in practice is that if some constituency sees a 
deficiency there is no effective means to address it because of the 
sensitivity about who owns what standard (in this case PWE/MPLS/IP), 
which is not insummountable obviously. This is where 
optional/informational RFCs can help if we recognise the different needs 
and address them (which at least for the end-to-end integrity issue we 
are, Malis et etl.).

In addition, we are obviously engaged in the rather complex issue of 
wanting to see an end to end solution of which we only have partial 
responsibility (the PW portion of the end-to-end Ethernet service). This 
complexity just adds to the consensus issue from a wider community. We 
are naturally pulled in to the end-to-end issue because the same people 
in the IETF that support a PW facility for Ethernet have a vested 
interest in seeing and end-to-end solution that is acceptable to a wider 
community.

>> The more difficult issue is that repeaters have 802 on ingress and 
>> egress, so if we are to extend this analogy, then a PW is an internal 
>> connection within the "virtual repeater" that is not part of a formal 
>> 802 model, other than it should not introduce errors greater than 
>> some prescription.
>
>
>> All Neil is suggesting is that the internal connection is 
>> "transporting" the ethernet layer, and he is further arguing for a 
>> principle of layer encapsulation (similar to object encapsulation in 
>> software) which is very similar in spirit to the principle of minimum 
>> intervention sited in the PW architecture document (3.3.5). All that 
>> is left is to argue about whether the FCS belongs to the layer being 
>> transported.
>>
>
>> were to take the analogy to the extreme, we would not strip the FCS 
>> here either, but of course as this is not a real repeater function, 
>> so we are left with balancing the models and requirements of at 
>> multiple views: IEEE, IP, IP-MPLS, ITU, carrier operations/engineering.
>>
>

mark ==> It is not clear to me this particular problem would necessarily 
have caused the IGP to make a change, unless the error was impacting 
control plane PDUs, which it may not have been if it was located on the 
service facing line cards. Of course I know less about the reported 
incident than you ;-). I accept your testimony that there have been few 
problems in practice. The issue I believe is the sensitivity to 
supporting services on a large scale (which you state below was not an 
anticipation of the WG - worth noting), and the approach that some 
constituencies take to fault detection & diagnosis; remembering that due 
to historical issues, the Internet community by design focused on 
Internet layer management techniques while other memebers of the 
industry did not.

> 2) What is the best engineering solution to those shortcomings, and

mark==> I have no complaints about the FCS retention draft from Malis et el.

<snipped to the end>