Subject: Fwd: New Version Notification for draft-mirsky-spring-bfd-00.txt

From: Greg Mirsky <[email-masked]>
Date: Mon, 8 May 2017 20:33:08 -0700

Dear All,
perhaps this new draft may is of interest to you.
Your comments, suggestions are most welcome and greatly appreciated.

Regards,
Greg

---------- Forwarded message ----------
From: <[email-masked]>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <[email-masked]>

A new version of I-D, draft-mirsky-spring-bfd-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-mirsky-spring-bfd
Revision:       00
Title:          Bidirectional Forwarding Detection (BFD) in Segment Routing
Networks Using MPLS Dataplane
Document date:  2017-05-08
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd
-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:       https://tools.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-spring-b
fd-00

Abstract:
   Segment Routing 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 kind of paths between systems.  This document
   defines how to use Label Switched Path Ping to bootstrap and control
   path in reverse direction of a BFD session on the Segment Routing
   network over MPLS dataplane.

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

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 May 2017 15:51:38 +0000

Dear Greg,

Cursorily scanning through this, it seems that most concerns raised and comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N (with N < 5) apply to your new draft.

This is one of those: https://www.ietf.org/mail-archive/web/mpls/current/msg15860.html — the list archive shows a few more. The copy/paste did not address the comments.

Best,

— Carlos.

On May 8, 2017, at 11:33 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear All,

Regards,
Greg

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>

Name:           draft-mirsky-spring-bfd
Revision:       00
Title:          Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using MPLS Dataplane
Document date:  2017-05-08
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-mirsky-spring-bfd-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mirsky-spring-bfd/
Htmlized:       https://tools.ietf.org/html/draft-mirsky-spring-bfd-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-spring-bfd-00

Abstract:

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<http://tools.ietf.org/>.

The IETF Secretariat

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 May 2017 09:00:22 -0700

Dear Carlos,
I've decided to re-start the discussion and am interested to hear technical
comments to the proposed solution.

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Dear Greg,
>
> Cursorily scanning through this, it seems that most concerns raised and
> comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N
> (with N < 5) apply to your new draft.
>
> This is one of those: https://www.ietf.org/mail-archive/web/mpls/current/
> msg15860.html — the list archive shows a few more. The copy/paste did not
> address the comments.
>
> Best,
>
> — Carlos.
>
> On May 8, 2017, at 11:33 PM, Greg Mirsky <[email-masked]> wrote:
>
> Dear All,
> [email-masked]

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 9 May 2017 16:07:22 +0000

Thank you Greg!

Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite similar to the text removed at https://tools.ietf.org/rfcdiff?url2=draft-ietf-mpls-bfd-directed-05.txt, then the complete set of outstanding technical comments that triggered the removal of that text from draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-)

One that I recall is: why use label values when every other return-path sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed, uses TFSs?

Best,

— Carlos.

On May 9, 2017, at 12:00 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Dear Carlos,
I've decided to re-start the discussion and am interested to hear technical comments to the proposed solution.

Regards,
Greg

On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Dear Greg,

Best,

— Carlos.

Dear All,

Regards,
Greg

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 9 May 2017 12:43:54 -0700

Hi Carlos,
I probably would characterize anything that starts with Why not as a
technical comment but rather as a question.
According to draft-ietf-spring-segment-routing-mpls, "In the MPLS dataplane,the
SR header is instantiated through a label stack".
At the same time, one of advantages of SR is that "per-flow state only
[maintained] at the ingress node to the SR domain".
Thus, for the case of monitoring unidirectional SR tunnels, I consider that
there's no need to create any additional state on the egress node.
Of course, if there were bidirectional SR tunnels, then control of the
reverse direction of the BFD session would not require use of the Return
Path sub-TLV.
As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel
sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the
proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Thank you Greg!
>
> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems quite
> similar to the text removed at https://tools.ietf.org/
> rfcdiff?url2=draft-ietf-mpls-bfd-directed-05.txt, then the complete set
> of outstanding technical comments that triggered the removal of that text
> from draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-)
>
> One that I recall is: why use label values when every other return-path
> sub-TLV for BFD and for LSP-Ping, including draft-ietf-mpls-bfd-directed,
> uses TFSs?
>
> Best,
>
> — Carlos.
>
> On May 9, 2017, at 12:00 PM, Greg Mirsky <[email-masked]> wrote:
>
> Dear Carlos,
> I've decided to re-start the discussion and am interested to hear
> technical comments to the proposed solution.
>
> Regards,
> Greg
>
>> This is one of those: https://www.ietf.org/ma
>> il-archive/web/mpls/current/msg15860.html — the list archive shows a few
>> more. The copy/paste did not address the comments.
>>
>> Best,
>>
>> — Carlos.
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 May 2017 19:24:52 +0000

Greg,

In the MPLS data plane, FECs are also instantiated through a label stack. But RFC 7110 does not use numeric label values, it uses TFSs. That does not create any additional state. E.g.,: https://www.ietf.org/mail-archive/web/mpls/current/msg16091.html

Thanks,

— Carlos.

On May 9, 2017, at 3:43 PM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carlos,
I probably would characterize anything that starts with Why not as a technical comment but rather as a question.
According to draft-ietf-spring-segment-routing-mpls, "In the MPLS dataplane,the SR header is instantiated through a label stack".
At the same time, one of advantages of SR is that "per-flow state only [maintained] at the ingress node to the SR domain".
Thus, for the case of monitoring unidirectional SR tunnels, I consider that there's no need to create any additional state on the egress node.
Of course, if there were bidirectional SR tunnels, then control of the reverse direction of the BFD session would not require use of the Return Path sub-TLV.
As for LSP-Ping, I just propose that the Segment Routing MPLS Tunnel sub-TLV MAY be used Reply Path TLV defined in RFC 7110. I viewed the proposal as invitation to technical discussion.

Regards,
Greg

On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Greg!

Best,

— Carlos.

Dear Carlos,

Regards,
Greg

Best,

— Carlos.

Dear All,

Regards,
Greg

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 May 2017 21:40:00 +0200

Hi Carlos,

Sorry what is "TFS" ?

RFC 7110 does not even use such abbreviation neither do
draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless
about it.

Just curious as you keep using this term in each email :)

Thx,
R.

On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> Greg,
>
> In the MPLS data plane, FECs are also instantiated through a label stack.
> But RFC 7110 does not use numeric label values, it uses TFSs. That does not
> create any additional state. E.g.,: https://www.ietf.org/
> mail-archive/web/mpls/current/msg16091.html
>
> Thanks,
>
> — Carlos.
>
>
>
> On May 9, 2017, at 3:43 PM, Greg Mirsky <[email-masked]> wrote:
>
> Hi Carlos,
> According to draft-ietf-spring-segment-routing-mpls, "In the MPLS
> dataplane,the SR header is instantiated through a label stack".
> Thus, for the case of monitoring unidirectional SR tunnels, I consider
> that there's no need to create any additional state on the egress node.
>> similar to the text removed at https://tools.ietf.org/rfcdiff
>> ?url2=draft-ietf-mpls-bfd-directed-05.txt, then the complete set of
>> outstanding technical comments that triggered the removal of that text from
>> draft-ietf-mpls-bfd-directed-05.txt might peek your interest :-)
>>
>>> il-archive/web/mpls/current/msg15860.html — the list archive shows a
>>> few more. The copy/paste did not address the comments.
>>>
>>> Best,
>>>
>>> — Carlos.
>>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 10 May 2017 21:41:59 +0200

Never mind .. I guess you made it up from "Target FEC Stack" :)

On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk <[email-masked]> wrote:

>> create any additional state. E.g.,: https://www.ietf.org/ma
>> il-archive/web/mpls/current/msg16091.html
>>
>> Thanks,
>>
>> — Carlos.
>>
>>
>>
>>> Since https://tools.ietf.org/html/draft-mirsky-spring-bfd-00 seems
>>> quite similar to the text removed at https://tools.ietf.org/rfcdiff

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 May 2017 20:01:52 +0000

You are right — sorry about that! “TFS” is not used in any of those RFCs or drafts, although it is used on email discussions about LSP Ping.

Indeed, TFS for “Target FEC Stack” from Section 3.2 of RFC 8029.

Thanks,

— Carlos.

On May 10, 2017, at 3:41 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Carlos,

Sorry what is "TFS" ?

RFC 7110 does not even use such abbreviation neither do draft-ietf-mpls-bfd-directed :) Google also seems to be pretty clueless about it.

Thx,
R.

On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <[email-masked]<mailto:[email-masked]>> wrote:
Greg,

Thanks,

— Carlos.

Hi Carlos,

Regards,
Greg

Best,

— Carlos.

Dear Carlos,

Regards,
Greg

Best,

— Carlos.

Dear All,

Regards,
Greg

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Mon, May 8, 2017 at 8:29 PM
Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 10 May 2017 14:23:48 -0700

