Fw: M2PA v6: Two Out of Three Valid BSN

Hi,

-----Original Message-----
From: "May, Howard" <howard.may <at> intel.com>
To: <sigtran <at> ietf.org>
Cc: "Tolga Asveren" <tolga.asveren <at> ss8.com>
Sent: Thursday, October 03, 2002 3:22 PM
Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN

Tolga,

> -----Original Message-----
> From: Tolga Asveren [mailto:tolga.asveren <at> ss8.com]
> Sent: 30 September 2002 15:57
> To: sigtran <at> ietf.org
> Subject: RE: [Sigtran] M2PA v6: Two Out of Three Valid BSN
>
>
> Anshoo,
>
> > -----Original Message-----
> > From: sigtran-admin <at> ietf.org
> [mailto:sigtran-admin <at> ietf.org]On Behalf Of
> > anssharma <at> hss.hns.com
> > Sent: Monday, September 30, 2002 9:28 AM
> > To: bidulock <at> openss7.org
> > Cc: sigtran <at> ietf.org
> > Subject: Re: [Sigtran] M2PA v6: Two Out of Three Valid BSN
> >
> > Hi Brian,
> >
> > Checksum failiure can cause any of the fields in the Message to
> > be corrupt,
> >

  then why is the special consideration being given to BSN.
> > The two out of three BSN scheme would have been suitable, had we
> > been taking
> > into the consideration the FSN/BSN values in the Link Status
> > Messages as well.
> > Since that is not the case, I am not sure how we would be
> > deriving any benefit
> > from this scheme.
> [TOLGA] Why do you think this procedure exists for MTP2? Your
> argument is
> that there won't be any missequencing in SCTP, but similarly
> one can argue,
> there won't be any misseqiencing on a wire(for MTP2) either.
[hmay] Is it not the case that in MTP2 there is more scope for misequenced BSNs
on account of prioritised Link Status messages and the use of FISUs.  Certainly
misequencing on account of this is an implementation specific issue, but in the
days when the processing able to be performed during single FISU emmission time
was more limited, this kind of issue may be  more common and thus 2 out of 3
safeguard more relevant.
> > If I am missing anything here, please elaborate.
> [TOLGA] At the beginning I also thought on bit errors, but
> another reason,
> why BSN does not have an expected value might be, that peer
> M2PA (or MTP2 in
> case of Q.703)  fills it wrong. I tend to think, that is the
> real reason for
> that procedure, because bit errors are handled as described
> in Q.703 10.2.
> (With the procedure defined in Q.703 5.3.1 it is possible to
> detect some
> errors which are not detectable with checksum but I would
> think, if there is
> really something wrong on the link, there would be enough bit
> errors, which
> are detectable with checksum, to make the procedure in Q.703
> 10.2 to work.)
[hmay] If (as I think you are suggesting) the 2 out of 3 procedure is now only
of significant value to protect against M2PA implementation error, then without
understanding why there is a specific risk of this error I don't currently see
why we should complicate the spec with the procedure.
[Anshoo] Even I would suggest the same. Since there seems to be no other reason
besides covering implementation errors, can we please remove this procedure from
the Draft.

Regards
Anshoo.

DISCLAIMER: This message is proprietary to Hughes Software Systems
Limited (HSS) and is intended solely for the use of the individual
to whom it is addressed. It may contain  privileged or confidential
information  and should not be circulated or used for any purpose other
than for what it is intended. If you have received this message in error,
please notify the originator immediately. If you are not the intended
recipient, you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. HSS accepts
no responsibility for loss or damage arising from the use of the information
transmitted by this email including damage from virus.