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

"Nobo Akiya (nobo)" <nobo@cisco.com> Wed, 14 May 2014 17:02 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 227781A02B2; Wed, 14 May 2014 10:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.152
X-Spam-Level:
X-Spam-Status: No, score=-110.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YtnhcY5xwVAc; Wed, 14 May 2014 10:02:22 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id B74721A029F; Wed, 14 May 2014 10:02:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3834; q=dns/txt; s=iport; t=1400086935; x=1401296535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=48bLEeyNl0uqxbA8H1moYbOcufzP59CkBFvkk7lOqYw=; b=K5qysW/9lc2XAufDbticqz22n97Gq4ZD2N530+JhhzPlJc2lu5WU+irJ vntJDoQEdl0z/rekSpZTrwuZbSLYD7UyFoMs+kEZOZeaFJef9CrUKh0Ve pYv60WrZcUqef4anSyxMKqtuQWHRjgVIwYVZvRyhJSpGr+8PuAhgcegAx I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhkFACygc1OtJV2Q/2dsb2JhbABZgmUhT1i+NIc7AYEjFnSCJQEBAQMBAQEBNzQJAgUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQiIMQgBDNEdEwSOHTEHBoMlgRUBA6xlgXeBP4Iw
X-IronPort-AV: E=Sophos;i="4.97,1053,1389744000"; d="scan'208";a="43809975"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 14 May 2014 17:02:11 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s4EH2BEN031325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 May 2014 17:02:11 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Wed, 14 May 2014 12:02:11 -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//+vVVCAAFe9gP//sQWw
Date: Wed, 14 May 2014 17:02:10 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3941E14EE6A@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> <CECE764681BE964CBE1DFF78F3CDD3941E14EDA1@xmb-aln-x01.cisco.com> <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@juniper.net>
In-Reply-To: <7F0CA0C7-CFD2-4B51-BA0A-A7F167B05B42@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/GsTeenZpVmMRal1ClEqs7mXTs_0
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 17:02:24 -0000

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