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

Mach Chen <mach.chen@huawei.com> Thu, 15 May 2014 09:21 UTC

Return-Path: <mach.chen@huawei.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 821171A0442; Thu, 15 May 2014 02:21:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 nDaMPbx3eLsT; Thu, 15 May 2014 02:21:46 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8F51A0441; Thu, 15 May 2014 02:21:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEE29839; Thu, 15 May 2014 09:21:37 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 10:20:38 +0100
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 15 May 2014 10:21:15 +0100
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.13]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Thu, 15 May 2014 17:21:09 +0800
From: Mach Chen <mach.chen@huawei.com>
To: "Nobo Akiya (nobo)" <nobo@cisco.com>, Hannes Gredler <hannes@juniper.net>
Thread-Topic: [Isis-wg] New Version Notification for draft-ginsberg-isis-sbfd-discriminator-00.txt
Thread-Index: AQHPasxAEriQ17fwwkKZMW0VvzcsSJs2PY8AgAliegCAABUCAIAAARwAgAACvoCAAAM2AIAAAqaAgAAFDICAAAIGgIAACvUAgAGVQEA=
Date: Thu, 15 May 2014 09:21:08 +0000
Message-ID: <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9C4A26@SZXEMA510-MBX.china.huawei.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> <CECE764681BE964CBE1DFF78F3CDD3941E14EDA1@xmb-aln-x01.cisco.com> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net> <CECE764681BE964CBE1DFF78F3CDD3941E14EE6A@xmb-aln-x01.cisco.com>
In-Reply-To: <CECE764681BE964CBE1DFF78F3CDD3941E14EE6A@xmb-aln-x01.cisco.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.97.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/AYqmszC3CwvFvLCTJ5krsoLyvWs
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: Thu, 15 May 2014 09:21:48 -0000

Hi Nobo and Hannes,

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. 

Best regards,
Mach

> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Nobo Akiya (nobo)
> Sent: Thursday, May 15, 2014 1:02 AM
> To: Hannes Gredler
> 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
> 
> Hi Hannes,
> 
> > assume that the advertising node only supports BFD4 and the receiving
> > node does support only BFD6. - how to detect such a condition ?
> 
> Ah I see. You are talking about S-BFD capability.
> 
> i.e.
> 
> IPv4
> IPv6
> MPLSv4
> MPLSv6
> SR-MPLS
> SR-IPv6
> Etc
> 
> One doesn't necessary have to solve this via assigning and advertising different
> discriminator per "feature" .. you would then have to advertise what "feature"
> each discriminator is for, with IANA maintained "feature" value.
> 
> Other approach is for a node to advertise the capability separate from
> discriminator value. You would also need IANA maintained "feature" value for
> this.
> 
> Another approach is to not define/advertise the S-BFD capabilities, but rely on
> operators to provision S-BFD for only those "features" which are known to be
> supported by relevant network nodes.
> 
> In summary, S-BFD capability might be something needed, but that doesn't
> necessary have to be tied to discriminator advertisement.
> 
> Those are some possibilities that I can think of. Do you have any thoughts around
> this?
> 
> - Nobo
> 
> >
> > /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
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg