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


On Wed, May 10, 2017 at 9:40 PM, Robert Raszuk <rob...@raszuk.net> 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.
>
> 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) <
> cpign...@cisco.com> 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/ma
>> il-archive/web/mpls/current/msg16091.html
>>
>> Thanks,
>>
>> — Carlos.
>>
>>
>>
>> On May 9, 2017, at 3:43 PM, Greg Mirsky <gregimir...@gmail.com> 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) <
>> cpign...@cisco.com> 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 <gregimir...@gmail.com> 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) <
>>> cpign...@cisco.com> 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 <gregimir...@gmail.com> 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: <internet-dra...@ietf.org>
>>>> Date: Mon, May 8, 2017 at 8:29 PM
>>>> Subject: New Version Notification for draft-mirsky-spring-bfd-00.txt
>>>> To: Gregory Mirsky <gregimir...@gmail.com>
>>>>
>>>>
>>>>
>>>> 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
>>>> m...@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mpls
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Reply via email to