Subject: [mpls] MPLS-RT review of draft-rhd-mpls-tp-psc-sd

From: Sam Aldrin <[email-masked]>
Date: Fri, 23 Aug 2013 15:25:55 -0700

Hi,

I have done a review of draft-rhd-mpls-tp-psc-sd as part of MPLS RT process. Please find my comments inline. 

-sam

General comments:
-------------------------
- Have similar comment like other drafts. This draft contains the diff off what is not present in the existing RFC. Is the intention to create a separate RFC in addition to existing RFC6378, by correcting the priority scheme?

Nitpicks/Editorial:
-----------
- Clarity question, Is  it mandated to use PSC only as communication medium or there could be other means, like OAM?

- Sec 1.2, Could you please add clarity to the sentence
The priority level of Clear SF defined in [RFC6378] can cause traffic
   disruption when a node that has experienced local signal fails on
   both working and protection paths is recovering from these failures.

- In Sec 4.2 - When you say SHALL, is it interpreted as MUST or SHOULD?

Assessment comments:
-----------------------------
- Is the document coherent?
> Yes, it is coherent and consistent

- Is the document useful?
> Yes. Correcting the priority as identified in RFC6378 is needed

- Is the document technically sound?
- Yes

- Is is ready for WG adoption
- Not in its correct form. This document is mostly identifying changes to RFC. My preference is to combine all the changes to RFC6378 and re-issue a new RFCbis.  Otherwise, this will be very confusing to refer two or more documents every time to make sense of what is the correct behavior for PSC in linear protection. 
- If that is (creating new RFC bis) something not possible(hope there is a real strong reason for this), then the document should be edited to be more stand alone document. i.e. remove add/replace to more assertive sections for readers to understand without having to go back to RFC, every time.

---

From: Huub van Helvoort <[email-masked]>
Date: Sat, 24 Aug 2013 10:11:46 +0200

All reviewers of the drafts,

draft-rhd-mpls-tp-psc-priority
draft-rhd-mpls-tp-psc-sd
draft-dj-mpls-tp-exer-psc
raft-cdh-mpls-tp-psc-non-revertive
draft-osborne-mpls-psc-updates

and anybody else who wants to contribute:

I have noticed your concern regarding the way each of
these drafts should be used to address RFC6378.

I would like to point you this presentation in the IETF87
meeting which contains a proposed forward path:
http://www.ietf.org/proceedings/87/slides/slides-87-mpls-15.ppt

In this thread the discussion for supporting the options
mentioned in the slides has already started:
http://www.ietf.org/mail-archive/web/mpls/current/msg10400.html

Best regards, Huub.

---

From: Markus Jork <[email-masked]>
Date: Mon, 26 Aug 2013 15:07:02 +0000

I did not attend the Berlin IETF and the minutes don't seem to be out yet, so I don't know to what extent this was discussed there.
But it seems most (all?) reviewers of the resulting drafts did not really like the "diff" approach. That sends a pretty clear message that maybe this wasn't such a great idea after all.
Even after looking at the slides, I'm not clear what the motivation was to choose the "diff" format. Was having a set of update drafts somehow meant to ease coordination with the ITU?
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.

-Markus

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Huub van Helvoort
> Sent: Saturday, August 24, 2013 4:12 AM
> Cc: [email-masked]; [email-masked]
> Subject: [mpls] MPLS-RT review of PSC related drafts
> 
> I have noticed your concern regarding the way each of these drafts should be
> used to address RFC6378.
> 
> I would like to point you this presentation in the IETF87 meeting which
> contains a proposed forward path:
> In this thread the discussion for supporting the options mentioned in the
> slides has already started:

---

From: Yaacov Weingarten <[email-masked]>
Date: Mon, 26 Aug 2013 20:48:23 +0300

Hi.
I fully agree with Markus on this. We should also keep in mind that, at
least in theory, each RFC should strive to be a stand-alone document. In
addition, as I pointed out in one of my reviews this could lead to
contradictory "corrections" that no reader's guide draft could overcome!

BR,
yaacov
On Aug 26, 2013 6:07 PM, "Markus Jork" <[email-masked]> wrote:

> I did not attend the Berlin IETF and the minutes don't seem to be out yet,
> so I don't know to what extent this was discussed there.
> But it seems most (all?) reviewers of the resulting drafts did not really
> like the "diff" approach. That sends a pretty clear message that maybe this
> wasn't such a great idea after all.
> Even after looking at the slides, I'm not clear what the motivation was to
> choose the "diff" format. Was having a set of update drafts somehow meant
> to ease coordination with the ITU?
> 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.
>
> -Markus
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 26 Aug 2013 22:05:59 +0200

Hallo Markus,

You wrote:

> I did not attend the Berlin IETF and the minutes don't
 > seem to be out yet, so I don't know to what extent this
 > was discussed there.

The sesion was recorded:
http://www.ietf.org/meeting/87/remote-participation.html#audio
(Room Potsdam 3).

> But it seems most (all?) reviewers of the resulting drafts
 > did not really like the "diff" approach.

Maybe most (all) reviewers did not attend the MPLS session
on Friday. And thus were not aware of the proposed roadmap
for progressing these drafts.
In the slideset slide 20 captures the overall idea:
- each of the drafts captures/describes an optional change
   to RFC6378.
- new draft-xxx-mpls-tp-ITU-mode provides the mode in which
   all the options are supported at the same time.
   All the changes to the protocol state machine are captured
   in this draft.
- It was agreed that any other sub-set of these options would
   require its own particular mode draft and state machine.

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.

> That sends a pretty clear message that maybe this wasn't
 > such a great idea after all.

Maybe they did not understand the way i which all the
options should be supported.

> Even after looking at the slides, I'm not clear what the
 > motivation was to choose the "diff" format.

To describe why each of the separate options is required.
This was proposed in the liaison sent from IETF to ITU.

 > 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.

> 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?

Regards, Huub.

-- 
*****************************************************************
               请记住，你是独一无二的，就像其他每一个人一样

---

From: t.petch <[email-masked]>
Date: Tue, 27 Aug 2013 18:06:10 +0100

----- Original Message -----
From: "Huub van Helvoort" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, August 26, 2013 9:05 PM
>    require its own particular mode draft and state machine.

Huub

It sounds as if it would be clearer if we had a sight of draft-xxx

Certainly up to now, my sympathies have been with the reviewers who have
found the piecemeal approach a source of possible ambiguity.

Tom Petch

---

From: Markus Jork <[email-masked]>
Date: Fri, 30 Aug 2013 21:29:05 +0000

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. 

>  > 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.
> 

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:

> = 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