From internet-drafts@ietf.org Mon Jun 10 12:29:30 2013 Return-Path: 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 BE93221F9A87; Mon, 10 Jun 2013 12:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NV9RAyAum9uS; Mon, 10 Jun 2013 12:29:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBC721F9A7B; Mon, 10 Jun 2013 12:29:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51 Message-ID: <20130610192930.15365.84096.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2013 12:29:30 -0700 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D Action: draft-ietf-isis-extended-sequence-no-tlv-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:29:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IS-IS for IP Internets Working Group of t= he IETF. Title : IS-IS Extended Sequence number TLV Author(s) : Uma Chunduri Wenhu Lu Albert Tian Naiming Shen Filename : draft-ietf-isis-extended-sequence-no-tlv-00.txt Pages : 12 Date : 2013-06-10 Abstract: This document defines Extended Sequence number TLV to protect Intermediate System to Intermediate System (IS-IS) PDUs from replay attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-extended-sequence-no-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-isis-extended-sequence-no-tlv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vvasanth@Brocade.com Thu Jun 13 00:20:19 2013 Return-Path: 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 3CF7C21F9703 for ; Thu, 13 Jun 2013 00:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkmDN8fk1-EF for ; Thu, 13 Jun 2013 00:20:13 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id E381021F9949 for ; Thu, 13 Jun 2013 00:20:11 -0700 (PDT) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id r5D6iAd2006228 for ; Thu, 13 Jun 2013 00:20:11 -0700 Received: from brmwp-exchub01.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1cxnnfgsv4-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 13 Jun 2013 00:20:11 -0700 Received: from brm-excashub-2.corp.brocade.com (172.16.187.49) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 13 Jun 2013 01:20:09 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.61]) by brm-excashub-2.corp.brocade.com ([172.16.187.74]) with mapi; Thu, 13 Jun 2013 01:20:09 -0600 From: Vijay Kumar Vasantha To: "isis-wg@ietf.org" Date: Thu, 13 Jun 2013 01:18:25 -0600 Thread-Topic: draft-ietf-isis-reverse-metric-03 Thread-Index: Ac5oA8WGKrkzsLUaQTGQ8ieJHdwHxAAAXKyw Message-ID: <51BD2AE8016AE441B63F5661159C99020F29ED579C@BRM-EXCH-3.corp.brocade.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_51BD2AE8016AE441B63F5661159C99020F29ED579CBRMEXCH3corpb_" MIME-Version: 1.0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1306120331 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-13_03:2013-06-12, 2013-06-13, 1970-01-01 signatures=0 X-Mailman-Approved-At: Thu, 13 Jun 2013 09:26:47 -0700 Subject: [Isis-wg] Reg: draft-ietf-isis-reverse-metric-03 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 08:35:21 -0000 --_000_51BD2AE8016AE441B63F5661159C99020F29ED579CBRMEXCH3corpb_ Content-Type: text/plain; charset="us-ascii" Hi, While reading draft-ietf-isis-reverse-metric-03 I got the following query, could someone please clarify it. - Could the link to DIS be made link of last resort on a LAN. For example consider a topology where three routers A, B & C are connected on a LAN, where A is DIS. A----------A'-----------B | | | C If administrator wishes to remove the bi-directional traffic for node A, then configuring reverse-metric on A will, - Make the cost from A to A' high. - Not affect the cost from A' to A in pseudo-node LSP. So the traffic from non-DIS nodes could still reach DIS on this LAN. Perhaps one of the ways to address it would be, Upon administrator enabling reverse-metric on a LAN, - If the node is a DIS on the LAN then DIS could increase the cost to itself in the pseudonode LSP. Thanks, Vijay --_000_51BD2AE8016AE441B63F5661159C99020F29ED579CBRMEXCH3corpb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

While read= ing draft-ietf-isis-reverse-metric-03 I got the following query, could some= one please clarify it.

 =

-       = ;   Could the link to DIS be made link of= last resort on a LAN.

 =

 

For exam= ple consider a topology where three routers A, B & C are connected on a= LAN, where A is DIS.

 <= /p>

A----------A’-----------B

          = ;          |

         &nb= sp;          |

           = ;         |

          &n= bsp;        C

 

If administrator wishes= to remove the bi-directional traffic for node A, then configuring reverse-= metric on A will,

 

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l= fo2'>-       &nbs= p;  Make the cost from A to A’ high.

-     &nbs= p;    Not affect the cost from AR= 17; to A in pseudo-node LSP.

 = ;

So the traffic from non-DIS nodes could sti= ll reach DIS on this LAN.

 

Perhaps one of the ways to address it would be,=

Upon administrator enabling reverse-met= ric on a LAN,

-   = ;       If the node i= s a DIS on the LAN then DIS could increase the cost to itself in the pseudo= node LSP.

 

Thanks,

Vijay

 

 =

 

 

