Dear Greg,

> 2020/02/26 午後5:38、Greg Mirsky <[email protected]>のメール:
> 
> Dear All,
> please find my notes and questions in-lined tagged GIM>>.
> 
> Regards,
> Greg
> 
> On Tue, Sep 10, 2019 at 12:58 PM Carlos Pignataro (cpignata) 
> <[email protected]> wrote:

Refreshing my cache -- since your reply is over 5.5 months after the last email 
on this -- please find inline a very quick follow-up (since you are naming me 
on your response)


> [A very late reply to this email, but since no-one else replied… to add topic 
> diversity to the list.]
> 
> SPRING chairs,
> 
> Sending this note only for completeness, and not as indication of interest or 
> support of draft-mirsky-spring-bfd-08.txt.
> Since draft-mirsky-spring-bfd has no provenance metadata 
> (Replaces/Replaced-by tags), I thought it useful to point to the ancestry of 
> this text.
> 
> TL;DR:
> 
> Two big concerns:
> 1. Review of this text (on a different draft) in the MPLS WG is 
> unacknowledged and undressed. Basically this text has technical showstoppers.
> GIM>> To the best of my understanding, all technical questions have been 
> addressed. The latest update also includes the Implementation Considerations 
> section. I believe that it is up to WG chairs to evaluate whether WG has 
> reached consensus (rough) on the WG draft.


Looking objectively at the mailing-list history [1], there has been effectively 
NO discussion about this document on the list. Other than one quick review I 
sent long ago on May 2017 [8], and I-D Action automated emails from the 
submission tool with new revisions every (expiration period =~ 6) months.

These are _all_ the emails about this draft for versions and versions during 
months and months:

I-D Action: draft-mirsky-spring-bfd-08.txt      internet-drafts 2019-08-02
I-D Action: draft-mirsky-spring-bfd-07.txt      internet-drafts 2019-02-24
I-D Action: draft-mirsky-spring-bfd-06.txt      internet-drafts 2018-08-23
I-D Action: draft-mirsky-spring-bfd-05.txt      internet-drafts 2018-03-03
I-D Action: draft-mirsky-spring-bfd-04.txt      internet-drafts 2018-02-27

And then, 1.5 years and 4 version later, there is:
Fwd: New Version Notification for draft-mirsky-spring-bfd-08.txt        Greg 
Mirsky     2019-08-02

To which the spring chair replied “Should we wait for your replies?” [2]

The fact that there was no discussion on this was already called out by Adrian 
[3] and Deborah [4] when this text lived in a different document, about 3.5 
years ago.

[1] https://mailarchive.ietf.org/arch/search/?q=%22draft-mirsky-spring-bfd%22
[2] https://mailarchive.ietf.org/arch/msg/spring/v8bCjqHxzUUy4ccumOpqyaDDCDg/
[3] https://mailarchive.ietf.org/arch/msg/mpls/DAY31G0WQPrVys8XGMO9nEHsQdM/
[4] https://mailarchive.ietf.org/arch/msg/mpls/diPhEsyo2Q48BmNNEm-WwjoRO5U/
[8] https://mailarchive.ietf.org/arch/msg/spring/XB_Co8IPSKkkEPWWPgGUIK8Rl0U/

However, these technical concerns have not been answered. Why use non-FEC when 
there are FECs defined [RFC 8287]? The use of numerical label values (these are 
LSEs and not SIDs) is a misnomer, creates conflicts between CP/DP, with LSP 
Ping, and the command/response paradigm from [RFC 7110] creates race conditions 
on network changes for a long-lived session.


> Carlos clearly has his opinion but, I believe, that is not necessarily 
> correctly reflects the opinion of MPLS WG.


The MPLS WG chairs are who can gauge the MPLS WG sentiment and opinion…

This is what I found Loa wrote [5]

[5] https://mailarchive.ietf.org/arch/msg/mpls/q3A5FfSZHTotSn5E7VGdBxy7SlI/


