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

[Loa Andersson <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
>

-- 


Loa Andersson                        email: [e-mail]
Senior MPLS Expert                          [e-mail]
Huawei Technologies (consultant)     phone: [phone]