Re: [Isis-wg] New Version/Proposed isis-wg documents draft-ginsberg-isis-sbfd-discriminator-00.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 26 August 2014 23:52 UTC

Return-Path: <ginsberg@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 CE94A1A0201; Tue, 26 Aug 2014 16:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
X-Spam-Status: No, score=-15.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] 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 ll2CL_7WgOdU; Tue, 26 Aug 2014 16:52:07 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D8E1A01F7; Tue, 26 Aug 2014 16:52:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8800; q=dns/txt; s=iport; t=1409097129; x=1410306729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=iNl5m/Ms6sTAU1pJAI/z1w3EjKDJ46lqvPfAfiQfbtY=; b=lWaP5wsEwsno/TebALIGSl5I9HwWIpQAeAuqLO7QduSIBzTan5c1oXUX od3G93GkfoUWCSGm4H/PGNvPd6Jlo0ELKnsyuMgYJtmbm3kbd4NT5BUSw kO8wiwkPS7SFD2+QYRPf5UECu343nkG5bkADH5vBr/m6Q+ya96MaJQb4q Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisFAEkc/VOtJV2T/2dsb2JhbABbgmojU1cEzFAKh0wBgRIWd4QDAQEBBAEBATc0CwwEAgEIEQQBAQEKFAkHJwsUCQgCBAENBQgTiCcBDL9QEwSPGzEHBoMpgR0BBIYTixqgO4IYgUZsgUiBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208";a="72656089"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 26 Aug 2014 23:52:08 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7QNq6vN005958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Aug 2014 23:52:06 GMT
Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 18:52:06 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Marc Binderberger <marc@sniff.de>, "Nobo Akiya (nobo)" <nobo@cisco.com>, Uma Chunduri <uma.chunduri@ericsson.com>, Gregory Mirsky <gregory.mirsky@ericsson.com>, Mach Chen <mach.chen@huawei.com>, "Hannes Gredler" <hannes@juniper.net>, Jeffrey Haas <jhaas@pfrc.org>
Thread-Topic: [Isis-wg] New Version/Proposed isis-wg documents draft-ginsberg-isis-sbfd-discriminator-00.txt
Thread-Index: AQHPwW4N06XhmNogNE2vZUS6BLomNJvjaXTw
Date: Tue, 26 Aug 2014 23:52:05 +0000
Message-ID: <F3ADE4747C9E124B89F0ED2180CC814F23EFDC6E@xmb-aln-x02.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> <CECE764681BE964CBE1DFF78F3CDD3941E14EE6A@xmb-aln-x01.cisco.com> <F73A3CB31E8BE34FA1BBE3C8F0CB2AE25D9C4A26@SZXEMA510-MBX.china.huawei.com> <CECE764681BE964CBE1DFF78F3CDD3941E150962@xmb-aln-x01.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7BFAA3@eusaamb103.ericsson.se> <CECE764681BE964CBE1DFF78F3CDD3941E157C55@xmb-aln-x01.cisco.com> <7347100B5761DC41A166AC17F22DF1121B7C011B@eusaamb103.ericsson.se> <CECE764681BE964CBE1DFF78F3CDD3941E157C7F@xmb-aln-x01.cisco.com> <20140826134100782350.a68cbcf3@sniff.de>
In-Reply-To: <20140826134100782350.a68cbcf3@sniff.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [128.107.163.140]
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/BdE9OEQzgPMvV32sjn7-9L25KLA
Cc: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] New Version/Proposed isis-wg documents 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: Tue, 26 Aug 2014 23:52:09 -0000

Marc -

No apologies necessary - the draft is still V0 and not yet a WG item. Your comments are welcome and still timely.

That said, we made a conscious decision in both the IS-IS and OSPF drafts to stay out of the "application context"  space. Despite rumors to the contrary, the IGPs are NOT a distribution mechanism for application information. Their primary purpose is to advertise information necessary for the operation of the routing protocol. It is in fact arguable that we are "crossing the line" by advertising S-BFD Discriminators at all - however the fact that IGPs are a likely S-BFD client as well as the convenience of using the IGPs makes this compromise seem justifiable. 

RFC 6823 (GENINFO) is the defined way to advertise application information using IS-IS. If BFD WG is serious about advertising application context along with the S-BFD Discriminators then this would be the way forward. That brings with it a significant amount of additional specification - so such a decision needs to be well considered.

   Les


> -----Original Message-----
> From: Marc Binderberger [mailto:marc@sniff.de]
> Sent: Tuesday, August 26, 2014 1:41 PM
> To: Nobo Akiya (nobo); Uma Chunduri; Gregory Mirsky; Mach Chen; Hannes
> Gredler; Les Ginsberg (ginsberg); Jeffrey Haas
> Cc: rtg-bfd@ietf.org; isis-wg@ietf.org
> Subject: Re: [Isis-wg] New Version/Proposed isis-wg documents draft-
> ginsberg-isis-sbfd-discriminator-00.txt
> 
> Hello everyone,
> 
> think I missed some discussions as they showed as "ISIS" WG. So my apology
> for bringing this up again but ...
> 
> looking at draft-ginsberg-isis-sbfd-discriminator-00 there is this part in
> the document:
> 
> 
>    Inclusion of the S-BFD Discriminators sub-TLV in a Router Capability
>    TLV is optional.  Multiple S-BFD Discriminators sub-TLVs MAY be
>    advertised by an IS.  When multiple S-BFD discriminators are
>    advertised how a given discriminator is mapped to a specific use case
>    is out of scope for this document.
> 
> 
> There is something right about it, at the same time something is missing,
> IMHO.
> 
> How BFD is using the discriminator value(s) is likely something the IS-IS
> protocol does not want to know; it would create interdependencies and
> complexity.
> 
> On the other hand the solution does not provide enough context for each
> discriminator. For a single discriminator - fine, no choice anyway. But
> transporting multiple discriminators without context seems "useless" to
> me.
> 
> I would have expected a slightly different layout:
> 
>                                                   No. of octets
>                  +-----------------------------+
>                  | Type (to be assigned by     |     1
>                  | IANA)  |
>                  +-----------------------------+
>                  | Length (multiple of 8)      |     1
>                  +-----------------------------+
>                  | Discriminator Value         |     4 per Discriminator
>                  | Context Value               |     4 (?) per Context
>                  : (potentially more pairs of  :
>                  :  Discriminator/Context)     :
>                  +-----------------------------+
> 
> 
> How many bits per Context value can be discussed; I used 32bit due to lack
> of
> fantasy ;-)  What a "context value" is/means doesn't matter to IS-IS, it just
> transports it. But the IS-IS clients - be it BFD or BFD clients - can use it.
> 
> We don't even need to discuss the details of a Context Value within the BFD
> WG for now but not having any value for administrative purposes seems
> "jumping short" to me (think communities in BGP, route tags in certain RIB
> implementations etc.)
> 
> 
> Again, sorry for commenting with a delay of "only" a few month :-)
> 
> 
> Regards, Marc
> 
> 
> 
> 
> 
> 
> On Wed, 21 May 2014 01:24:37 +0000, Nobo Akiya (nobo) wrote:
> > Thanks for prompt response Greg.
> >
> > Will incorporate the text in draft-ietf-...-01.
> >
> > -Nobo
> >
> >> -----Original Message-----
> >> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> >> Sent: Tuesday, May 20, 2014 9:22 PM
> >> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler
> >> Cc: 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 Nobo,
> >> I like it.
> >>
> >> 	Regards,
> >> 		Greg
> >>
> >> -----Original Message-----
> >> From: Nobo Akiya (nobo) [mailto:nobo@cisco.com]
> >> Sent: Tuesday, May 20, 2014 6:18 PM
> >> To: Gregory Mirsky; Mach Chen; Hannes Gredler
> >> Cc: 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 Greg,
> >>
> >> That's true, the whole paragraph in the section 7 of S-BFD base document
> is
> >> just describing some possible implementation techniques. How about
> we
> >> change the paragraph:
> >>
> >> [old]
> >>    Note that incoming BFD control packets destined to BFD target
> >>    identifier types may be IPv4, IPv6 or MPLS based.  For those BFD
> >>    target identifier types, implementations MAY either allow the same
> >>    reflector BFD session to handle all incoming BFD control packets in
> >>    address family agnostic fashion, or setup multiple reflector BFD
> >>    sessions to handle incoming BFD control packets with different
> >>    address families.  This policy is again a local matter, and is
> >>    outside the scope of this document.
> >>
> >> [new]
> >>    Note that incoming BFD control packets destined to BFD target
> >>    identifier types may be IPv4, IPv6 or MPLS based.  How such packets
> >>    reach an appropriate reflector BFD session is a local matter, and is
> >>    outside the scope of this document.
> >>
> >> -Nobo
> >>
> >>> -----Original Message-----
> >>> From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com]
> >>> Sent: Tuesday, May 20, 2014 6:46 PM
> >>> To: Nobo Akiya (nobo); Mach Chen; Hannes Gredler
> >>> Cc: 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
> >>>
> >>> Dear All,
> >>> according to Section 7 of the S-BFD Base document differentiation
> >>> among address families by S-BFD is optional and mention in connection
> >>> to separate S-BFD reflectors to act as per-AF reflectors. Perhaps I've
> >>> missed that part of S-BFD Base discussion but I don't see the benefit of
> >> supporting such mode.
> >>> BFD control packets been AF-agnostic since RFC 5880 and I think that
> >>> S-BFD should maintain that approach.
> >>>
> >>> I agree with Mach that discriminators in S-BFD, as well as in BFD, are
> >>> and must remain AF blind.
> >>>
> >>> 	Regards,
> >>> 		Greg
> >>>
> >>> -----Original Message-----
> >>> From: Rtg-bfd [mailto:rtg-bfd-bounces@ietf.org] On Behalf Of Nobo
> >>> Akiya
> >>> (nobo)
> >>> Sent: Thursday, May 15, 2014 7:07 AM
> >>> To: Mach Chen; Hannes Gredler
> >>> Cc: 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 Mach, Hannes, et al,
> >>>
> >>>> 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.
> >>>
> >>> I agree Mach, mostly :)
> >>>
> >>> I can also see one arguing that forwarding supporting X does not
> >>> always mean S-BFD is supported on X. If we want to address this, then
> >>> it is an S-BFD specific issue, and we _may_ want to solve this via
> >>> introducing S-BFD capability advertisements.
> >>>
> >>> With that said, S-BFD discriminator advertisement is one area which
> >>> the capability problem can be solved, but not necessary a problem that
> >>> has to be solved with S-BFD discriminator advertisement. Rather I
> >>> don't think the two should be bundled together.
> >>>
> >>> Let us continue the capability discussion separate from the
> >>> discriminator advertisements?
> >>>
> >>> -Nobo
> >>>
> >
> > _______________________________________________
> > Isis-wg mailing list
> > Isis-wg@ietf.org
> > https://www.ietf.org/mailman/listinfo/isis-wg
> >