> 2. Potentially applicable IPR, as per the email below, is undisclosed.
> GIM>> As I understand the IPR process at IETF, a third party that believes 
> that the particular IPR (application or patent) is applicable to the given 
> document can file the IPR Disclosure. If Carlos believes that there is an 
> undisclosed IPR, then he should follow the IETF process. As for me, to the 
> best of my understanding, there's no undisclosed IPR related to this draft.


I think I was not clear. I did not mean to imply that I believe there is any 
particular applicability of a piece of IPR. I have no opinion on that, since 
I’ve not read it.

However, I do have an opinion on what appears to be a contradiction.

Greg, I would love to understand this:

Right after version -05 of draft-ietf-mpls-bfd-directed, there is this mpls 
mailing-list posting [6] by you, which says:

-->8--
Dear All,
authors decided to remove sections Segment Routing: MPLS Data Plane Case
and Bootstrapping BFD session with BFD Reverse Path over Segment Routed
tunnel from this document and address the Segment Routing case in the
future work. The new version has been submitted as
draft-ietf-mpls-bfd-directed-05
(see below) and, to the best of our knowledge and understanding, earlier
disclosed IPR is no longer applicable to this version.
-->8—

And the difference from -04 to -05 can be seen at [7], as effectively the text 
that became draft-mirsky-spring-bfd.

[6] https://mailarchive.ietf.org/arch/msg/mpls/imnwjd0the9F-F4gdHxh_J3xzq4/
[7] https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-bfd-directed-05.txt


The inconsistency or apparent contradiction that I was calling out is the 
following:

1. Removing text from draft-ietf-mpls-bfd-directed-04 into 
draft-ietf-mpls-bfd-directed-05 [7] makes the IPR be no longer applicable [6].
2. What happens when that removed text from step 1. becomes a new document, 
draft-mirsky-spring-bfd?


Anyway, this ended up being a not-totally-quick follow-up, but I thought it 
important to explicitly cite the specific pointers, add the relevant text, 
postings, explanations, and timelines.

Best,

Carlos.