= --_000_51BD2AE8016AE441B63F5661159C99020F29ED579CBRMEXCH3corpb_-- From abhishekv.verma@gmail.com Fri Jun 14 10:19:06 2013 Return-Path: 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 5F93821F9D21 for ; Fri, 14 Jun 2013 10:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQemKhs9AcK2 for ; Fri, 14 Jun 2013 10:19:06 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AB1F221F9C96 for ; Fri, 14 Jun 2013 10:19:05 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id m46so731767wev.30 for ; Fri, 14 Jun 2013 10:19:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JjWMBIiDDT03XDzLyEloO0q0zJzL8/tyOoKkIkMjKNw=; b=qjVbXsFqAROtaGH6bK8xxwrtAGBtmjInVS5jnsS7gTKS4aNNo7TXs+u3uLtm0j7kbb r8RJJ2qGqHoEJ/ImLgjZh/PCHJgZhW68mkLFOX6Hzhh9FpMoQWTr3qMFvERULkwmqXkX fpP3NNOEC3JHdenph+mEbvEKwncrH4BcFn1o+9KBTqdCMEr/RZgAAVNQZadKerpeqOJl xWW76Z15akNXOs8sku2dGH+jyukPHT2bmDxzGpzGxYBQfj8emqbkwclY1Y1yGzSTk+Gv pzlGgkM9zTEhNFkNDHqmDms1ZHC1NCHQh7a/nT6gMgQNujqzkiMl586wmJGWaH42EL79 AVWw== MIME-Version: 1.0 X-Received: by 10.180.206.70 with SMTP id lm6mr1911667wic.50.1371230344857; Fri, 14 Jun 2013 10:19:04 -0700 (PDT) Received: by 10.194.31.228 with HTTP; Fri, 14 Jun 2013 10:19:04 -0700 (PDT) Date: Fri, 14 Jun 2013 22:49:04 +0530 Message-ID: From: Abhishek Verma To: "isis-wg@ietf.org" Content-Type: multipart/alternative; boundary=001a11c265be9c533704df207194 Subject: [Isis-wg] ISIS LSP fragmentation X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:19:06 -0000 --001a11c265be9c533704df207194 Content-Type: text/plain; charset=ISO-8859-1 Hi, In ISIS routing protocol, the maximum size of a single LSP, as specified by ISO 10589, is1492 bytes. If a router cannot fit all of its TLVs into this maximum length, it produces a multipart LSP. The first part will have an LSP number of 0x00, the second 0x01, the third 0x02, and so on. When a router has to break its LSP into multiple parts, will it break one TLV into 2 parts? That is some information of a TLV is contained in the first part and other information of the previous TLV is contained in the next part. Regards, Abhishek --001a11c265be9c533704df207194 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

In ISIS routing protocol, the maxim= um size of a single LSP,=20 as specified by ISO 10589, is1492 bytes. If a router cannot fit all of its = TLVs=20 into this maximum length, it produces a multipart LSP. The first part will = have=20 an LSP number of 0x00, the second 0x01, the third 0x02, and so on.

When a router has to break its LSP into multiple=20 parts,=A0 will it break one TLV into 2 parts? That is some information of a= TLV is=20 contained in the first part and other information of the previous TLV is=20 contained in the next part. =A0

Regards,=A0

Abhishek



