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 protected]> 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 protected]] > *Sent:* Saturday, November 9, 2019 6:29 PM > *To:* [email protected]; 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 protected]> > Date: Fri, Aug 2, 2019 at 9:46 AM > Subject: Fwd: New Version Notification for draft-mirsky-spring-bfd-08.txt > To: spring <[email protected]>, <[email protected]> > > > > 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 > > _________________________________________________________________________________________________________________________ > > 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. > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
