Re: [Last-Call] [Detnet] Rtgdir last call review of draft-ietf-detnet-mpls-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,
I fully agree with Carlos about a "one-liner explanation" that would not hurt.
IMHO and FWIW it would be even better if the such an explanation would also cover:
- the rationale for three MUST to support sequence number spaces
- added value of the sequence number space with zero bits in DetNet (one of these three).

My 2c.

Get Outlook for Android


From: rtg-dir <rtg-dir-bounces@xxxxxxxx> on behalf of Carlos Pignataro (cpignata) <cpignata@xxxxxxxxx>
Sent: Monday, January 27, 2020, 17:08
To: Lou Berger
Cc: Routing Directorate; Balázs Varga A; detnet@xxxxxxxxx; draft-ietf-detnet-mpls.all@xxxxxxxx; last-call@xxxxxxxx
Subject: Re: [RTG-DIR] [Detnet] Rtgdir last call review of draft-ietf-detnet-mpls-04

Hi, Lou,

> 2020/01/27 午前9:41、Lou Berger <lberger@xxxxxxxx>のメ?ル:
>
> Hi,
>
> Balázs thank you for the clarification -- see below for one comment.
>
> On 1/10/2020 8:56 AM, Balázs Varga A wrote:
>> Yes, but why not the Preferred CW?
>>
>> <Balazs>/<Stewart> Sum of mailing + proposed fixing:
>> The PCW only supports a 16bit sequence number and it has the skip zero auto-signaling of active S/N feature.
>> This was a problem for DetNet because:
>> - We were worried about S/N rollover frequency in some applications and so we wanted the option of a larger S/N.
>> - We wanted to have the option to propagate the S/N from the payload to the transport to simplify the implementation
>> in some cases. These applications have a non-skip zero S/N. Skip zero is an irritation to implement and we should probably
>> have signaled in in PWs.
>> As you note in is only a preferred design for PWs, DetNet is not constrained by that and there were good reasons to adopt
>> this alternate approach.
>> We assume to fix this with adding above information to the text.
>> NEW text to be added in section 4.2.1:
>>     "This format of the d-CW was created in order (1) to allow larger S/N space to
>>     avoid S/N rollover frequency in some applications and (2) to allow non-skip
>>     zero S/N what simplifies implementation."
>
> While I completely agree with the rational and validity of the good question, I don't think such motivation belongs in the document.  We generally don't document every design decision in a specification.  I don't feel strongly about this so if others do, I'll defer to their opinion...
>
> Balázs, Carlos, Do you think it should stay?
>

I have no strong feelings either way, but I believe if this is a departure from a “preferred” format from a BCP, then a one-liner explanation would not hurt. I’d leave this one in.

Thanks,

Carlos.

> Thanks,
>
> Lou (as contributor)
>



___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________
-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux