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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Sat, 27 October 2018 15:45 UTC

Return-Path: <cpignata@cisco.com>
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 8C017130DE7 for <rtg-bfd@ietfa.amsl.com>; Sat, 27 Oct 2018 08:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 c0p-abxYAJJ7 for <rtg-bfd@ietfa.amsl.com>; Sat, 27 Oct 2018 08:45:00 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8EA130DDD for <rtg-bfd@ietf.org>; Sat, 27 Oct 2018 08:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18909; q=dns/txt; s=iport; t=1540655100; x=1541864700; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hsucHPydu90oKRblv0Qs97IQbRRChtiN8XCf1iZ6De8=; b=HjYj0JU3tJ1S+NW4RxBjNI7QxeCtXw7/nabekk6GmHL5yw0IiyZ4PR/W gz0i/8+mBfj3xJChbfqw7ggr92/BoeZKQlciXQo2aixReF/rS4uNElZVR DloxnKIKD/Rm1MNPTdwQs+qxt7rS/9DS1ATNJIa8oCMy3HrXG3QGLLW16 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AqAAC2h9Rb/5xdJa1jHAEBAQQBAQcEAQGBUQcBAQsBgQ1NKmZ/KIN1iBiMF4FokXqFS4F6CwEBI4RJAheDASE0DQ0BAwEBAgEBAm0cAQuFOwYjSwsQAgEGAj8DAgICMBQRAgQOBYMhAYEdZA+LPZtOgS6ELAERQD2EVwWLZxeBQT+BEScME4FOfoEoGQGBWQEBAgEBhGExgiYCiGCFaoYiih0JAoZoihoYgVKEd4l+iVmDF4oFAhEUgSYdOIFVcBU7KgGCQYIygQgBCIdWhT5vAY0HAQE
X-IronPort-AV: E=Sophos;i="5.54,432,1534809600"; d="scan'208,217";a="472317455"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Oct 2018 15:44:58 +0000
Received: from XCH-RTP-020.cisco.com (xch-rtp-020.cisco.com [64.101.220.160]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id w9RFiwdA008308 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 27 Oct 2018 15:44:58 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-020.cisco.com (64.101.220.160) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 27 Oct 2018 11:44:57 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1395.000; Sat, 27 Oct 2018 11:44:57 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "xiao.min2@zte.com.cn" <xiao.min2@zte.com.cn>
CC: "jhaas@pfrc.org" <jhaas@pfrc.org>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: WG Adoption request for draft-mirsky-bfd-mpls-demand
Thread-Topic: WG Adoption request for draft-mirsky-bfd-mpls-demand
Thread-Index: AQHUbgwD5QWe87FDVESXKSPa+3sEcg==
Date: Sat, 27 Oct 2018 15:44:57 +0000
Message-ID: <773591B5-C44C-4F18-9521-9B3302C40093@cisco.com>
References: 20181017222431.GK17157@pfrc.org, 75D9EDEC-68A6-4053-8931-39CFE3CCEA29@cisco.com, <201810271307410222765@zte.com.cn>
In-Reply-To: <201810271307410222765@zte.com.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_773591B5C44C4F1895219B3302C40093ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.160, xch-rtp-020.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/-sKMYWtSbqTUXRwJrxfzILyYqc4>
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 15:45:04 -0000

Hi Xiao,

Thanks much for the quick response!

Please find my follow ups:

1. Sorry if I was not clear. Yes, RFC 5880 lists exemplary possible mechanisms to glean continued connectivity but requires the use of one. My question is: which mechanisms does this draft propose? Could it please be spelled out?

2. Again, apologies if I was not clean enough. I understand what the abstract says, but the quoted text says that live was needs to be checked for a node (egress LER) instead of the forwarding path. Does that mean ~ “of the forwarding path towards/upto the node”?

Thanks for your consideration.

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Oct 27, 2018, at 01:07, "xiao.min2@zte.com.cn<mailto:xiao.min2@zte.com.cn>" <xiao.min2@zte.com.cn<mailto:xiao.min2@zte.com.cn>> wrote:


Hi Carlos,


My answers to your two questions are as follow:

  1.  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.

  2.  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<mailto:cpignata@cisco.com>>
收件人:肖敏10093570;
抄送人:Jeff Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>;rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> <rtg-bfd@ietf.org<mailto: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<mailto: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<mailto:jhaas@pfrc.org>>
收件人:rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org> <rtg-bfd@ietf.org<mailto: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