Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-discriminator-00
"Nobo Akiya (nobo)" <nobo@cisco.com> Sun, 24 August 2014 12:51 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 EBCC11A895F for <isis-wg@ietfa.amsl.com>; Sun, 24 Aug 2014 05:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -115.169
X-Spam-Level:
X-Spam-Status: No, score=-115.169 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.668, 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 WDKJHIJcLj4v for <isis-wg@ietfa.amsl.com>; Sun, 24 Aug 2014 05:51:10 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38DF1A8952 for <isis-wg@ietf.org>; Sun, 24 Aug 2014 05:51:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6532; q=dns/txt; s=iport; t=1408884667; x=1410094267; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8ZzMViTvN/KPHbcagZLkjv6SNa1Zfy2HBcokbbIyA3c=; b=Tx+KAt0kwqRsEKsmj9KB3cgcRmrVvLd+aTyzw703C4vtdQHpBZ89ucCB ztA3bBrKGxBnqAx954defooU2mEKNVZHEbsbm/IYdoDtRPrW3KuK9xGq1 5Ac6heudB5Yegt7E3nxd7B6YW8S35kGzIFyTG7syG5FKKmVRZhjHHzefO Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAEff+VOtJA2H/2dsb2JhbABZgmojU1cEzDYKh00BgQgWd4QDAQEBAwEBAQE3NAsMBAIBCBEEAQELFAkHJwsUCQgCBAENBQiIMggBDMF+EwSPGzEHBoMpgR0FjxOCE6AvghiBRmyBSIEHAQEB
X-IronPort-AV: E=Sophos;i="5.04,390,1406592000"; d="scan'208";a="346769414"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 24 Aug 2014 12:51:04 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s7OCp3nX013040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 24 Aug 2014 12:51:03 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Sun, 24 Aug 2014 07:51:02 -0500
From: "Nobo Akiya (nobo)" <nobo@cisco.com>
To: Uma Chunduri <uma.chunduri@ericsson.com>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Christian Hopps <chopps@rawdofmt.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>
Thread-Topic: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-discriminator-00
Thread-Index: Ac+86HabHgHI9DprSRuZPZ9v+T9EbAACVwKgAAYh11AADQtlcAARBjGAAHoon/AAC23roA==
Date: Sun, 24 Aug 2014 12:51:02 +0000
Message-ID: <CECE764681BE964CBE1DFF78F3CDD3943A3B7344@xmb-aln-x01.cisco.com>
References: <1B502206DFA0C544B7A60469152008633F35A160@eusaamb105.ericsson.se> <F3ADE4747C9E124B89F0ED2180CC814F23EF80FF@xmb-aln-x02.cisco.com> <1B502206DFA0C544B7A60469152008633F35B2E7@eusaamb105.ericsson.se> <CECE764681BE964CBE1DFF78F3CDD3943A3B38DB@xmb-aln-x01.cisco.com> <F3ADE4747C9E124B89F0ED2180CC814F23EF947C@xmb-aln-x02.cisco.com> <1B502206DFA0C544B7A60469152008633F35DD39@eusaamb105.ericsson.se>
In-Reply-To: <1B502206DFA0C544B7A60469152008633F35DD39@eusaamb105.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.240.212]
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/cj2qZG2Q6uzjn73abUCWAnB0LhE
Cc: Hannes Gredler <hannes@juniper.net>
Subject: Re: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd-discriminator-00
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: Sun, 24 Aug 2014 12:51:12 -0000
Hi Uma, > -----Original Message----- > From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] > Sent: Sunday, August 24, 2014 3:27 AM > To: Les Ginsberg (ginsberg); Nobo Akiya (nobo); Christian Hopps; isis- > wg@ietf.org list > Cc: Hannes Gredler > Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd- > discriminator-00 > > Dear Nobo, > > > [NOBO] This is a very good comment Uma. My response would be > that > > there's nothing in S-BFD documents that prevents tying of local S- > BFD > > discriminator to set of incoming interfaces. i.e. a local S-BFD > > discriminator for an MT can programmed to process S-BFD packets > coming > > in only from set of interfaces which belong in the MT. If such strict > > checks are desired, implementations are free to do so. > > I am not talking about the S-BFD packet, rather the S-BFD discriminator > received at an MT interface/MT node. > The received one might be associated for only one or set of MTs by the > sender. IMO, (in one way) this could be represented only when an MT-ID > (5120) is associated with the discriminator. Ok I see what you are saying. I agree with Les that we do not want to use discriminator to classify the MT ID, rather use something in the lower layer to achieve that. Thanks! -Nobo > > > Dear Les, > > > The MT question has nothing to do w S-BFD - it is a generic issue for > any type of BFD multi-hop session. > > If you have multiple topologies for a given address family and you > would like the BFD packets to traverse > > a specific topology then you have to "mark" BFD packets in the > same way that data packets are marked for > > a given topology. > > As I clarified above my question was about association of discriminator to > MT ID... > If you think it's not necessary I have no issues! > > -- > Uma C. > > > -----Original Message----- > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Thursday, August 21, 2014 2:03 PM > To: Nobo Akiya (nobo); Uma Chunduri; Christian Hopps; isis-wg@ietf.org list > Cc: Hannes Gredler > Subject: RE: [Isis-wg] Proposed isis-wg documents - draft-ginsberg-isis-sbfd- > discriminator-00 > > Uma/Nobo - > > The MT question has nothing to do w S-BFD - it is a generic issue for any type > of BFD multi-hop session. If you have multiple topologies for a given > address family and you would like the BFD packets to traverse a specific > topology then you have to "mark" BFD packets in the same way that data > packets are marked for a given topology. Then the packets will be > processed at each hop along the way based on topology specific forwarding. > What this marking is has nothing to do with BFD - and it certainly would NOT > be a BFD discriminator as this would be specific to BFD packets only - which > is not at all what you want. > > Les > > > > -----Original Message----- > > From: Nobo Akiya (nobo) > > Sent: Thursday, August 21, 2014 6:05 AM > > To: Uma Chunduri; Les Ginsberg (ginsberg); Christian Hopps; isis- > > wg@ietf.org list > > Cc: Hannes Gredler > > Subject: RE: [Isis-wg] Proposed isis-wg documents - > > draft-ginsberg-isis-sbfd- > > discriminator-00 > > > > Hi Uma, Les, > > > > Pardon me for jumping in. > > Please see [NOBO] in-line. > > > > > -----Original Message----- > > > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Uma > > > Chunduri > > > Sent: Thursday, August 21, 2014 3:00 AM > > > To: Les Ginsberg (ginsberg); Christian Hopps; isis-wg@ietf.org list > > > Cc: Hannes Gredler > > > Subject: Re: [Isis-wg] Proposed isis-wg documents - > > > draft-ginsberg-isis- > > sbfd- > > > discriminator-00 > > > > > > Les, > > > > > > In-line [Uma1]: > > > > > > === > > > > Support this. > > > > > > > > Qs: > > > > > > > > 1. What happened to the discussion on- if this discriminator is a > > > > link property or node property as defined (asked originally in > > > > OSPF WG by Hannes). > > > > > > The question was answered - discriminators are a node property. > > > > > > [Uma1]: I saw SR use cases for SBFD and with ADJ-SID's (link > > > specific) this can be a problem. > > > > [NOBO] Couple of comments. > > 1. S-BFD document for Segment Routing is very stale. Authors should be > > able to roll out a revised and updated document this weekend. > > 2. S-BFD authors wanted to build in some connectivity test aspect into > > the S- BFD mechanism, particularly to allow verifying where Adj-SID > > terminates on the nextshop. However, there were strong push backs from > > the BFD WG regarding usage of BFD or S-BFD for connectivity test. > > Thus, S-BFD focuses only on continuity check, which is a node reachability > check. > > > > > > > > > 2. If MTs are on the same physical topology, I don't see the > > > > association of Discriminator to the logical topology/MT. Is it > > > > already though and discounted ? If yes rationale will be helpful. > > > > > > Just as IP/IPv6 addresses are NOT topology specific, S-BFD > > > discriminators > > are > > > NOT topology specific. The paths to reach a node may differ between > > > topologies - but that is not a property of the discriminator. > > > > > > [Uma1]: A node may be part of any logical topology (MT) or may not be. > > > But, if the discriminator doesn't represent the same then the > > > receiving > > node > > > (participating in multiple logical topologies) has no idea for > > > which topo > > the > > > same has been received or In other words sending node may not be > > > part > > of > > > the particular logical topo. > > > > > > Do you see this as an issue? > > > > [NOBO] This is a very good comment Uma. My response would be that > > there's nothing in S-BFD documents that prevents tying of local S-BFD > > discriminator to set of incoming interfaces. i.e. a local S-BFD > > discriminator for an MT can programmed to process S-BFD packets coming > > in only from set of interfaces which belong in the MT. If such strict > > checks are desired, implementations are free to do so. > > > > Thanks! > > > > -Nobo > > > > > > > > -- > > > Uma C. > > > > > > _______________________________________________ > > > Isis-wg mailing list > > > Isis-wg@ietf.org > > > https://www.ietf.org/mailman/listinfo/isis-wg
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Uma Chunduri
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Uma Chunduri
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Nobo Akiya (nobo)
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Les Ginsberg (ginsberg)
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Uma Chunduri
- Re: [Isis-wg] Proposed isis-wg documents - draft-… Nobo Akiya (nobo)