Subject: Re: [mpls] MPLS-RT review of PSC related drafts

From: Loa Andersson <[email-masked]>
Date: Mon, 02 Sep 2013 14:05:25 +0200

Markus, Huub, et.al.,

It is quite obvious that I'm behind reading the pcs drafts, reading now
and hopefully will be able to give more insightful responses when done.

However, in Berlin I asked the authors to keep the specification
separate. I had the impression that the 6378-delata should be captured
in draft-xxx and the existing documents should clear and simple "just"
specify the new functions.

I guess this was not communicated clearly, since all the mpls-rt
reviewers "complains" that the current format (based on 6738-delta) is
hard to digest.

Bear with me a few days until I'm through the documents.

/Loa

On 2013-08-30 23:29, Markus Jork wrote:
> Huub,
>
>>   > Was having a set of update drafts somehow meant to ease  > coordination
>> with the ITU?
>>
>> Yes. This was requested in the liaison from IETF to ITU and the concatenation
>> of the options is in draft ITU mode.
>
> Ok, so as I suspected the current format of the I-Ds was chosen for procedural reasons.
> While that is understandable, the resulting I-Ds are pretty hard to digest.
> I think producing good and readable RFCs should be more important than making it easy to get them through the standardization process.
>
>>> Anyway, the main audience for a standards track RFC are
>>   > the implementers and users of the technology. So an RFC  > should be
>> written to be easily understood and digested  > by its audience. And in my
>> opinion the format chosen for  > this set of PSC drafts is not ideal in that
>> regard.
>>
>> What is the format you would like to see?
>
> I think we need one draft that is a new revision of RFC 6378. It would incorporate all the corrections and new features.
> That's what you want to do with "draft-xxx-mpls-tp-ITU-mode" anyway:
>
>> Currently there will be two modes:
>> = none option supported: existing RFC6378 = all options supported: draft ITU mode
>>
>> In this way implementations (currently) have to support two modes.
>
> So if the current set of drafts describing optional features can't be arbitrarily combined anyway, why not produce one new ITU-mode draft that describes all of this together?
>
> Just to illustrate the problem with the current set of drafts, here is one example: 3 of the drafts modify the same section of RFC 6378:
>
> * draft-rhd-mpls-tp-psc-priority-01.txt:
>
>    4.2.  Updates to Section 4.3.3.2.  Unavailable State
>       Remove the following bullet items and their text:
>       [...]
>
>
> * draft-cdh-mpls-tp-psc-non-revertive-00.txt:
>
>    4.8.  Updates to Section 4.3.3.2. Unavailable State
>       Replace the following bullet item in the reaction to local input
>       list:
>       [...]
>       With:
>       [...]
>
>       Replace the following bullet item in the reaction to remote message
>       list:
>       [...]
>       With:
>       [...]
>
>
> * draft-rhd-mpls-tp-psc-sd-00.txt:
>
>    5.9.  Updates to Section 4.3.3.2 Unavailable State
>
>       The second paragraph of Section 4.3.3.2 Unavailable State in
>       [RFC6378] shows the intention of including the signal degrade on the
>       protection in the Unavailable state.  This document follows the same
>       state grouping as [RFC6378] for SD-P, even though the protection path
>       can be partially available under the condition of the signal degrade
>       on the protection path.
>
>       Replace the following text in the first paragraph of Section 4.3.3.2
>       Unavailable State for further clarification on SD on the protection
>       path:
>       [...]
>       With:
>       [...]
>
>       Replace the following bullet item text in the transitions in reaction
>       to a local input:
>       [...]
>       With:
>       [...]
>
>       Replace the following bullet item text in the transitions in reaction
>       to a local input:
>       [...]
>       With:
>       [...]
>
>
> Each draft with its "diff" format is bad enough on its own. But any combination of these drafts would be incomprehensible. So why have these separate RFCs?
>
> -Markus
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64