Re: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand

<xiao.min2@zte.com.cn> Sat, 27 October 2018 05:07 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BF01292AD for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 22:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t1QIz1rz10s for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 22:07:48 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137C812785F for <rtg-bfd@ietf.org>; Fri, 26 Oct 2018 22:07:47 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 39761BA994046F74A1BE; Sat, 27 Oct 2018 13:07:45 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse02.zte.com.cn with SMTP id w9R57dRT013022; Sat, 27 Oct 2018 13:07:39 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid201; Sat, 27 Oct 2018 13:07:41 +0800 (CST)
Date: Sat, 27 Oct 2018 13:07:41 +0800 (CST)
X-Zmail-TransId: 2afb5bd3f29d8912fa6f
X-Mailer: Zmail v1.0
Message-ID: <201810271307410222765@zte.com.cn>
In-Reply-To: <75D9EDEC-68A6-4053-8931-39CFE3CCEA29@cisco.com>
References: 20181017222431.GK17157@pfrc.org, 75D9EDEC-68A6-4053-8931-39CFE3CCEA29@cisco.com
Mime-Version: 1.0
From: <xiao.min2@zte.com.cn>
To: <cpignata@cisco.com>
Cc: <jhaas@pfrc.org>, <rtg-bfd@ietf.org>
Subject: =?UTF-8?B?UmU6IFJlOiBXRyBBZG9wdGlvbiByZXF1ZXN0IGZvciBkcmFmdC1taXJza3ktYmZkLW1wbHMtZGVtYW5k?=
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse02.zte.com.cn w9R57dRT013022
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/uI586UOXD8_hQw8WEPABAHKuTCY>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-bfd/>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Oct 2018 05:07:51 -0000

Hi Carlos,






My answers to your two questions are as follow:


In section 6.6 of RFC5880, just after the text you quoted, it says "One possible mechanism is the receipt of traffic from the remote system; another is the use of the Echo function." So I'm not sure what's your real concern.


In the abstract of this draft it says "This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths." If you don't like the expression form of the text quoted by you, pls feel free to propose some text.






Best Regards,


Xiao Min



原始邮件



发件人:CarlosPignataro(cpignata) <cpignata@cisco.com>
收件人:肖敏10093570;
抄送人:Jeff Haas <jhaas@pfrc.org>;rtg-bfd@ietf.org <rtg-bfd@ietf.org>;
日 期 :2018年10月26日 12:04
主 题 :Re: WG Adoption request for draft-mirsky-bfd-mpls-demand


Xiao, 
Scanning through the draft, two questions:
 
1. What is the underlying mechanism to check liveness such that Demand can be used?
 
https://tools.ietf.org/html/rfc5880#section-6.6
 

   Demand mode requires that some other mechanism is used to imply

   continuing connectivity between the two systems.  The mechanism used
 

2. Is this draft testing liveness of a path or a node?
 
https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-03#section-3
 

   In this state BFD peers MAY remain as long as the egress LER is in Up

   state.  The ingress LER MAY check liveness of the egress LER by

   setting the Poll flag.  The egress LER will respond by transmitting
 

 


Thanks,
 
— Carlos Pignataro


 
On Oct 19, 2018, at 9:59 PM, xiao.min2@zte.com.cn wrote:
 


I support WG adoption of this draft. Use of the demand mode for p2p LSP monitoring is feasible and required.


 


Best Regards,


Xiao Min


 




 






发件人:JeffreyHaas <jhaas@pfrc.org>

收件人:rtg-bfd@ietf.org <rtg-bfd@ietf.org>;

日 期 :2018年10月18日 06:24

主 题 :WG Adoption request for draft-mirsky-bfd-mpls-demand



Working Group, The BFD chairs have received an adoption request for  "BFD in Demand Mode over Point-to-Point MPLS LSP" (draft-mirsky-bfd-mpls-demand). https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ The adoption call will end on the Friday after IETF 103, November 9. Note that there is are existing IPR statements on this draft: https://datatracker.ietf.org/ipr/3301/ https://datatracker.ietf.org/ipr/3104/ Please indicate to the mailing list whether you support adoption of this draft. -- Jeff & Reshad