> 
> Besides there being no apparent interest, there’s serious issues.
> 
> Longer version:
> 
> Martin, At the time you were shepherd of draft-ietf-mpls-bfd-directed, so you 
> might remember this.
> 
> Much of the text of draft-mirsky-spring-bfd seems to be coming from earlier 
> versions of draft-ietf-mpls-bfd-directed.
> 
> The text was removed from draft-ietf-mpls-bfd-directed during reviews in the 
> MPLS WG, instead of fixing it, and now it seems to have found its way into a 
> new document and a new WG, bypassing the previous review.
> 
> All the text from draft-ietf-mpls-bfd-directed about SRv6 was removed here: 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-bfd-directed-03.txt
> All the text from draft-ietf-mpls-bfd-directed about SR MPLS was removed 
> here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-bfd-directed-05.txt
> GIM>> Authors always welcome and appreciate comments. Changes in scope were 
> presented and accepted by MPLS WG. 
> 
> All that text received critical review and comments that can be found for 
> example at:
>       • 
> https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-mpls-bfd-directed%22%20%22Segment%20Routing%3A%20MPLS%20Data%20Plane%20Case%22
>       • 
> https://mailarchive.ietf.org/arch/search/?q=%22draft-ietf-mpls-bfd-directed%22%20%22Segment%20Routing%22
> 
> And the authors of draft-ietf-mpls-bfd-directed decided to remove it as per: 
> https://mailarchive.ietf.org/arch/msg/mpls/imnwjd0the9F-F4gdHxh_J3xzq4
> 
> This particular email to the MPLS WG has interesting text:
> "
>     authors decided to remove sections Segment Routing: MPLS Data Plane Case
> ...
>     The new version has been submitted as
>     draft-ietf-mpls-bfd-directed-05
>     (see below) and, to the best of our knowledge and understanding, earlier
>     disclosed IPR is no longer applicable to this version.
> “
> 
> Basically this seems to imply that there was IPR applicable to that text, 
> that removing it made it not applicable to the MPLS WG doc. 
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-bfd-directed
> 
> However, that text seems to have founds its way to this new doc, but there 
> does not seem to be any IPR disclosures.
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-mirsky-spring-bfd
> GIM>> As noted above, authors of draft-mirsky-spring-bfd believe that there 
> is no undisclosed IPR relevant to the draft. Any third party that believes 
> otherwise is free to follow the IETF process of IPR disclosure. 
> 
> There are still significant outstanding technical issues with this text, 
> raised in the MPLS WG under a different I-D, but still apply, as for example:
> https://mailarchive.ietf.org/arch/msg/mpls/pPq_LO8E0vIKKYLiHa50z7cFWks
> https://mailarchive.ietf.org/arch/msg/mpls/iXsENQuPWmmgsueNiUMlyRCcu4U
> https://mailarchive.ietf.org/arch/msg/mpls/X1a595fcp8D-WYGO9UkVsqum23s
> Etc.
> GIM>> As I've noted above, all the technical comments to 
> draft-ietf-mpls-bfd-directed have been addressed by authors. Changes to the 
> scope of draft-ietf-mpls-bfd-directed were made by the authors after 
> discussion in MPLS WG.
> 
> Back to your regular programming (no pun intended :-) 
> 
> Best,
> 
> Carlos.
> 
>> On Aug 2, 2019, at 12:46 PM, Greg Mirsky <[email protected]> wrote:
>> 
>> Dear All,
>> with this update, we've added a section on using BFD for Multipoint Networks 
>> (RFC 8562 and RFC 8563) for proactive defect detection in 
>> Point-to-Multipoint SR Policies.
>> Authors believe that the draft is stable and addresses p2p, as well as, p2mp 
>> use cases of SR-MPLS. We appreciate your consideration of WG adoption poll 
>> for this specification.
>> 
>> Regards,
>> Greg
>> 
>> ---------- Forwarded message ---------
>> From: <[email protected]>
>> Date: Fri, Aug 2, 2019 at 12:38 PM
>> Subject: New Version Notification for draft-mirsky-spring-bfd-08.txt
>> To: Ilya Varlashkin <[email protected]>, Gregory Mirsky 
>> <[email protected]>, Ilya Varlashkin <[email protected]>, Jeff Tantsura 
>> <[email protected]>, Mach Chen (Guoyi) <[email protected]>
>> 
>> 
>> 
>> A new version of I-D, draft-mirsky-spring-bfd-08.txt
>> has been successfully submitted by Greg Mirsky and posted to the
>> IETF repository.
>> 
>> Name:           draft-mirsky-spring-bfd
>> Revision:       08
>> Title:          Bidirectional Forwarding Detection (BFD) in Segment Routing 
>> Networks Using MPLS Dataplane
>> Document date:  2019-08-02
>> Group:          Individual Submission
>> Pages:          13
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-08.txt
>> Status:         https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
>> Htmlized:       https://tools.ietf.org/html/draft-mirsky-spring-bfd-08
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-mirsky-spring-bfd-08
>> 
>> Abstract:
>>    Segment Routing (SR) architecture leverages the paradigm of source
>>    routing.  It can be realized in the Multiprotocol Label Switching
>>    (MPLS) network without any change to the data plane.  A segment is
>>    encoded as an MPLS label, and an ordered list of segments is encoded
>>    as a stack of labels.  Bidirectional Forwarding Detection (BFD) is
>>    expected to monitor any existing path between systems.  This document
>>    defines how to use Label Switched Path Ping to bootstrap a BFD
>>    session, control path in reverse direction of the SR-MPLS tunnel and
>>    applicability of BFD Demand mode in the SR-MPLS domain.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> The IETF Secretariat
>> 
>> _______________________________________________
>> spring mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/spring
> 

_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring

Reply via email to