Subject: Re: [spring] New Version Notification for draft-mirsky-spring-bfd-08.txt

From: Greg Mirsky <[email-masked]>
Date: Mon, 9 Dec 2019 10:03:43 -0800

Hi Bruno,
I've read the e-mail you've referenced but I cannot find any technical
substance. I don't find it productive to engage in the discussion of
whether there is or there isn't IPR relevant to draft-mirsky-spring-bfd. I,
as one of the authors of the draft, don't know of any undisclosed IPR
related to this draft. Anyone who knows otherwise can submit IETF IPR
Disclose.
Also, as I understand, merging or splitting drafts is not an uncommon
practice. The authors had agreed that the use case for the Non-FEC TLV is
more applicable to SPRING WG.
As for the state of discussion of draft-ietf-mpls-bfd-directed
<https://datatracker.ietf.org/doc/draft-ietf-mpls-bfd-directed/> I think
that MPLS WG chair's opinion should be listened to, not of one of the
participants of the discussion.

Regards,
Greg

On Sat, Nov 9, 2019 at 12:47 PM <[email-masked]> wrote:

> Dear Greg,
>
>
>
> Carlos made some significant comments to your draft.
>
> I was kind of expecting that you would reply. Should we wait for your
> replies?
>
>
>
> Regards,
>
> --Bruno
>
>
>
>
>
> *From**:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* Saturday, November 9, 2019 6:29 PM
> *To:* [email-masked]; spring
> *Subject:* Fwd: New Version Notification for
> draft-mirsky-spring-bfd-08.txt
>
>
>
>
> Dear SPRING WG Chairs,
>
> still awaiting your response to the inquiry below.
>
>
>
> Regards,
>
> Greg
>
> ---------- Forwarded message ---------
> From: *Greg Mirsky* <[email-masked]>
> Date: Fri, Aug 2, 2019 at 9:46 AM
> Subject: Fwd: New Version Notification for draft-mirsky-spring-bfd-08.txt
> To: spring <[email-masked]>, <[email-masked]>
>
>
>
> 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-masked]>
> Date: Fri, Aug 2, 2019 at 12:38 PM
> Subject: New Version Notification for draft-mirsky-spring-bfd-08.txt
> To: Ilya Varlashkin <[email-masked]>, Gregory Mirsky <
> [email-masked]>, Ilya Varlashkin <[email-masked]>, Jeff Tantsura
> <[email-masked]>, Mach Chen (Guoyi) <[email-masked]>
>
>
>
>
> 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
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>