--001a11c265be9c533704df207194-- From tony.li@tony.li Fri Jun 14 10:27:20 2013 Return-Path: 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 7211A21F9D01 for ; Fri, 14 Jun 2013 10:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+fQ-xoGNQiN for ; Fri, 14 Jun 2013 10:27:14 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:17]) by ietfa.amsl.com (Postfix) with ESMTP id 992A121F9CE7 for ; Fri, 14 Jun 2013 10:27:13 -0700 (PDT) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta10.emeryville.ca.mail.comcast.net with comcast id oEGG1l0041zF43QAAHTDfR; Fri, 14 Jun 2013 17:27:13 +0000 Received: from [192.168.2.111] ([98.248.36.188]) by omta24.emeryville.ca.mail.comcast.net with comcast id oHTC1l00B43ZcXW8kHTCqk; Fri, 14 Jun 2013 17:27:13 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tony Li In-Reply-To: Date: Fri, 14 Jun 2013 10:27:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Abhishek Verma X-Mailer: Apple Mail (2.1508) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371230833; bh=LUtb822epfnNaZd1UiAkuTPIUc29e9qrJzHkYtGYCdw=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=dRMvcRqhJp8PRr028qdBuBUpJ4ft03LK0V3uvxd6GKWIJ5O697y+BypVJzKGh5oNC 73CLK7KH4dqGobJ5mv/ompQ1V5ANeGJItLLZBghgy0BtqgHj1xjE/9vbBQ/0U0/Eww rz0QOcUj69j90hKhrP/MqZmm6VBULzdGEJcLwQh2xZ6r4Fgr5qHlLGZ5opQ8fqBePp 1s2iQuGKF6lit20pd8xewBoVROpt9O3glvxUub+zF0EgrDR81RC2+8BkAVO52ed5br oq1UxOsZhxNoXL78xaS00M+6A4u5Dz4mW2GJP+0oUH+Tu6RcoqpxowlT3XPY/ldWYq YsxO+N9OA1fFQ== Cc: "isis-wg@ietf.org" Subject: Re: [Isis-wg] ISIS LSP fragmentation X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:27:20 -0000 > In ISIS routing protocol, the maximum size of a single LSP, as = specified by ISO 10589, is1492 bytes. If a router cannot fit all of its = TLVs into this maximum length, it produces a multipart LSP. The first = part will have an LSP number of 0x00, the second 0x01, the third 0x02, = and so on. >=20 > When a router has to break its LSP into multiple parts, will it break = one TLV into 2 parts? That is some information of a TLV is contained in = the first part and other information of the previous TLV is contained in = the next part. =20 Welcome to the WG. This list is primarily intended for standards making = discussions, not for educational purposes. That said, no, splitting a TLV would get hairy. TLVs are atomic and = should always appear in their entirety in a single fragment. Tony From shane@castlepoint.net Fri Jun 14 12:26:30 2013 Return-Path: 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 445B721F9D5B for ; Fri, 14 Jun 2013 12:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vrWkgIGDXIM for ; Fri, 14 Jun 2013 12:26:25 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9791E21F9D4B for ; Fri, 14 Jun 2013 12:26:25 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id D052830004A for ; Fri, 14 Jun 2013 19:26:24 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 429A6300047; Fri, 14 Jun 2013 13:26:22 -0600 (MDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CDA67712-2CD9-405A-B590-1A73AB725294" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Shane Amante In-Reply-To: <51BD2AE8016AE441B63F5661159C99020F29ED579C@BRM-EXCH-3.corp.brocade.com> Date: Fri, 14 Jun 2013 13:26:22 -0600 Message-Id: <4E3BAC27-0317-4F37-88A5-BB8A0AD314E4@castlepoint.net> References: <51BD2AE8016AE441B63F5661159C99020F29ED579C@BRM-EXCH-3.corp.brocade.com> To: Vijay Kumar Vasantha X-Mailer: Apple Mail (2.1508) X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Jun 14 13:26:24 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 51bb6e6042071158096510 X-DSPAM-Factors: 27, 2013+at, 0.40000, 2013+at, 0.40000, above+addresses, 0.40000, above+addresses, 0.40000, to+#+#+#+link, 0.40000, to+#+#+#+link, 0.40000, is+DIS, 0.40000, is+DIS, 0.40000, response+#+the, 0.40000, response+#+the, 0.40000, DIS+#+#+LAN, 0.40000, DIS+#+#+LAN, 0.40000, list+#+#+ietf, 0.40000, list+#+#+ietf, 0.40000, got+#+#+#+could, 0.40000, got+#+#+#+could, 0.40000, back+#+#+at, 0.40000, back+#+#+at, 0.40000, A+#+pseudo, 0.40000, A+#+pseudo, 0.40000, Jun+13, 0.40000, Jun+13, 0.40000, com+#+#+#+reading, 0.40000, com+#+#+#+reading, 0.40000, bi+#+#+for, 0.40000, bi+#+#+for, 0.40000, could+#+please, 0.40000 Cc: "isis-wg@ietf.org" Subject: Re: [Isis-wg] Reg: draft-ietf-isis-reverse-metric-03 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 19:26:30 -0000 --Apple-Mail=_CDA67712-2CD9-405A-B590-1A73AB725294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Vijay, Please see below. On Jun 13, 2013, at 1:18 AM, Vijay Kumar Vasantha = wrote: > Hi, > =20 > While reading draft-ietf-isis-reverse-metric-03 I got the following = query, could someone please clarify it. > =20 > - Could the link to DIS be made link of last resort on a LAN. > =20 > =20 > For example consider a topology where three routers A, B & C are = connected on a LAN, where A is DIS. > =20 > A----------A=92-----------B > | > | > | > C I take it A' represents the pseudo-node? > If administrator wishes to remove the bi-directional traffic for node = A, then configuring reverse-metric on A will, > =20 > - Make the cost from A to A=92 high. > - Not affect the cost from A=92 to A in pseudo-node LSP. The latter bullet is incorrect for the scenario you describe. The DIS = should increase the cost in the pseudo-node LSP (A') back to A, at the = same time. But, before you answer, please see the next response. > So the traffic from non-DIS nodes could still reach DIS on this LAN. > =20 > Perhaps one of the ways to address it would be, > Upon administrator enabling reverse-metric on a LAN, > - If the node is a DIS on the LAN then DIS could increase the = cost to itself in the pseudonode LSP. Actually, I believe the comment/question you have is actually more = applicable to a related draft: http://tools.ietf.org/html/draft-ietf-isis-oper-enhance-03 In particular, you may wish to review Section 3, "Pseudonodes with = Non-zero Metrics", of the aforementioned draft, which describes where = the DIS, itself, is altering the metric in the Pseudo-node LSP to = achieve the effect you describe. Anyway, let me know if the above addresses you question or not. Thanks, -shane > Thanks, > Vijay > =20 > =20 > =20 > =20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg --Apple-Mail=_CDA67712-2CD9-405A-B590-1A73AB725294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Vijay,

Please see below.

On = Jun 13, 2013, at 1:18 AM, Vijay Kumar Vasantha <vvasanth@Brocade.com> = wrote:
 
While reading draft-ietf-isis-reverse-metric-03 I = got the following query, could someone please clarify = it.
 
- Could the = link to DIS be made link of last resort on a LAN.
 
For example = consider a topology where three routers A, B & C are connected on a = LAN, where A is DIS.
    =             =     |
If = administrator wishes to remove the bi-directional traffic for node A, = then configuring reverse-metric on A will,
 
- Make the cost = from A to A=92 high.
- Not affect = the cost from A=92 to A in pseudo-node = LSP.

The latter bullet is = incorrect for the scenario you describe.  The DIS should increase = the cost in the pseudo-node LSP (A') back to A, at the same time. =  But, before you answer, please see the next = response.


So the traffic from non-DIS nodes could still = reach DIS on this LAN.
Perhaps one of the = ways to address it would be,
Upon = administrator enabling reverse-metric on a LAN,
- If the node = is a DIS on the LAN then DIS could increase the cost to itself in the = pseudonode = LSP.

Actually, I = believe the comment/question you have is actually more applicable to a = related draft:

In particular, you may wish to review Section 3, "Pseudonodes = with Non-zero Metrics", of the aforementioned draft, which describes = where the DIS, itself, is altering the metric in the Pseudo-node LSP to = achieve the effect you describe.

Anyway, let me = know if the above addresses you question or = not.

Thanks,

-shane


Thanks,
In-Reply-To: <51BD2AE8016AE441B63F5661159C99020F29ED579C@BRM-EXCH-3.corp.brocade.com> Date: Fri, 14 Jun 2013 15:02:51 -0700 Message-Id: References: <51BD2AE8016AE441B63F5661159C99020F29ED579C@BRM-EXCH-3.corp.brocade.com> To: Vijay Kumar Vasantha X-Mailer: Apple Mail (2.1503) Cc: "isis-wg@ietf.org" Subject: Re: [Isis-wg] Reg: draft-ietf-isis-reverse-metric-03 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 22:02:58 -0000 --Apple-Mail=_6FD994EC-149B-40C7-AFCD-075F17040D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Vijay, please see inline. On Jun 13, 2013, at 12:18 AM, Vijay Kumar Vasantha = wrote: > Hi, > =20 > While reading draft-ietf-isis-reverse-metric-03 I got the following = query, could someone please clarify it. > =20 > - Could the link to DIS be made link of last resort on a LAN. > =20 > =20 > For example consider a topology where three routers A, B & C are = connected on a LAN, where A is DIS. > =20 > A----------A=92-----------B > | > | > | > C > =20 > If administrator wishes to remove the bi-directional traffic for node = A, then configuring reverse-metric on A will, > =20 > - Make the cost from A to A=92 high. > - Not affect the cost from A=92 to A in pseudo-node LSP. No, as Shane mentioned, this 'reverse metric' is in the direction of A' = to A, assume if you want to change the default behavior which is metric of zero. Basically you have metric from two sides, from any node to A', and from = A' to any node. If you change metric from a node to A', that's the normal ISIS behavior = on LAN today, which controls the traffic outbound to the LAN towards all the other nodes; = This draft allows to to change the metric from A' to any node on the LAN, which controls the = inbound traffic into that node. In your case, if you what to increase the inbound metric = to A, then this draft allows you to set A' to A metric. > =20 > So the traffic from non-DIS nodes could still reach DIS on this LAN. the above change does not change the traffic between B to C, or from C = to B, or outbound traffic from A to B or C. > =20 > Perhaps one of the ways to address it would be, > Upon administrator enabling reverse-metric on a LAN, > - If the node is a DIS on the LAN then DIS could increase the = cost to itself in the pseudonode LSP. > =20 That is intention of the draft. It allows any node on the LAN to use IIH = packet to request the DIS (could be itself) to raise/change the 'reverse metric' towards = the requesting node. Regards, - Naiming > Thanks, > Vijay > =20 > =20 > =20 > =20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg --Apple-Mail=_6FD994EC-149B-40C7-AFCD-075F17040D46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

Hi = Vijay,

please see inline.

On = Jun 13, 2013, at 12:18 AM, Vijay Kumar Vasantha <vvasanth@Brocade.com> = wrote:

 
While reading draft-ietf-isis-reverse-metric-03 I = got the following query, could someone please clarify = it.
 
- Could the = link to DIS be made link of last resort on a LAN.
 
For example = consider a topology where three routers A, B & C are connected on a = LAN, where A is DIS.
    =             =     |
 
If = administrator wishes to remove the bi-directional traffic for node A, = then configuring reverse-metric on A will,
 
- Make the cost = from A to A=92 high.
- Not affect = the cost from A=92 to A in pseudo-node = LSP.

No, as Shane = mentioned, this 'reverse metric' is in the direction of A' to A, = assume
if you want to change the default behavior which is = metric of zero.
Basically you have metric from two sides, from = any node to A', and from A' to any node.
If you change metric = from a node to A', that's the normal ISIS behavior on LAN today, = which
controls the traffic outbound to the LAN towards all the = other nodes; This draft allows to
to change the metric from A' = to any node on the LAN, which controls the inbound = traffic
into that node. In your case, if you what to increase = the inbound metric to A, then
this draft allows you to set A' = to A metric.

 
So = the traffic from non-DIS nodes could still reach DIS on this = LAN.

the above change does = not change the traffic between B to C, or from C to B, or = outbound
traffic from A to B or C.

 
Perhaps one of the ways to address it would = be,
Upon administrator enabling = reverse-metric on a LAN,
- If the node = is a DIS on the LAN then DIS could increase the cost to itself in the = pseudonode LSP.
Thanks,
Subject: Re: [Isis-wg] Reg: draft-ietf-isis-reverse-metric-03 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 15:41:30 -0000 --_000_51BD2AE8016AE441B63F5661159C99020F2A98E2BCBRMEXCH3corpb_ Content-Type: text/plain; charset="us-ascii" Hi, Thanks Shane & Naiming for explaining and pointing out to the related draft 'draft-ietf-isis-oper-enhance-03'. Yes, the sec 3 of this related draft addresses my question. Thanks, Vijay From: Shane Amante [mailto:shane@castlepoint.net] Sent: Saturday, June 15, 2013 12:56 AM To: Vijay Kumar Vasantha Cc: isis-wg@ietf.org Subject: Re: [Isis-wg] Reg: draft-ietf-isis-reverse-metric-03 Hi Vijay, Please see below. On Jun 13, 2013, at 1:18 AM, Vijay Kumar Vasantha > wrote: Hi, While reading draft-ietf-isis-reverse-metric-03 I got the following query, could someone please clarify it. - Could the link to DIS be made link of last resort on a LAN. For example consider a topology where three routers A, B & C are connected on a LAN, where A is DIS. A----------A'-----------B | | | C I take it A' represents the pseudo-node? If administrator wishes to remove the bi-directional traffic for node A, then configuring reverse-metric on A will, - Make the cost from A to A' high. - Not affect the cost from A' to A in pseudo-node LSP. The latter bullet is incorrect for the scenario you describe. The DIS should increase the cost in the pseudo-node LSP (A') back to A, at the same time. But, before you answer, please see the next response. So the traffic from non-DIS nodes could still reach DIS on this LAN. Perhaps one of the ways to address it would be, Upon administrator enabling reverse-metric on a LAN, - If the node is a DIS on the LAN then DIS could increase the cost to itself in the pseudonode LSP. Actually, I believe the comment/question you have is actually more applicable to a related draft: http://tools.ietf.org/html/draft-ietf-isis-oper-enhance-03 In particular, you may wish to review Section 3, "Pseudonodes with Non-zero Metrics", of the aforementioned draft, which describes where the DIS, itself, is altering the metric in the Pseudo-node LSP to achieve the effect you describe. Anyway, let me know if the above addresses you question or not. Thanks, -shane Thanks, Vijay _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg --_000_51BD2AE8016AE441B63F5661159C99020F2A98E2BCBRMEXCH3corpb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /o:p>

 

Thanks Shane & Naiming for explaining and poin= ting out to the related draft ‘draft-ietf-isis-oper-enhance-03’= .

Yes, the sec 3 of this r= elated draft addresses my question.

 

Thanks,

Vijay

=

 

 

= From:= Shane Amante [mailto:shane@castlepoint.net]
Sent: Saturday, Jun= e 15, 2013 12:56 AM
To: Vijay Kumar Vasantha
Cc: isis-w= g@ietf.org
Subject: Re: [Isis-wg] Reg: draft-ietf-isis-reverse-me= tric-03

 

Hi Vijay,

 

Please see below.<= o:p>

 

On Jun 13, 2013, at 1:18 AM, Vijay Kumar Vasantha &l= t;vvasanth@Brocade.com> wrot= e:

Hi,

 

While reading dr= aft-ietf-isis-reverse-metric-03 I got the following query, could someone pl= ease clarify it.

 <= /o:p>

-  &= nbsp;       Could the link to DIS be made link of last resort on a LAN.<= o:p>

 

<= /div>

 

For example consider a topology where three routers A, B & C are conn= ected on a LAN, where A is DIS.

 

A----------A’= ;-----------B

  &nb= sp;            =      |

&n= bsp;            = ;       |

            &n= bsp;       |

=

          &= nbsp;        C

 

<= p class=3DMsoNormal>I take it A' represents the pseudo-node?

=

 



If administrator w= ishes to remove the bi-directional traffic for node A, then configuring rev= erse-metric on A will,

 =

- &= nbsp;        Make the cost from A to A’ high.

-    = ;      Not affect the cost from A’ to A in pseudo-node LSP.<= /span>

 

=

The latter bullet is incorrect for the scenario you de= scribe.  The DIS should increase the cost in the pseudo-node LSP (A') = back to A, at the same time.  But, before you answer, please see the n= ext response.

 



So the traffic from non-DIS nodes could still reach DIS on this L= AN.

 <= /p>

Perhaps one of the ways to address it would be,=

Upon administrator enabling = reverse-metric on a LAN,

-          If the node is a DIS on the LA= N then DIS could increase the cost to itself in the pseudonode LSP.

 

Actually, I believe the comment/question you = have is actually more applicable to a related draft:

http://tools.ietf.org/html/draft-ietf-isis-oper-enhance= -03

 

=

In particular, you may wish to review Secti= on 3, "Pseudonodes with Non-zero Metrics", of the aforementioned = draft, which describes where the DIS, itself, is altering the metric in the= Pseudo-node LSP to achieve the effect you describe.

 

Anyway, let me know if the above addresses you question or not.

 

Thanks,

&= nbsp;

-shane

<= div>

 


Thanks,

<= /div>

Vijay

 

 

 

 

______________= _________________________________
Isis-wg mailing list
Isis-wg@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/isis-wg=

 

= --_000_51BD2AE8016AE441B63F5661159C99020F2A98E2BCBRMEXCH3corpb_-- From ginsberg@cisco.com Sun Jun 16 22:07:32 2013 Return-Path: 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 555A621F99E8 for ; Sun, 16 Jun 2013 22:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f43b70kMsaa4 for ; Sun, 16 Jun 2013 22:07:27 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7667121F99E3 for ; Sun, 16 Jun 2013 22:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2424; q=dns/txt; s=iport; t=1371445647; x=1372655247; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fumhtCkpf7priY7hZ2uU2wOGFrAPvFq+3g2upi3QTKI=; b=TVWVUHArN0VX+xJTzbhS3SBp8ezI12l1lh1cKQx7ijx3PzKOIbZS1//8 IaHQwWN6xZStSdC/IPXe8SFT9CtCs4FsSIYxLPRhsfKxr8U3YHhpn6RWG tyqJBN2n1BahAvXrgL0mpr1XqXqw8EwugdoUBWzIzvRT1y3AcohI36I6L 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogHAHSYvlGtJXG+/2dsb2JhbABagwkxQwaCf7tYDXcWbQeCIwEBAQQjEUMOBAIBCBEEAQEDAgYdAwICAjAUAQYBAQUDAgQTCAGIBQcFpnmQaIEmjGmBBxYiBoJGM2EDmGqQGoMPgWhA X-IronPort-AV: E=Sophos;i="4.87,878,1363132800"; d="scan'208";a="223556346" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jun 2013 05:07:27 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5H57Qls030741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Jun 2013 05:07:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.215]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 00:07:26 -0500 From: "Les Ginsberg (ginsberg)" To: "isis-wg@ietf.org" Thread-Topic: New Version Notification for draft-ginsberg-isis-fs-lsp-01.txt Thread-Index: AQHOaxf8jolK/j+aO0CKqw0uAmkLkJk5WrUA Date: Mon, 17 Jun 2013 05:07:26 +0000 Message-ID: References: <20130617050317.23917.46082.idtracker@ietfa.amsl.com> In-Reply-To: <20130617050317.23917.46082.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.70.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Isis-wg] FW: New Version Notification for draft-ginsberg-isis-fs-lsp-01.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 05:07:32 -0000 RllJLg0KDQogICBMZXMNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IFN1bmRheSwgSnVuZSAxNiwgMjAxMyAxMDowMyBQTQ0KVG86IFN0ZWZhbm8gUHJldmlk aSAoc3ByZXZpZGkpOyBZaSBZYW5nICh5aXlhKTsgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNClN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ2luc2JlcmctaXNpcy1m cy1sc3AtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdpbnNiZXJnLWlz aXMtZnMtbHNwLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMZXMg R2luc2JlcmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1naW5zYmVyZy1pc2lzLWZzLWxzcA0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkgSVMt SVMgRmxvb2RpbmcgU2NvcGUgTFNQcw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDYtMTYNCkdyb3Vw OgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxOQ0KVVJMOiAgICAg ICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1naW5zYmVy Zy1pc2lzLWZzLWxzcC0wMS50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1naW5zYmVyZy1pc2lzLWZzLWxzcA0KSHRtbGl6ZWQ6ICAgICAg ICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1naW5zYmVyZy1pc2lzLWZzLWxzcC0w MQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1naW5zYmVyZy1pc2lzLWZzLWxzcC0wMQ0KDQpBYnN0cmFjdDoNCiAgIEludGVybWVkaWF0ZSBT eXN0ZW0gVG8gSW50ZXJtZWRpYXRlIFN5c3RlbSAoSVMtSVMpIHByb3ZpZGVzIGVmZmljaWVudA0K ICAgYW5kIHJlbGlhYmxlIGZsb29kaW5nIG9mIGluZm9ybWF0aW9uIHRvIGl0cyBwZWVycy4gIEhv d2V2ZXIgdGhlDQogICBjdXJyZW50IGZsb29kaW5nIHNjb3BlcyBhcmUgbGltaXRlZCB0byBlaXRo ZXIgYXJlYSB3aWRlIHNjb3BlIG9yDQogICBkb21haW4gd2lkZSBzY29wZS4gIFRoZXJlIGFyZSBl eGlzdGluZyB1c2UgY2FzZXMgd2hlcmUgc3VwcG9ydCBvZg0KICAgb3RoZXIgZmxvb2Rpbmcgc2Nv cGVzIGFyZSBkZXNpcmFibGUuICBUaGlzIGRvY3VtZW50IGRlZmluZXMgbmV3DQogICBQcm90b2Nv bCBEYXRhIFVuaXRzIChQRFVzKSB3aGljaCBwcm92aWRlIHN1cHBvcnQgZm9yIG5ldyBmbG9vZGlu Zw0KICAgc2NvcGVzIGFzIHdlbGwgYXMgYWRkaXRpb25hbCBzcGFjZSBmb3IgYWR2ZXJ0aXNpbmcg aW5mb3JtYXRpb24NCiAgIHRhcmdldGVkIGZvciB0aGUgY3VycmVudGx5IHN1cHBvcnRlZCBmbG9v ZGluZyBzY29wZXMuDQoNCiAgIFRoZSBwcm90b2NvbCBleHRlbnNpb25zIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudCBhcmUgbm90IGJhY2t3YXJkcw0KICAgY29tcGF0aWJsZSB3aXRoIGV4aXN0aW5n IGltcGxlbWVudGF0aW9ucyBhbmQgc28gbXVzdCBiZSBkZXBsb3llZCB3aXRoDQogICBjYXJlLg0K DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K DQo= From internet-drafts@ietf.org Mon Jun 17 07:25:29 2013 Return-Path: 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 85D6921F8FA1; Mon, 17 Jun 2013 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CuHhEJLZAsD; Mon, 17 Jun 2013 07:25:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9FC21F8B21; Mon, 17 Jun 2013 07:25:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130617142527.25409.45488.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 07:25:27 -0700 Cc: isis-wg@ietf.org Subject: [Isis-wg] I-D Action: draft-ietf-isis-te-metric-extensions-00.txt X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:25:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IS-IS for IP Internets Working Group of t= he IETF. Title : IS-IS Traffic Engineering (TE) Metric Extensions Author(s) : Stefano Previdi Spencer Giacalone Dave Ward John Drake Alia Atlas Clarence Filsfils Filename : draft-ietf-isis-te-metric-extensions-00.txt Pages : 17 Date : 2013-06-17 Abstract: In certain networks, such as, but not limited to, financial information networks (e.g. stock market data providers), network performance criteria (e.g. latency) are becoming as critical to data path selection as other metrics. This document describes extensions to IS-IS TE [RFC5305] such that network performance information can be distributed and collected in a scalable fashion. The information distributed using ISIS TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms with which network performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-isis-te-metric-extensions-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stbryant@cisco.com Fri Jun 21 07:39:14 2013 Return-Path: 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 03D2521F9BDB; Fri, 21 Jun 2013 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.383 X-Spam-Level: X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faByYFTegINx; Fri, 21 Jun 2013 07:39:09 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id B7B8C11E8193; Fri, 21 Jun 2013 07:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8857; q=dns/txt; s=iport; t=1371825548; x=1373035148; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=SZPcSEOoxK3ukKiU5hTJ1TDWrdeF6yPnSvZladOuWK4=; b=ZaPNa+t/BTz+JKpqtEOMviC0zBmDJ6M81l9xuTn5/uQrsZIVLlAClnsW Ovls2DwBkrjSKFtWu7gS4H9F1dTReCNgUJUYhtzp2syr9mG/9fla9XWR+ tYm+y1pSqJ7jwGmhP+vNqtXrAxVzeoO7w/Db6GXAVbNMTR/LZKLEidRh/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAK1kxFGQ/khN/2dsb2JhbABbgwkxiSm2VYECFnSCIwEBAQQBAQFrCgEMBBwDAQIKFg8JAwIBAgEVHwcCCAYBDAEFAgEBF4dzDLxCjX6BOhEHBoNbA5dDgSmQG4MQ X-IronPort-AV: E=Sophos;i="4.87,913,1363132800"; d="scan'208,217";a="14893308" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 21 Jun 2013 14:39:06 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5LEd4u6025782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Jun 2013 14:39:04 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r5LEd3hm025510; Fri, 21 Jun 2013 15:39:03 +0100 (BST) Message-ID: <51C46587.3020907@cisco.com> Date: Fri, 21 Jun 2013 15:39:03 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: isis-wg , "ospf@ietf.org" , "mpls@ietf.org" , "rtgwg@ietf.org" , 6man@ietf.org References: <51C352CA.6000307@cisco.com> In-Reply-To: <51C352CA.6000307@cisco.com> X-Forwarded-Message-Id: <51C352CA.6000307@cisco.com> Content-Type: multipart/alternative; boundary="------------080101000407060509050103" Cc: ops-area@ietf.org Subject: [Isis-wg] Fwd: Status BOF in Berlin X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 14:39:14 -0000 This is a multi-part message in MIME format. --------------080101000407060509050103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the working groups on the "To" list. I apologies to those that have already seen this through circulation to routing-discussion, but I know that not everyone is subscribed there. The list for discussion of this topic is status@ietf.org - Stewart -------- Original Message -------- Subject: Status BOF in Berlin Date: Thu, 20 Jun 2013 20:06:50 +0100 From: Stewart Bryant Reply-To: stbryant@cisco.com To: routing-discussion@ietf.org CC: status@ietf.org STATUS * Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS] * Status: Approved * Description The IETF has two packet-based forwarding technologies: IP and MPLS. IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940 ) do not appear to have been implemented at all. The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes. Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE. Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6. This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic. * Responsible Area Directors: Adrian Farrel and Stewart Bryant * BoF Chairs: Alvaro Retana, John Scudder * * Mailing list: https://www.ietf.org/mailman/listinfo/status Further details can be found at http://trac.tools.ietf.org/bof/trac/wiki - Stewart --------------080101000407060509050103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This BOF touches on technology of interest to each of the
working groups on the "To" list.

I apologies to those that have already seen this through
circulation to routing-discussion, but I know that not
everyone is subscribed there.

The list for discussion of this topic is status@ietf.org

- Stewart

-------- Original Message --------
Subject: Status BOF in Berlin
Date: Thu, 20 Jun 2013 20:06:50 +0100
From: Stewart Bryant <stbryant@cisco.com>
Reply-To: stbryant@cisco.com
To: routing-discussion@ietf.org
CC: status@ietf.org


STATUS

  • Name: Stacked Tunnels for Source Routing (STATUS) [Was TUBAS]
  • Status: Approved
  • Description

The IETF has two packet-based forwarding technologies: IP and MPLS.

IP previously had a source-based routing mechanism made available through an IP Option. This mechanism has, however, not been widely used and has a number of issues that make its use inadvisable, and other mechanisms (such as RFC 1940) do not appear to have been implemented at all.

The ability of a router to influence or control the forwarding path of an individual packet or all the packets of a given Forwarding Equivalence Class (FEC) is a desirable feature for a number of reasons including Label Switched Path stitching, egress protection, explicit routing, egress ASBR link selection, and backup (bypass tunnels, Remote Loop-Free Alternates) routing. This can be achieved by facilitating source-initiated selection of routes to complement the route selection provided by existing routing protocols for both inter- domain and intra-domain routes.

Historically, distribution of MPLS label binding information was done by relying on label distribution protocols such as LDP and RSVP-TE.

Several new proposals have been made to make use of the MPLS forwarding plane in novel but backward-compatible ways, and to install forwarding instructions using information distributed by the IGP running in the network, or through the management plane. It has been suggested that similar mechanisms might also be applied in IPv6.

This BoF is intended to discuss the practicalities of various use cases and to establish a consensus around the problem space and desirability of developing solutions in this area with a view to determining whether the IETF should have a Working Group on this topic.

Further details can be found  at http://trac.tools.ietf.org/bof/trac/wiki

- Stewart



--------------080101000407060509050103-- From ietf-ipr@ietf.org Fri Jun 21 09:11:03 2013 Return-Path: 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 3CBDA21F9F3E; Fri, 21 Jun 2013 09:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2BvDK+1r1VA; Fri, 21 Jun 2013 09:11:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 806C511E8193; Fri, 21 Jun 2013 09:11:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: sprevidi@cisco.com, Spencer.giacalone@thomsonreuters.com, wardd@cisco.com, jdrake@juniper.net, akatlas@juniper.net, cfilsfil@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130621161102.21567.63170.idtracker@ietfa.amsl.com> Date: Fri, 21 Jun 2013 09:11:02 -0700 Cc: chopps@rawdofmt.org, isis-wg@ietf.org, dward@cisco.com, adrian@olddog.co.uk, ipr-announce@ietf.org Subject: [Isis-wg] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-isis-te-metric-extensions-00 X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:11:03 -0000 Dear Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Alia Atlas= , Clarence Filsfils: An IPR disclosure that pertains to your Internet-Draft entitled "IS-IS Tra= ffic Engineering (TE) Metric Extensions" (draft-ietf-isis-te-metric-extensions) = was submitted to the IETF Secretariat on 2013-06-19 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2109/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-isis-te-metric- extensions-00.""); The IETF Secretariat From d3e3e3@gmail.com Sat Jun 22 03:39:56 2013 Return-Path: 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 46CD921E8088 for ; Sat, 22 Jun 2013 03:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImGJk2OjRUkf for ; Sat, 22 Jun 2013 03:39:55 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD711E80ED for ; Sat, 22 Jun 2013 03:39:55 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n9so10491058oag.36 for ; Sat, 22 Jun 2013 03:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=QoudAO/mirirQ5yGJpvGBiXtxyiKpmDYhyTUqP/vkvM=; b=QAzrO/nvKYsBVekl1icqfCd8kFX1v0r8XwEd3gGcA2tASCyb/FbkwZe5egh+W3/lAX CSSmm4v8bexlBkLubWWVWIX+BSfxzRMWnFknwx1B5c3f3107a8D+BChOTmwL3SCSIU9Q bTP5ZJMZ/PJpL4BCF2bMNSfpo4AydqnlrvgY/M9VtjvOtviUP8q7LXBXiJ2w4oeVzkyS OmSmAzCVHDHty7AJuYvcOfyDnL2OaWqdv+Oc60tM0POI3mtayKp8EovC6aNtOxfi7z/W 2zzrwc4QcJcKX31GHQLdNj/puuaAAbZYYA7UTSRCvd5yZ7/LNHcQEyFgj0J3Y+gmt1ZP 8YHw== X-Received: by 10.60.97.199 with SMTP id ec7mr2796939oeb.139.1371897593056; Sat, 22 Jun 2013 03:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.12.65 with HTTP; Sat, 22 Jun 2013 03:39:33 -0700 (PDT) From: Donald Eastlake Date: Sat, 22 Jun 2013 06:39:33 -0400 Message-ID: To: isis mailing list Content-Type: text/plain; charset=ISO-8859-1 Subject: [Isis-wg] draft-ietf-trill-rfc6327bis adopted by TRILL WG X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 10:39:56 -0000 Hi, It may be of interest that draft-ietf-trill-rfc6327bis-00.txt (TRILL: Adjacency) has been adopted as a TRILL WG document. Thanks, Donald ============================= Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From chopps@rawdofmt.org Tue Jun 25 09:03:27 2013 Return-Path: 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 26FFC11E811D for ; Tue, 25 Jun 2013 09:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmPG4LNs-Bfm for ; Tue, 25 Jun 2013 09:03:26 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id ECE7C11E80F5 for ; Tue, 25 Jun 2013 09:03:25 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so27082617iea.25 for ; Tue, 25 Jun 2013 09:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer:x-gm-message-state; bh=2UYH1O6bymJm2umMPegmKps873PSFm1bg+HGA++XCM8=; b=ICJ6oGPqlYEYERBxfX6vmtkFl3P2J3uLbUdjfacj/UTvw+5ZqypEEjIWZdvPct/w/y x9IWz1e/3xzvznLfFhKgxeZr1M3mu0sbwIy0+DG0qW/F4L0LMLVnEVBN3T9Ab7VuHRBW HeKwfgWrJFXOfbWM4ny0A1GhdITWLwnhAB2QzebHt3f4bdZf4k3RrzE1Gvi7Psz2aY/D sJMce69+6pLGR0xDm0NMpKA78wijGHkLn+l/l//Nm6Zmqjst0p0WVbvJI9cSH/xrRvkP qWQ1GNeJFgoadcyEMgz3KC1/EBp4VblTai36otcVpWdSC9uA89wYWTxDfsMch8jR01H8 KlTg== X-Received: by 10.43.152.210 with SMTP id kx18mr14253829icc.39.1372176205270; Tue, 25 Jun 2013 09:03:25 -0700 (PDT) Received: from [192.168.1.4] (c-69-137-217-47.hsd1.mi.comcast.net. [69.137.217.47]) by mx.google.com with ESMTPSA id p6sm3775191iga.10.2013.06.25.09.03.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Jun 2013 09:03:24 -0700 (PDT) From: Christian Hopps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 25 Jun 2013 12:03:22 -0400 Message-Id: <1D7869EF-8DF0-43A1-A974-20A40E7F5D03@rawdofmt.org> To: "isis-wg@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQloeYER3BXJmbRlAr4lFFPDYLC1ybRvS0skoSV6gGBTKEKg46VL9J9ysABl5XG/3MksmKnp Cc: Christian Hopps , Dave Ward Subject: [Isis-wg] Call for IETF-87 agenda topics X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF IS-IS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 16:03:27 -0000 If you would like an agenda slot for the upcoming isis-wg meeting in = Berlin, please send the chairs a request. Thanks, Chris & Dave.=