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 protected]> 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 protected]> 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 protected]> 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/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.
>>
>> On May 8, 2017, at 11:33 PM, Greg Mirsky <[email protected]> wrote:
>>
>> 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 protected]>
>> Date: Mon, May 8, 2017 at 8:29 PM
>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
>> To: Gregory Mirsky <[email protected]>
>>
>>
>>
>> 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-bfd-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
>>
>>
>> _______________________________________________
>> mpls mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>>
>>
>
>

Reply via email to