Re: M2PA Alignment Clarification

I agree with Mark in that this sounds implementation dependent and does 
not guarantee interworking between different implementations of m2pa stacks.

Brian Bidulock stated 4.1.8 "M2PA SHOULD give higher priority to reading 
the Link Status stream than to reading the User Data stream.".  If this 
is required to guarantee interworking then this must be stated as a 
requirement and not as a recommedation as it is here.

At one time (draft version 3), the proving messages were sent on the 
data stream.  I do not remember the reason that the proving messages 
were moved from the data stream to the link status stream.  If the 
proving messages were on the data stream, there would not be the 
missequencing of the SLTM and proving messages received.


Brian F. G. Bidulock wrote:
> Mark,
>
> Well, if the implementation does not follow the recommendations
> of RFC 4165 section 4.1.8, then there will be a problem.
>
> If, at the receiver, you should wait until it can be determined
> that no messages are outstanding for stream 0 before reading data
> messages on stream 1, per section 4.1.8.  When you read an SLTM
> and have a missing TSN, as all M2PA messages are sent ordered,
> you can easily detect that there is a missing message from stream 0.
>
> Per 4.1.8, your receiver should wait until the link status stream
> messages are read before processing messages read from stream 1.
>
> Therefore, if you make your receiving implementation follow 4.1.8
> to the letter, then you will not have a problem: it will wait until
> all proving messages have been received before processing the SLTM.
>
> --brian
>
>
> Davidson, Mark wrote:                    (Wed, 04 Oct 2006 07:21:45)
>   
>> Brian,
>>
>> I agree that if ALL senders wait for the last LSP to be acked by SCTP
>> before sending LSR/DATA then the problem is fixed (though I dislike
>> munging the layers in this way).  But the original problem is one for
>> the receiver, not the sender.  I.e., the receiver cannot guarantee that
>> the far end follows this procedure.  Changing what is sent, doesn't help
>> guarantee what is received.  We don't get to assume the same vendor on
>> both ends.  So the problem remains.
>>
>> -Mark Davidson
>>
>>     
>
>   


-- 
Brian Tatum       (972)519-2781          E-mail: [email protected]
Alcatel USA, Inc.  3400 West Plano Parkway, MS SWPRO, Plano, Texas 75075
******* Alcatel is not responsible for any opinions stated here. *******

_______________________________________________
Sigtran mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/sigtran