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

"Nobo Akiya (nobo)" <nobo@cisco.com> Wed, 14 May 2014 16:15 UTC

Return-Path: <nobo@cisco.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 3FAB51A02DB; Wed, 14 May 2014 09:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.152
X-Spam-Level:
X-Spam-Status: No, score=-115.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, 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 DHYFWJexeHCq; Wed, 14 May 2014 09:15:51 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C58171A02D1; Wed, 14 May 2014 09:15:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2308; q=dns/txt; s=iport; t=1400084145; x=1401293745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vALBYOMgAgdCALd2WcFvi6W+Zyvw3V3y8THB/n+8Xa4=; b=EaiE2GrxtL98cXNi8U8IHBsT1nBYzxANlS/m0CB4IyWDT8yz3Y4FSFOH cqwg6MnJCD3bvyz+QTYPluvH7ugo+Wr5SuiGG0BfKchpLDMmPGedBGugS m8s6jUbdi+k7GV1jqjD3yZ0T0QJdWkyFiNJUzzzj47O30nhGSQ+YFCRQC 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAGyVc1OtJV2P/2dsb2JhbABZgmUhgSfFbwGBIxZ0giUBAQEEOj0CDAQCAQgRBAEBAQoUCQcyFAkIAgQOBQiIOQHRHBeOHTEHBoMlgRUBA6xlgXeBP4Iw
X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="324892528"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-3.cisco.com with ESMTP; 14 May 2014 16:15:45 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s4EGFia2021463 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 16:15:44 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 14 May 2014 11:15:44 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
Thread-Index: AQHPasw+3TfBhqItW0CgAHCwI2S40Zs3F30AgAliegCAABUCAIAAARwAgAACvoD//61T8IAAWImA//+vVVA=
Date: Wed, 14 May 2014 16:15:43 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E14EDA1@xmb-aln-x01.cisco.com>
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>
In-Reply-To: <20140514155739.GA14148@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [161.44.212.77]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/T4WuAIsEbdEbYWfNle3r_aHnJ9E
Cc: Jeffrey Haas <jhaas@pfrc.org>, "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, 14 May 2014 16:15:55 -0000

Hi Hannes,

Please see in-line.

> -----Original Message-----
> From: Hannes Gredler [mailto:hannes@juniper.net]
> Sent: Wednesday, May 14, 2014 11:58 AM
> To: Nobo Akiya (nobo)
> Cc: Jeffrey Haas; 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
> 
> On Wed, May 14, 2014 at 03:48:10PM +0000, Nobo Akiya (nobo) wrote:
> | Hi Jeff,
> |
> | > On Wed, May 14, 2014 at 05:26:52PM +0200, Hannes Gredler wrote:
> | > > On May 14, 2014, at 5:22 PM, Les Ginsberg (ginsberg) wrote:
> | > > > Thanx for the comments.
> | > > > I don't see how your proposal solves the problem you are
> | > > > attempting to
> | > address. The sender of the S-BFD packet has no control over what
> | > interface is used to receive the packet on the target node.
> | > Associating it with a prefix will not help in that regard.
> | > >
> | > > well it would help first endpoint discovery and pinning down BFD
> | > > traffic to
> | > particular line card.
> | >
> | > Indeed.  In the SPRING related case (or even some MPLS scenarios),
> | > traffic may be heavily steered to a given interface.  This interface
> | > may not even be to a router, but may be an ingress for a SFC device
> | > and that ingress is critical for the execution of the chain.
> |
> | In those cases, one should be sending S-BFD packet in-band, which would
> go through the specific interface/LC to reach the reflector session on the
> target node (i.e. outage will be detected regardless of the discriminator
> used). So having separate reflector discriminator won't be adding further
> benefit.
> |
> | Flip side is, if a reflector is hosted on LC 1 and traffic engineered tunnel is
> terminating on LC2, then outage of LC1 can cause the "no S-BFD response"
> on the tunnel terminating on LC2. However, I would think this is a limitation
> with implementation.
> 
> what about AF discovery ? - how would a receiver know what AF a S-BFD
> session to bring up with ?

I was under the impression that IP header (i.e version) can distinguish the AF if implementations required demux'ing received S-BFD packet based on AF. If I missed your point/question, do clarify.

-Nobo