Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements

From: Loa Andersson <[email-masked]>
Date: Thu, 6 Oct 2016 16:09:01 +0800

Working Group, authors,

We are past the closing date for this wglc. I'm reluctant to close the
last call. The reason is that I received some comments off-line that I'd
like to hear feed back on.

1. Existing solution mechanism(s)
    ------------------------------
    It is said that even though we have no existing implementations of
    m:n, there are existing solutions mechanisms that meet the
    requirements.
    I would like to have this verified if possible.

2. Not an update of 5654
    ---------------------
    This is probably correct, this document adds two new requirements,
    but does in no way change RFC 5654.

3. Document structure
    ------------------
    IESG members has recently expressed opinions that we should not
    publish small stand alone document with a small number of use cases
    or requirements, thes should rather be kept with the working and
    published as appendices to the solutions document.
    I would like to hear comments on this.

4. The document need to be liaised to ITU-T SG15
    ---------------------------------------------
    I agree with this, normally we liaise wg consensus texts, and the
    document could be liaised when the wglc closes.

To hear the feedback on this I will keep the wglc open for another
week starting today.

/Loa
mpls wg co-chair

On 18/09/2016 18:39, Loa Andersson wrote:
> Working Group,
>
> This is to initiate a two week working group last call on
> draft-ietf-mpls-tp-mfp-use-case-and-requirements-02.
>
> Please send your comments to the mpls wg mailing list ([email-masked]).
>
> There were no IPR disclosures against this document.
>
> All the authors and contributors have stated on the working group
> mailing list that they are not aware of any IPRs that relates to this
> document.
>
> This working group last call ends Oct 2, 2016.
>
>
> /Loa
> for the MPLS wg chairs

-- 

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

---

From: Rolf Winter <[email-masked]>
Date: Thu, 6 Oct 2016 11:37:10 +0000

Hi,

please see inline.

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Donnerstag, 6. Oktober 2016 10:09
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements

Working Group, authors,

We are past the closing date for this wglc. I'm reluctant to close the last call. The reason is that I received some comments off-line that I'd like to hear feed back on.

2. Not an update of 5654
    ---------------------

--- RW
This is the text concerning updates of RFC in RFC2223 (it has recently been obsoleted by RFC 7322, but text regarding the reasoning behind updates has basically vanished there as far as I can tell):

Updates

      To be used as a reference from a new item that cannot be used
      alone (i.e., one that supplements a previous document), to refer
      to the previous document.  The newer publication is a part that
      will supplement or be added on to the existing document; e.g., an
      addendum, or separate, extra information that is to be added to
      the original document.

I think this makes this document an update as it contains an addendum essentially. Or the other way round, if you read 5654, there is no way the reader can tell there are more requirements. An update will make that clear.
---

3. Document structure
    ------------------

--- RW
I can understand this and usually I would agree. But then, given the above that solution document would need to update RFC5654 and that would be strange, having a solution document update a requirements document. It would mix two things I believe should be separate. You unfortunately cannot restrict an update of an RFC to a section of a different RFC.

---

--- RW

Yes, that should be done.

Best,

Rolf

---

To hear the feedback on this I will keep the wglc open for another week starting today.

/Loa
mpls wg co-chair

--

---

From: Loa Andersson <[email-masked]>
Date: Thu, 6 Oct 2016 23:42:09 +0800

Rolf,

> 1. Existing solution mechanism(s)

I think your reading is correct - and I very much appreciated a model
where w developed things in a series of document - I guess MPLS-TP and
sub-projeccts are what comes to mind.

But the description of updating is obsoleted, i.e. it is history we
can't use to support our arguments. And according to the new orthodoxy
and addendum is not an update.

/Loa

--

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 6 Oct 2016 15:59:33 +0000

Hi,

I agree with Loa on this is not an update of RFC5654. RFC5654 is a document reflecting ITU-T requirements for MPLS-TP. This draft is not a result of a request by ITU-T.

The document is building on RFC6372, but it doesn't necessarily "update" RFC6372. RFC6372 covers a wide range of mechanisms. An implementer of RFC6372 does not have to also implement this document unless they want to support this extra capability. So this capability is not required for any of those existing requirements, it's only needed if one wants this capability, so the requirements can stand on their own. Note, RFC6372 did not update RFC5654.

I'm recommending to hold this document in the WG until a solution document is initiated. By doing a solution document, it will help determine if these requirements and the resulting solution are an update for any of the existing solution documents.

As the document only has two requirements, it can be part of an appendix to a solution document. PCE recently did such a document:
https://www.ietf.org/id/draft-ietf-pce-pcep-service-aware-13.txt

Of more concern, I've not seen any mailing list discussion on this document or any solution document proposed indicating interest by the WG, I strongly encourage the list be used as progress a solution document. Working in parallel on requirements and a solution is always the best approach. Requirements documents do not need to be published as RFCs, especially these very short type of documents. The IETF Chair summarized this in his May blog on the IESG retreat:
https://www.ietf.org/blog/2016/05/

Thanks,
Deborah

