IETF Logo Mail Archive

Re: [Isis-wg] Mail regarding draft-ietf-isis-l2bundles

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Tue, 10 May 2016 16:46 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 CDE1412D75E; Tue, 10 May 2016 09:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 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.996, 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 prPWT8dGAfU2; Tue, 10 May 2016 09:46:33 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0ED12D782; Tue, 10 May 2016 09:46:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9340; q=dns/txt; s=iport; t=1462898787; x=1464108387; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yPoMf83pORILt1vJ7uLDL5kulDaj2WRK+Ql+9GBjQs0=; b=FcHy4XshsUDFepJAmswv8/VK+1ptOEI4lW3JqBctJgCJIWAVgRc7OFvR pek9nrdokQlNriGQ7ORYBX9mcr6SDHyhlEuVNMSOiSZWARg793ccFX4gA sM+SfxxVD8yziFSwstKHEVWTpf6WJmhZjnT8WmgOz/R8vPtSEYuTPa5Cq c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfAgDhDzJX/51dJa1dgmxMVX0GtDeEdwENgXaGEAKBNTgUAQEBAQEBAWUnhEEBAQEELUwQAgEIEQQBASgHMhQJCAEBBAENBQiIIgG5AAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIIRMhCIBAVGFIwWYJwGOFo8gjz8BHgEBQoNrbodVNgF+AQEB
X-IronPort-AV: E=Sophos;i="5.24,605,1454976000"; d="scan'208,217";a="271025400"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2016 16:46:26 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u4AGkQR9009090 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 May 2016 16:46:26 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 May 2016 11:46:25 -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.1104.009; Tue, 10 May 2016 11:46:25 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, "draft-ietf-isis-l2bundles@ietf.org" <draft-ietf-isis-l2bundles@ietf.org>
Thread-Topic: Mail regarding draft-ietf-isis-l2bundles
Thread-Index: AdGqvcPaRvaJKpRnRESC+nv4N2fWPAAHHJ/g
Date: Tue, 10 May 2016 16:46:25 +0000
Message-ID: <5d64ca10c08b4716b7cf985d60b05673@XCH-ALN-001.cisco.com>
References: <BN3PR05MB27067757FCE70FEF9561A988D5710@BN3PR05MB2706.namprd05.prod.outlook.com>
In-Reply-To: <BN3PR05MB27067757FCE70FEF9561A988D5710@BN3PR05MB2706.namprd05.prod.outlook.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: [171.69.34.164]
Content-Type: multipart/alternative; boundary="_000_5d64ca10c08b4716b7cf985d60b05673XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/isis-wg/XIpWcG_wrn937ZHYi8LeLIa8dls>
Cc: "isis-wg@ietf.org list" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Mail regarding draft-ietf-isis-l2bundles
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 10 May 2016 16:46:36 -0000

Shraddha -

From: Shraddha Hegde [mailto:shraddha@juniper.net]
Sent: Tuesday, May 10, 2016 6:31 AM
To: draft-ietf-isis-l2bundles@ietf.org
Cc: isis-wg@ietf.org list
Subject: Mail regarding draft-ietf-isis-l2bundles

Authors,

I have a few generic comments on the draft.


-          The draft needs an "elements of procedure" section that talks about when the new TLV gets originated/updated/purged

[Les:] What is being advertised are attributes of L2 bundle member links which comprise an L3 interface on which IS-IS has an adjacency. This is quite comparable to link attributes advertised for the parent L3 link as defined in RFC 5305. Note that an equivalent "elements of procedures" section does not exist in that document. Other than saying the advertisements follow the state of the L2 bundle member I am not sure what such a section would say.
Is it really unclear as to when the advertisements would be sent/withdrawn?


-          Section 2.2 talks about shared attributes sub-tlv. It's not clear why the  sub-tlvs  defined for tlv 22/222 needs to be added/duplicated

In TLV 25. For ex: link bandwidth sub TLV will be part of tlv 22 so what is the specific need to add it in TLV25 as well?

What would be the behavior if the contents of sub-tlvs from 22 and 25 do not match?



[Les:] The sub-TLVs advertised in TLV 22 describe the L3 link - which is the composite of the L2 bundle members. The advertisements which are defined in this document describe individual bundle members. There is no intent to compare attributes advertised for L2 bundle members with attributes advertised for the L3 link.



If there are no specific use cases, it's better to omit this section (In the interest of reducing implementation complexity)

and add it later in a new draft whenever such a use case arises.



[Les:] Sorry, I do not know to what section this comment should be applied.



   Les





Rgds

Shraddha

v2.23.0 | Report a Bug | By Email