Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

Gregory Mirsky <gregory.mirsky@ericsson.com> Wed, 21 May 2014 01:21 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE7C1A03F5; Tue, 20 May 2014 18:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level:
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 FKseOkfwCvZL; Tue, 20 May 2014 18:21:46 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1491E1A03F0; Tue, 20 May 2014 18:21:46 -0700 (PDT)
X-AuditID: c6180641-f79df6d000002de0-fc-537bad84a2a8
Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 4A.DA.11744.48DAB735; Tue, 20 May 2014 21:31:17 +0200 (CEST)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0174.001; Tue, 20 May 2014 21:21:43 -0400
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, Mach Chen <mach.chen@huawei.com>, Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
Thread-Index: AQHPasw+ft5/3BK2OUCTWOWP0ceEqZs2wwSAgAmmLwCAABUDAIAAARwAgAACvoCAAAM1AIAAAqaAgAAFDYCAAAIFgIAACvUAgAERhQCAAE/xgIAIJyKAgABv9QD//72YMA==
Date: Wed, 21 May 2014 01:21:42 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se>
References: <20140508144606.23448.98448.idtracker@ietfa.amsl.com> <F3ADE4747C9E124B89F0ED2180CC814F23D873B9@xmb-aln-x02.cisco.com> <9DDF3832-A276-40F1-AF24-2CEAB31E63DC@juniper.net> <F3ADE4747C9E124B89F0ED2180CC814F23DB5518@xmb-aln-x02.cisco.com> <922372D3-6CE8-461E-9BD4-94C2B050C37D@juniper.net> <20140514153641.GC13993@pfrc> <CECE764681BE964CBE1DFF78F3CDD3941E14ED44@xmb-aln-x01.cisco.com> <20140514155739.GA14148@juniper.net> <CECE764681BE964CBE1DFF78F3CDD3941E14EDA1@xmb-aln-x01.cisco.com> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <CECE764681BE964CBE1DFF78F3CDD3941E14EE6A@xmb-aln-x01.cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9C4A26@SZXEMA510-MBX.china.huawei.com> <CECE764681BE964CBE1DFF78F3CDD3941E150962@xmb-aln-x01.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> <CECE764681BE964CBE1DFF78F3CDD3941E157C55@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E157C55@xmb-aln-x01.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyuXRPoG7r2upgg8a5XBYb/mxkt+i/94TN 4uih96wWF9YKW8zuiLf4/GcbowObx5TfG1k9Wo68ZfVYsuQnk8f1pqvsASxRXDYpqTmZZalF +nYJXBn9J9YwFrTJVhzd9pW5gXGfeBcjJ4eEgInEuWUtbBC2mMSFe+vBbCGBo4wSh27ndjFy AdnLGSX+fFzACJJgEzCSeLGxhx3EFhEolOg8voAJpIhZoIlRortzFliRsECyxP2GU2wQRSkS zd++MIIUiQhMYpT492odWIJFQFXiT8dusAZeAV+Jn+dWs0Cs62GX+HDtJ1ARBwcnUOLxUi6Q Gkag876fWsMEYjMLiEvcejKfCeJsAYkle84zQ9iiEi8f/2OFsJUkJi09xwpRryOxYPcnNghb W2LZwtfMEHsFJU7OfMIygVFsFpKxs5C0zELSMgtJywJGllWMHKXFqWW56UaGmxiBEXZMgs1x B+OCT5aHGAU4GJV4eBeoVwcLsSaWFVfmHmKU5mBREufdc60qWEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVANj0APmF4lRNr+Pdz36cmtbZO52jYcpzncSmQUmvXwm+6rKQk/5Au/yWSHKNj8C DV1r/kY5FFYWRvw4YNRl4HFE3vCSrWh/UQGDrTN3v175muAgo7WK35XPbDKP0F1izij7fcmP PdvnaMWKxkx8pv7tDmfH2dbHwv7bZ16197G8OiNmybRtW3KVWIozEg21mIuKEwEBZznFkQIA AA==
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/5S6jIjG9l_lWRRBS_wBGc3-3Rlg
Cc: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 May 2014 01:21:48 -0000

Hi Nobo,
I like it.

	Regards,
		Greg

-----Original Message-----
From: Nobo Akiya (nobo) [mailto:nobo@cisco.com] 
Sent: Tuesday, May 20, 2014 6:18 PM
To: Gregory Mirsky; Mach Chen; Hannes Gredler
Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
Subject: RE: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt

Hi Greg,

That's true, the whole paragraph in the section 7 of S-BFD base document is just describing some possible implementation techniques. How about we change the paragraph:

[old]
   Note that incoming BFD control packets destined to BFD target
   identifier types may be IPv4, IPv6 or MPLS based.  For those BFD
   target identifier types, implementations MAY either allow the same
   reflector BFD session to handle all incoming BFD control packets in
   address family agnostic fashion, or setup multiple reflector BFD
   sessions to handle incoming BFD control packets with different
   address families.  This policy is again a local matter, and is
   outside the scope of this document.

[new]
   Note that incoming BFD control packets destined to BFD target
   identifier types may be IPv4, IPv6 or MPLS based.  How such packets
   reach an appropriate reflector BFD session is a local matter, and is
   outside the scope of this document.

-Nobo

> -----Original Message-----
> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> Sent: Tuesday, May 20, 2014 6:46 PM
> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler
> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
> Subject: RE: [Isis-wg] New Version Notification for 
> draft-ginsberg-isis-sbfd- discriminator-00.txt
> 
> Dear All,
> according to Section 7 of the S-BFD Base document differentiation 
> among address families by S-BFD is optional and mention in connection 
> to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've 
> missed that part of S-BFD Base discussion but I don't see the benefit of supporting such mode.
> BFD control packets been AF-agnostic since RFC 5880 and I think that 
> S-BFD should maintain that approach.
> 
> I agree with Mach that discriminators in S-BFD, as well as in BFD, are 
> and must remain AF blind.
> 
> 	Regards,
> 		Greg
> 
> -----Original Message-----
> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo 
> Akiya
> (nobo)
> Sent: Thursday, May 15, 2014 7:07 AM
> To: Mach Chen; Hannes Gredler
> Cc: Les Ginsberg (ginsberg); rtg-bfd@ietf.org; isis-wg@ietf.org
> Subject: RE: [Isis-wg] New Version Notification for 
> draft-ginsberg-isis-sbfd- discriminator-00.txt
> 
> Hi Mach, Hannes, et al,
> 
> > IMHO, the capability issue should not be a S-BFD specific issue, 
> > even not BFD specified issue. It is actually a forwarding capability 
> > issue, it is about whether the target node can process IPv4, IPv6, 
> > MPLS, SR encapsulated BFD packets.
> 
> I agree Mach, mostly :)
> 
> I can also see one arguing that forwarding supporting X does not 
> always mean S-BFD is supported on X. If we want to address this, then 
> it is an S-BFD specific issue, and we _may_ want to solve this via 
> introducing S-BFD capability advertisements.
> 
> With that said, S-BFD discriminator advertisement is one area which 
> the capability problem can be solved, but not necessary a problem that 
> has to be solved with S-BFD discriminator advertisement. Rather I 
> don't think the two should be bundled together.
> 
> Let us continue the capability discussion separate from the 
> discriminator advertisements?
> 
> -Nobo
>