Hi Carlos,
RFC 7110 defined sub-TLVs by extensively re-using TFS sub-TLVs. Even more,
they've referenced explanations of fields to the TFS-defining RFCs. I guess
only Flags field was introduced in RFC 7110 with Primary and Secondary bit
flag fields being defined.

As, I've said in the discussion on BFD directed, this is proposal, it make
sense to me as the head-end has all the information already. I always
welcome technical comments and appreciate well-argumented discussion. What
would be the reason not to use the proposed approach but do it TFS-like
style?

Regards,
Greg

On Wed, May 10, 2017 at 1:01 PM, Carlos Pignataro (cpignata) <
[email-masked]> wrote:

> You are right — sorry about that! “TFS” is not used in any of those RFCs
> or drafts, although it is used on email discussions about LSP Ping.
>
> On May 10, 2017, at 3:41 PM, Robert Raszuk <[email-masked]> wrote:
>
>
>>> In the MPLS data plane, FECs are also instantiated through a label
>>> stack. But RFC 7110 does not use numeric label values, it uses TFSs. That
>>> does not create any additional state. E.g.,: https://www.ietf.org/ma
>>>>> Cursorily scanning through this, it seems that most concerns raised
>>>>> and comments made about the SR sections of draft-ietf-mpls-bfd-directed-0N

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 May 2017 21:46:58 +0000

Greg,

> On May 10, 2017, at 5:23 PM, Greg Mirsky <[email-masked]> wrote:
> 
> Hi Carlos,
> RFC 7110 defined sub-TLVs by extensively re-using TFS sub-TLVs. Even more, they've referenced explanations of fields to the TFS-defining RFCs. I guess only Flags field was introduced in RFC 7110 with Primary and Secondary bit flag fields being defined.
> 
> As, I've said in the discussion on BFD directed, this is proposal, it make sense to me as the head-end has all the information already. I always welcome technical comments and appreciate well-argumented discussion.

From my perspective, the well argument discussion already happened on this exact text and this proposed approach. They happened already twice on multiple WGLCs in BFD, and that text was removed. Asking again under a different draft filename does not change the arguments already presented.

The proposal is broken.

> What would be the reason not to use the proposed approach but do it TFS-like style?
> 

You can read these reasons on the list archives on the previous discussion. I answered this question already. But, for completeness:

Label values can change. With labels there is no validation possible that what distributed by a given label distribution protocol is what is meant in the data plane. 

More importantly, again, a technical example of why this is broken and backwards:

https://tools.ietf.org/html/draft-mirsky-spring-bfd-00#section-4 says:

   The IANA is requested to assign new sub-TLV type from "Multiprotocol
   Label Switching Architecture (MPLS) Label Switched Paths (LSPs) Ping
   Parameters - TLVs" registry, "Sub-TLVs for TLV Types 1, 16, and 21"
   sub-registry.

     +---------+-------------------------------------+---------------+
     | Value   | Description                         | Reference     |
     +---------+-------------------------------------+---------------+
     | X (TBD) | Segment Routing MPLS Tunnel sub-TLV | This document |
     +---------+-------------------------------------+---------------+

Now, TLV Types 1, 16, and 21 for MPLS LSP Ping are 

         1   Target FEC Stack
      16    Reverse-path Target FEC Stack
      21    Reply Path 

MPLS LSP Ping TLVs 1, 16, and 21 need a sub-TLV with a FEC. Not with a Label value. That is why, TLV 1 is called “Target FEC Stack” (sometimes referred to informally as TFS)

However, you are defining a protocol structure that holds numeric Label values, and you somehow want that to be used in TLV 1 for MPLS LSP Ping…

How do you envision this to work with https://tools.ietf.org/html/rfc8029#section-3.2? 

That is yet another reason why FECs are being defined at:
https://tools.ietf.org/html/draft-ietf-mpls-spring-lsp-ping-02

Hope that helps,

— Carlos.
PS: As I find this repetitive, this is my last email on the subject.

> Regards,
> Greg
> 
> On Wed, May 10, 2017 at 1:01 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
>> On Wed, May 10, 2017 at 9:24 PM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
>> Greg,
>> 
>>> On Tue, May 9, 2017 at 9:07 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
>>> Thank you Greg!
>>> 
>>>> On Tue, May 9, 2017 at 8:51 AM, Carlos Pignataro (cpignata) <[email-masked]> wrote:
>>>> Dear Greg,
>>>>