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

Hannes Gredler <hannes@juniper.net> Wed, 14 May 2014 16:23 UTC

Return-Path: <hannes@juniper.net>
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 B891D1A02E1; Wed, 14 May 2014 09:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 g-zoU64MVKxx; Wed, 14 May 2014 09:23:10 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0098.outbound.protection.outlook.com [207.46.100.98]) by ietfa.amsl.com (Postfix) with ESMTP id D777D1A02D1; Wed, 14 May 2014 09:23:08 -0700 (PDT)
Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) by BL2PR05MB066.namprd05.prod.outlook.com (10.255.232.19) with Microsoft SMTP Server (TLS) id 15.0.944.11; Wed, 14 May 2014 16:23:00 +0000
Received: from [172.29.4.101] (66.129.239.16) by pod51010.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.459.0; Wed, 14 May 2014 16:23:00 +0000
MIME-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Hannes Gredler <hannes@juniper.net>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E14EDA1@xmb-aln-x01.cisco.com>
Date: Wed, 14 May 2014 18:22:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net>
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>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>
X-Mailer: Apple Mail (2.1283)
X-Originating-IP: [66.129.239.16]
X-Forefront-PRVS: 0211965D06
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(13464003)(24454002)(377454003)(199002)(189002)(19580395003)(87286001)(87936001)(21056001)(83072002)(92566001)(89996001)(20776003)(82746002)(76176999)(50466002)(4396001)(19580405001)(97756001)(66066001)(81342001)(80022001)(85852003)(64706001)(50226001)(47776003)(83322001)(99396002)(88136002)(50986999)(81542001)(77096999)(36756003)(83716003)(33656001)(101416001)(79102001)(92726001)(62966002)(46406003)(46102001)(57306001)(74502001)(77156001)(76482001)(23726002)(86362001)(15975445006)(93916002)(74662001)(31966008)(102836001)(77982001)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2PR05MB066; H:BL2PRD0510HT004.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received-SPF: None (: juniper.net does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net;
X-OriginatorOrg: juniper.net
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/B4FWvZqKniy4E3SSqUHHjPbvVME
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:23:12 -0000

nobo,

assume that the advertising node only supports BFD4
and the receiving node does support only BFD6. - 
how to detect such a condition ?

/hannes


On May 14, 2014, at 6:15 PM, Nobo Akiya (nobo) wrote:

> 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
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg