Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Wed, 31 May 2017 23:21 UTC
Return-Path: <ginsberg@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834E612944E for <isis-wg@ietfa.amsl.com>; Wed, 31 May 2017 16:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 QI4i-CJV3K58 for <isis-wg@ietfa.amsl.com>; Wed, 31 May 2017 16:21:09 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37532126CD8 for <isis-wg@ietf.org>; Wed, 31 May 2017 16:21:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=117564; q=dns/txt; s=iport; t=1496272869; x=1497482469; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FUgXB+uWpUc6gWcsc2W652xWH/Ve8fFA67hUMzOB3vI=; b=bi0Srhab4YkMJK6fds2hO5Y5Xe7RTql8GMp5asbmVL50QE9L9jPl5otF 7TWJiubb5dqL7uOvalSrBZ/MvkFjL6dM946OcD+ViwAbPViH3JQRZ8wWB dzRXHCK38BVMLlUbo4G7zXdVxRHhNGeEi5+zoFPoTqMwf8drjllzWAvmp M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYAACWTi9Z/51dJa1TChkBAQEBAQEBAQEBAQcBAQEBAYJuPCtigQ0HjgSRcpV5gg8sgh0Bg1oCgm0/GAECAQEBAQEBAWsohRgBAQEBAxoBElwCAQgRBAEBFgsBBgcyFAkIAQEEARIIE4krZBCuR4tQAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGYYFfAYITgQyEOQhOEAmFMwWJR3GFcYZQhyoBhx+DNYhKkgCUTQEfOIEKdBVGhQMcGYFKdohGgQ0BAQE
X-IronPort-AV: E=Sophos;i="5.39,276,1493683200"; d="scan'208,217";a="252093187"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 May 2017 23:21:05 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v4VNL5mR009685 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 May 2017 23:21:05 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 May 2017 18:21:04 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 31 May 2017 18:21:04 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Uma Chunduri <uma.chunduri@huawei.com>, Chris Bowers <cbowers@juniper.net>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Thread-Topic: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
Thread-Index: AdLLRtm+ZNz9pbnGTU+TnDWIYIoHggCiCx3QAyKCkkAAAhKisA==
Date: Wed, 31 May 2017 23:21:04 +0000
Message-ID: <6d001426688b431680e1d840fb04f173@XCH-ALN-001.cisco.com>
References: <MWHPR05MB28293E73A559496455BA7BBAA9E20@MWHPR05MB2829.namprd05.prod.outlook.com> <3547a236e630428291fccc45a0add058@XCH-ALN-001.cisco.com> <25B4902B1192E84696414485F5726854018BC396@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <25B4902B1192E84696414485F5726854018BC396@SJCEML701-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.85.4]
Content-Type: multipart/alternative; boundary="_000_6d001426688b431680e1d840fb04f173XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/6wjkortrTjquis_elbUBS8oso-4>
Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 31 May 2017 23:21:12 -0000
Uma - From: Uma Chunduri [mailto:uma.chunduri@huawei.com] Sent: Wednesday, May 31, 2017 3:00 PM To: Les Ginsberg (ginsberg); Chris Bowers; isis-wg@ietf.org Subject: RE: draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00 Looked at both proposals and here are my specific comments: - Perhaps without any application identifier/bit the value can be used for all applications. But specifying and ID can restrict to that particular application. With this, I don't see an explosion of identifiers per application as suggested below. [Les:] No one - certainly not me - is predicting an "explosion" of applications. That isn't the point I am trying to make. If we support 3 applications - say SR-TE, LFA, and one User defined App(UDA). On any interface I could have a need to advertise a link attribute with any of the following scopes: 1)SR-TE only 2)LFA only 3)UDA only 4)SR-TE and LFA 5)SR-TE and UDA 6)LFA and UDA 7)SR-TE and LFA and UDA If a bit is assigned to each application (IANA registry or runtime definition), only three bit definitions are needed in order to support all of the above cases. If a scalar is assigned to represent each combination, then 7 scalars have to be defined. In order for advertisements to be interpreted consistently by every node these definitions have to be assigned consistently on every node in the network. If we add support for another UDA then the list above expands to 15 entries ((2**N)-1) for scalars - but only one additional bit need be defined when using a bit mask. - One drawback I see with application identifiers - these would be specific to a domain/AS. If these values have to be used by a controller for mapping different application identifier in one domain to corresponding application identifier in another domain would be difficult. In that sense IANA define application bit mask might fit well. [Les:] I agree with this point. - On the new TLV (TLV 238) proposed in https://tools.ietf.org/html/draft-ginsberg-isis-te-app-00 o Not sure why SRLG need to be a separate TLV to start with as done in RFC 5307 for IPv4 and RFC 6119 for IPv6. This indeed, created lot of grief during BGP-LS time too from both specification and implementation PoV. If this need to be fixed these should be brought under T LVs 22, 23, 141, 222, and 223 not a 'new' separate TLV. o Hence, strongly disagree to clean-up this SRLG mess with yet another high level TLV [Les:] I understand your concern. However, we have existing formats. What we have deliberately done with the extensions is to make sure we do NOT change existing formats for attribute advertisements - we only "encapsulate" with the "application bit mask". This should allow a significant amount of existing TLV parsing code to be reused. In the case of SRLG if we followed that model precisely we would have had to define two new top level TLVs - one for IPv4/unnumbered and one for IPv6. We wanted to be more frugal in consuming TLV code points so we elected to make the new TLV format flexible enough to accommodate IPv4/IPv6, and unnumbered. Your proposal is more "ambitious", but I am not sure the benefits are significant enough. There are downsides to advertising SRLG in IS-neighbor TLVs. AS a link may well have multiple SRLG values it could significantly bloat the TLV space used, forcing multiple TLVs for the same neighbor - which would defeat the purpose. And it is harder for an implementation to determine whether a topology change is signaled by the revised IS-neighbor advertisement - so unnecessary SPFs might be triggered as a result. NOTE: One could make the same argument for link attribute advertisements -that a separate TLV might have been a better solution - but that ship sailed many years ago. Les -- Uma C. From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg) Sent: Monday, May 15, 2017 4:52 PM To: Chris Bowers <cbowers@juniper.net<mailto:cbowers@juniper.net>>; isis-wg@ietf.org<mailto:isis-wg@ietf.org> Subject: Re: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00 Chris - Thanx for the detailed write up regarding your proposed encoding for advertising link attribute information for multiple applications. My primary takeaway is that we are now in agreement regarding the need to support application specific advertisement of link attribute information. This is the major difference between the proposals in draft-ginsberg-isis-te-app/ppsenak-ospf-te-link-attr-reuse vs hegde-isis-advertising-te-protocols/hegde-ospf-advertising-te-protocols This means we have resolved the stalemate and that the respective WGs should now be able to begin work on the proposals based on the ginsberg/ppsenak drafts. This is a major step forward and I think achieves the task you and I were assigned in Chicago WG meetings. The remainder of my comments are specific to your encoding proposals - but it is worth emphasizing that we are no longer debating the requirements - we are simply discussing alternative encodings. Regarding Attribute Set Identifier ---------------------------------- Your proposal is to define dynamically - via configuration on every router - a numeric identifier which represents a set of applications. Each identifier is associated with one or more applications - and that identifier is then advertised with a set of link specific attribute sub-sub-TLVs. As this is based on configuration, for correct operation the operator MUST configure consistent numeric value/application set mappings on EVERY router. To cover all possible combinations the operator would have to configure up to (2**N)-1 identifiers where N is the number of applications supported. 3 applications: up to 7 identifiers 4 applications: up to 15 identifiers 5 applications: up to 31 identifiers And the correct identifier(s) have to be associated with the appropriate sets of attributes on every link on each router. This seems both onerous and error prone. The stated benefit of this vs the IANA assigned bit mappings proposed by the ginsberg/ppsenak drafts is that a new application could be introduced without requiring a bit assignment by IANA. If we look at the existing applications (RSVP-TE, SR-TE, LFA) we note that all of these applications required IETF drafts be written to define interoperable behavior. I would expect the same would be required of any new application. Given that a draft is required, the inclusion of an IANA request for an application bit identifier in such a draft is trivial. By doing so we avoid the additional configuration and its risks of inconsistency. If the intent is to allow introduction of a proprietary or experimental application in a network prior to developing any standards I think there is a much easier way to support that. draft-ginsberg-isis-te-app currently defines: Bit Mask Length: Non-zero (1 octet) Application Bit Mask: Size is (Bit Mask Length+7)/8 The following bits are assigned: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |L|R|S|F| | +-+-+-+-+-+-+-+-+ L-bit: Applications listed MUST use the legacy advertisements for the corresponding link found in TLVs 22, 23, 141, 222, and 223 or TLV 138 or TLV 139 as appropriate. R-bit: RSVP-TE S-bit: Segment Routing Traffic Engineering F-bit: Loop Free Alternate We could reserve some bits (I think two would be enough) for non-standards use. For example 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |L|R|S|F| |P|X| +-+-+-+-+-+-+-+-+ P-Bit: Reserved for proprietary application X-bit: Reserved for experimental (pre-standard) application Regarding your proposal for: Traffic-engineering Protocol sub-TLV ------------------------------------------------------------------- I think what you are trying to address here are the backwards compatibility concerns. Today, because we lack the ability to advertise application specific attributes, implementations have been forced to overload the use of the legacy advertisements even though such advertisements were never intended to be used in this way. One of the issues which the ginsberg/ppsenak drafts are addressing is the inappropriate use of legacy advertisements. While we do recognize that until we have full deployment of the extensions we need to support backwards compatibility with the existing overloaded use of legacy advertisements, we do NOT want to standardize this behavior. draft-ginsberg-isis-te-app provides backwards compatibility by using the L-bit as described above. With partial deployment we then (using the example of SR-TE) advertise an application bit mask with L and S bits set. This indicates that SR-TE application is using the legacy advertisements. Even after full deployment of the extensions this can be used to avoid unnecessary duplication when SR-TE and RSVP-TE share the same attributes on a given link. However, because you are proposing to use a numeric identifier, you have no way to indicate when SR-TE (for example) should use legacy advertisements. In order to do so you have to introduce another sub-TLV which uses the equivalent of the bit mask which the ginsberg/ppsenak drafts already utilize. And, since IANA allocations for the bits in this sub-TLV are still required, you have not actually eliminated the need for IANA bit allocations - which is one of the goals of your proposed dynamically assigned identifiers. For the proposals defined in the ginsberg/ppsenak drafts this information has already been conveyed via the bit mask advertised as part of the link attribute advertisements - so there is no need for this additional advertisement. Also note that the concept of "application enabled on a link" is not what is required. What is required is to identify what sets of applications can use a set of link attribute advertisements - which is completely captured by the new application specific link attribute advertisements defined in the ginsberg/ppsenak drafts. There is no need for this additional sub-TLV. Les From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris Bowers Sent: Friday, May 12, 2017 10:47 AM To: isis-wg@ietf.org<mailto:isis-wg@ietf.org> Subject: [Isis-wg] draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00 ISIS-WG, As I said at the microphone at the WG meeting in Chicago, I think there may be some common ground that can address the general goals of both draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00. The text below describes proposed encodings that I think reflect potential common ground. The main idea is to decouple the advertisement of what protocols are enabled on a link and the advertisement of different sets of attributes on a link, and then allow applications to choose how to use that information as they see fit. This takes into account input from networks operators regarding the desire for a flexible mapping between attribute sets and the applications that use them. I look forward to feedback from the WG on these proposed encodings. The text below borrows liberally from the existing text in draft-hegde-isis-advertising-te-protocols-02 and draft-ginsberg-isis-te-app-00 with some important differences. Chris ====== Attribute Set Identifier The new Attribute Set Identifier is a 32-bit value that identifies a set of attributes. All of the attributes advertised with a given value of the Attribute Set Identifier are considered to be part of the attribute set. This allows different applications to use different attribute sets, if desired. The Attribute Set Identifier with a value of zero is special. Existing encodings for advertising attributes that do not explicitly support the inclusion of the Attribute Set Identifier are now understood to implicitly advertise attributes with the Attribute Set Identifier set to zero. In this framework, existing implementations using the existing encodings already support the advertisement of attributes with the Attribute Set Identifier = 0. In order to ensure a consistent view of the attribute set scoped attributes, for encodings that explicitly support the Attribute Set Identifier, advertising an attribute with Attribute Set Identifier set to zero is not allowed. >From a standardization perspective, there is not intended to be any fixed mapping between a given Attribute Set Identifier and a given application. A network operator wishing to advertise different attribute sets could configure the network equipment to advertise attributes with different values of the Attribute Set Identifier based on their objectives. The different applications (be they controller-based applications or distributed applications) would make use of the different attribute sets based on convention within that network. As an example, a network operator might choose to advertise four different attribute sets, in support of five different applications with the following mapping. Application Attribute Set Identifier =========================== ======================== Distributed RSVP-based 0 (implicit) auto-bandwidth Centralized SR-based TE 0 (implicit) Distributed SR-based FRR 100 Centralized RSVP-based 200 diverse low-latency paths Potential new application 300 that uses both SR and RSVP to build LSPs Below are descriptions of proposed encodings that allow attributes to be advertised with non-zero values of the Attribute Set Identifier. The Traffic-engineering Protocol sub-TLV is described as well, since it is needed to indicate what protocols are enabled on a link. ====== Link Attribute Set sub-TLV The Link Attribute Set sub-TLV is a new sub-TLV for TLVs 22, 23, 141, 222, and 223. It allows different sets of link attributes to be advertised for the same link. This allows different applications to use different sets of attributes. Type: to be assigned by IANA (suggested value 101 ) Length: Variable (1 octet) Value: Attribute Set Identifier - a 32-bit value containing the non-zero Attribute Set Identifier that identifies a set of attributes. The Link Attribute Set sub-TLV MUST be ignored if the Attribute Set Identifier is zero. This ensures a consistent view of the attribute set scoped link attributes, where the Link Attribute sub-TLVs advertised directly in TLV#22 are now understood to be implicitly advertised with the Attribute Set Identifier equal to zero. Link Attribute sub-sub-TLVs - the format of these Link Attribute sub-sub-TLVs matches the existing formats for the Link Attribute sub-TLVs defined in [RFC5305] and [RFC7810]. Each Link Attribute sub-sub-TLV advertised in a given Link Attribute Set sub-TLV is associated with the Attribute Set Identifier in the Link Attribute Set sub-TLV. ======= Attribute Set Scoped SRLG TLV A new TLV is defined to allow SRLGs to be advertised for a given link and associated with a specific attribute set identifier. Although similar in functionality to TLV 138 (defined by [RFC5307]) and TLV 139 (defined by [RFC6119] a single TLV provides support for IPv4, IPv6, and unnumbered identifiers for a link. Unlike TLVs 138/139 it utilizes sub-TLVs to encode the link identifiers in order to provide the flexible formatting required to support multiple link identifier types. Type: to be assigned by IANA (suggested value 238) Length: Number of octets in the value field (1 octet) Value: Neighbor System-ID + pseudo-node ID (7 octets) Attribute Set Identifier - a 32-bit value containing the non-zero Attribute Set Identifier that identifies a set of attributes. The Attribute Set Scoped SRLG TLV MUST be ignored if the Attribute Set Identifier is zero. This ensures a consistent view of the attribute set scoped link attributes, where the SRLGs advertised directly in TLV#138 and TLV#139 are now understood to be implicitly advertised with the Attribute Set Identifier equal to zero. Length of sub-TLVs (1 octet) Link Identifier sub-TLVs (variable) 0 or more SRLG Values (Each value is 4 octets) The following Link Identifier sub-TLVs are defined. The type values are suggested and will be assigned by IANA - but as the formats are identical to existing sub-TLVs defined for TLVs 22, 23, 141, 222, and 223 the use of the suggested sub-TLV types is strongly encouraged. Type Description 4 Link Local/Remote Identifiers (see [RFC5307]) 6 IPv4 interface address (see [RFC5305]) 8 IPv4 neighbor address (see [RFC5305]) 12 IPv6 Interface Address (see [RFC6119]) 13 IPv6 Neighbor Address (see [RFC6119]) At least one set of link identifiers (IPv4, IPv6, or unnumbered) MUST be present. TLVs which do not meet this requirement MUST be ignored. Multiple TLVs for the same link MAY be advertised. ======= Traffic-engineering Protocol sub-TLV A new Traffic-engineering protocol sub-TLV is a new sub-TLV for TLVs 22, 23, 141, 222, and 223. The sub-TLV indicates the protocols enabled on the link. The sub-TLV has flags in the value field to indicate the protocol enabled on the link. The length field is variable to allow the flags field to grow for future requirements. Type : to be assigned by IANA (suggested value 102) Length: Variable (1 octet) Value: The value field consists of bits indicating the protocols enabled on the link. This document defines the two protocol values below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +----------+-------------------------------+ | Value | Protocol Name | +----------+-------------------------------+ |0x01 | RSVP | +----------+-------------------------------+ |0x02 | Segment Routing | +----------+-------------------------------+ The RSVP flag is set to one to indicate that RSVP-TE is enabled on a link. The RSVP flag is set to zero to indicate that RSVP-TE is not enabled on a link. The Segment Routing flag is set to one to indicate that Segment Routing is enabled on a link. The Segment Routing flag is set to zero to indicate that Segment Routing is not enabled on a link ========
- [Isis-wg] draft-hegde-isis-advertising-te-protoco… Chris Bowers
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Peter Psenak
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Peter Psenak
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Shraddha Hegde
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Peter Psenak
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Acee Lindem (acee)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Uma Chunduri
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Uma Chunduri
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Shraddha Hegde
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Uma Chunduri
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Greg Mirsky
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Greg Mirsky
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Greg Mirsky
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Greg Mirsky
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Uma Chunduri
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Jeff Tantsura
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Les Ginsberg (ginsberg)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Acee Lindem (acee)
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… stephane.litkowski
- Re: [Isis-wg] draft-hegde-isis-advertising-te-pro… Acee Lindem (acee)