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