Subject: Frame Check Sequence Retention - LAST CALL

From: Stewart Bryant <[email-masked]>
Date: Mon, 29 Nov 2004 14:29:24 +0000

This is the start of two week last call for

PWE3 Frame Check Sequence Retention
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-fcs-retention-02.txt

Last call will end Tuesday 14th December 2004

Stewart

FCS retention

---

From: [email-masked]
Date: Mon, 29 Nov 2004 16:50:37 -0000

Couple of observations on this draft:

1	I don't agree the default behaviour should be strip the
FCS......but there is a much more important principle at stake here:
The default behaviour of any client/server relationship should always be
complete client transparency (all planes) over the server.

2	The data-plane behaviour should be consistent irrespective of
how the trail is set-up.  This draft talks about LDP-based signalling
for the XoverMPLS case (though there is a cursory mention of management
provisioning).  However, it should apply to all signalling cases, eg the
MH-PW discussions where RSVP-TE is also being considered.  

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant
> Sent: 29 November 2004 14:29
> To: pwe3
> Subject: [PWE3] Frame Check Sequence Retention - LAST CALL
> 
> 

Stewart

FCS retention

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 29 Nov 2004 14:16:28 -0500

Neil,

Thanks for your comments.  Unfortunately, I can't do anything about comment 
1 without the WG changing all of the existing encapsulation drafts.  On 
comment 2, I agree, if the WG makes RVSP-TE-signaled pseudowires a work 
item, then we'll be sure to get the capability to signal FCS retention in 
there.  Maybe in that case we can even make it the default! :-)

Cheers,
Andy

---------

---

From: [email-masked]
Date: Tue, 30 Nov 2004 09:04:36 -0000

Thanks Andy and 'yes please'.....

Often we can't go back and re-do stuff......but as an engineering
community we would be rather foolish not to learn from mistakes.  It
would be really nice if we could capture these lessons as we go along.

I think its time we started doing things a little more measured based on
a better understanding of functional architecture wrt the 3 networking
modes.  It's quite clear to me from several perspectives/initiatives
(such as the stated desire to migrate from MPLS to GMPLS in CCAMPs (see
Note at the end) and quite obviously the creeping realisation in PWE3
that XoverMPLS != XoverIP) that its time we started viewing MPLS as the
basis of layer network in its own right.  Indeed, if more folks had had
this view earlier I suspect many of the other problems that we also see
looming (such as the likelihood of creating a new 'PW layer network' and
the unnecessary differences of 'PW OAM' and 'LSP OAM') might have been
understood better earlier and addressed more appropriately.
{Aside - I am not saying throw-out all that has gone before that is
wrong, but learn from this and look to where we are now heading.}

We strongly believe there is far more value (and less opex) from
operating the 3 network modes in concert rather than trying to make 1
size fit all.....in fact the latter approach simply won't work
effectively in both technical and commercial dimensions (I can easily
explain why, but not here/now).

I'd urge open-minded folks to try and think more in functional
architecture terms and understand that it is the *differences* between
the 3 modes that are the 'precious bits'.....all the modes are important
and a full-service operator needs them all.  It's how we work them in
concert that is the really important issue.

Note - There is a very good reason why the GMPLS control-plane looks
like its does....and the behaviour we see here is not simply down to a
'design choice' (though the actual functional components are) but a
forced behaviour due to the nature of the co-cs mode (specifically the
nature of the link-connections and the quantised/known data-plane
bit-rate).

regards, Neil

> From: Andrew G. Malis [mailto:[email-masked]] 
> Sent: 29 November 2004 19:16
> To: Harrison,N,Neil,IKR2 R
> Cc: [email-masked]
> Subject: RE: [PWE3] Frame Check Sequence Retention - LAST CALL
> 
> 
> Neil,
> 
> >The default behaviour of any client/server relationship 
> should always 
> >be complete client transparency (all planes) over the server.
> >
> >provisioning).  However, it should apply to all signalling cases, eg 
> >the MH-PW discussions where RSVP-TE is also being considered.
> >
> >regards, Neil
> >
> > > From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> > > Of Stewart 
> Bryant