> From: mpls [mailto:[email-masked]] On Behalf Of Rolf Winter
> Sent: Thursday, October 06, 2016 7:37 AM
> To: Loa Andersson <[email-masked]>; [email-masked]
> Subject: Re: [mpls] working group last call on draft-ietf-mpls-tp-mfp-use-case-
> and-requirements
> 
> Hi,
> 
> please see inline.
> 
> We are past the closing date for this wglc. I'm reluctant to close the last call.
> The reason is that I received some comments off-line that I'd like to hear feed
> back on.
> 
> This is the text concerning updates of RFC in RFC2223 (it has recently been
> obsoleted by RFC 7322, but text regarding the reasoning behind updates has
> basically vanished there as far as I can tell):
> 
> Updates
> 
> I think this makes this document an update as it contains an addendum
> essentially. Or the other way round, if you read 5654, there is no way the
> reader can tell there are more requirements. An update will make that clear.
> ---
> 
> 3. Document structure
>     ------------------
> I can understand this and usually I would agree. But then, given the above that
> solution document would need to update RFC5654 and that would be strange,
> having a solution document update a requirements document. It would mix
> two things I believe should be separate. You unfortunately cannot restrict an
> update of an RFC to a section of a different RFC.
> 
> ---
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 6 Oct 2016 23:07:47 +0100

Hej Loa,

> 1. Existing solution mechanism(s)

It all slightly depends on the precise intent of the document. I think it is
talking about m:n end-to-end protection of LSPs. This is very distinct from m:n
protection resource sharing within a network: a problem that requires quite a
lot more coordination to solve well since the various head ends need to be
updated about the protection status (a problem that does not exist in end-to-end
protection).

The text is a bit coy, referring to "protection entity" and "working entity."
That may be intended to save some words, but it doesn't help us know exactly
what problem is being solved. The only figure shows LSPs across a protection
domain with end-to-end protection, so my assumption may be right.

Now, given this, the requirements in the document are clear but do not seem (to
me) to need more protocol work. Maybe there could be an applicability statement
written (by people who want to ship or deploy this function) showing how the
existing tools can do the job. Or maybe it is an exercise for the reader :-)

A middle step might be to write protocol requirements (A needs to detect foo. A
needs to tell Z bar. Etc.) so that it can be more easily seen which bits of
protocol can be used to do the job.

[BTW, the document doesn't distinguish between unidirectional and bidirectional
LSPs and that, surely, changes the coordination that is needed.]

Cheers,
Adrian

---

From: Rolf Winter <[email-masked]>
Date: Thu, 20 Oct 2016 08:13:49 +0000

Hi,

FWIW, to me personally, what Deborah suggests seems the most sensible way forward.

Best,

Rolf

-----Original Message-----
From: BRUNGARD, DEBORAH A [mailto:[email-masked]] 
Sent: Donnerstag, 6. Oktober 2016 18:00
To: Rolf Winter; Loa Andersson; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements

Hi,

Thanks,
Deborah

> Subject: Re: [mpls] working group last call on 
> draft-ietf-mpls-tp-mfp-use-case- and-requirements
> 
> Hi,
> 
> please see inline.
> 
> Subject: Re: working group last call on 
> draft-ietf-mpls-tp-mfp-use-case-and-
> requirements
> 
> Working Group, authors,
> 
> The reason is that I received some comments off-line that I'd like to 
> hear feed back on.
> 
> This is the text concerning updates of RFC in RFC2223 (it has recently 
> been obsoleted by RFC 7322, but text regarding the reasoning behind 
> updates has basically vanished there as far as I can tell):
> 
> Updates
> 
> essentially. Or the other way round, if you read 5654, there is no way 
> the reader can tell there are more requirements. An update will make that clear.
> ---
> 
> 3. Document structure
>     ------------------
> I can understand this and usually I would agree. But then, given the 
> above that solution document would need to update RFC5654 and that 
> would be strange, having a solution document update a requirements 
> document. It would mix two things I believe should be separate. You 
> unfortunately cannot restrict an update of an RFC to a section of a different RFC.
> 
> ---
> 
> > mailing list that they are not aware of any IPRs that relates to 
> > this document.
> >

---

From: Loa Andersson <[email-masked]>
Date: Sat, 22 Oct 2016 10:38:36 +0800

Rolf, et.al.,

Yes that might be the only route open to us, but as you said early we
will lose requirement trceability and I don't like that. Does anyone
have an idea how to fix that?

/Loa

--

---

From: Rolf Winter <[email-masked]>
Date: Mon, 24 Oct 2016 11:44:16 +0000

Loa,

 I guess we can postpone that question until we actually publish this.

Best,

Rolf

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]] 
Sent: Samstag, 22. Oktober 2016 04:39
To: Rolf Winter; BRUNGARD, DEBORAH A; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: working group last call on draft-ietf-mpls-tp-mfp-use-case-and-requirements

Rolf, et.al.,

Yes that might be the only route open to us, but as you said early we will lose requirement trceability and I don't like that. Does anyone have an idea how to fix that?

/Loa

On 2016-10-20 16:13, Rolf Winter wrote:
> Cc: [email-masked]; 
> [email-masked]
> Subject: RE: working group last call on 
> draft-ietf-mpls-tp-mfp-use-case-and-requirements
>
> Hi,
>
>> This is the text concerning updates of RFC in RFC2223 (it has 
>> recently been obsoleted by RFC 7322, but text regarding the reasoning 
>> behind updates has basically vanished there as far as I can tell):
>>
>> Updates
>>
>> essentially. Or the other way round, if you read 5654, there is no 
>> way the reader can tell there are more requirements. An update will make that clear.
>> ---
>>
>> 3. Document structure
>>     ------------------

--