[要約] RFC 7987は、IS-ISプロトコルの最小残存寿命に関する要件を定義しています。その目的は、ネットワークの安定性と信頼性を向上させるために、IS-ISルーターが最小残存寿命情報を適切に管理することです。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7987 P. Wells
Category: Standards Track Cisco Systems
ISSN: 2070-1721 B. Decraene
Orange
T. Przygienda
Juniper
H. Gredler
RtBrick Inc.
October 2016
IS-IS Minimum Remaining Lifetime
IS-IS最小残存寿命
Abstract
概要
Corruption of the Remaining Lifetime field in a Link State Protocol Data Unit (LSP) can go undetected. In certain scenarios, this may cause or exacerbate flooding storms. It is also a possible denial-of-service attack vector. This document defines a backwards-compatible solution to this problem.
リンク状態プロトコルデータユニット（LSP）の[Remaining Lifetime]フィールドの破損が検出されない場合があります。特定のシナリオでは、これにより洪水嵐が発生または悪化する場合があります。また、サービス拒否攻撃の可能性もあります。このドキュメントでは、この問題に対する下位互換性のあるソリューションを定義しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7987.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7987で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Problem Statement ...............................................3
1.1. Requirements Language ......................................4
2. Solution ........................................................4
3. Deployment Considerations .......................................5
3.1. Inconsistent Values for MaxAge .............................5
3.2. Reporting Corrupted Lifetime ...............................6
3.3. Impact of Delayed LSP Purging ..............................7
4. Security Considerations .........................................7
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................8
Acknowledgements ...................................................8
Contributors .......................................................8
Authors' Addresses .................................................9
[ISO10589] defines the format of a Link State PDU (LSP) that includes a Remaining Lifetime field. This field is set by the originator based on local configuration and then decremented by all systems once the entry is stored in their LSP Database (LSPDB) consistent with the passing of time. This allows all Intermediate Systems (ISs) to age out the LSP at approximately the same time.
[ISO10589]は、Remaining Lifetimeフィールドを含むLink State PDU（LSP）のフォーマットを定義します。このフィールドは、ローカルの構成に基づいて発信者によって設定され、時間の経過に合わせてエントリがLSPデータベース（LSPDB）に格納されると、すべてのシステムによってデクリメントされます。これにより、すべての中間システム（IS）がほぼ同時にLSPを期限切れにすることができます。
Each LSP also has a checksum field to allow receiving systems to detect errors that may have occurred during transmission. [ISO10589] mandates that the checksum is calculated by the originator of the LSP and cannot be modified by other routers. Therefore, the Remaining Lifetime is deliberately excluded from the checksum calculation. In cases where cryptographic authentication is included in an LSP ([RFC5304] or [RFC5310]), the Remaining Lifetime field is also excluded from the hash calculation. If the Remaining Lifetime field gets corrupted during flooding, this corruption is therefore undetectable. The consequences of such corruption depend upon how the Remaining Lifetime is altered.
各LSPにはチェックサムフィールドもあり、受信システムは送信中に発生した可能性のあるエラーを検出できます。 [ISO10589]は、チェックサムがLSPの発信者によって計算され、他のルーターによって変更できないことを義務付けています。したがって、残存寿命は意図的にチェックサム計算から除外されます。暗号認証がLSP（[RFC5304]または[RFC5310]）に含まれている場合、Remaining Lifetimeフィールドもハッシュ計算から除外されます。フラッディング中に[残りのライフタイム]フィールドが破損した場合、この破損は検出できません。このような腐敗の結果は、残存寿命がどのように変更されるかに依存します。
In cases where the Remaining Lifetime becomes larger than the originator intended, the impact is benign. As the originator is responsible for refreshing the LSP before it ages out, a new version of the LSP will be generated before the LSP ages out, so no harm is done.
Remaining Lifetimeがオリジネーターが意図したよりも長くなる場合、影響は無害です。発信者はLSPが期限切れになる前に更新する責任があるため、LSPが期限切れになる前に新しいバージョンのLSPが生成されるため、害はありません。
In cases where the Remaining Lifetime field becomes smaller than the originator intended, the LSP may age out prematurely (i.e., before the originator refreshes the LSP). This has two negative consequences:
Remaining Lifetimeフィールドがオリジネーターが意図したよりも小さくなる場合、LSPは時期尚早に（つまり、オリジネーターがLSPを更新する前に）期限切れになることがあります。これには2つのマイナスの影響があります。
1. The LSP will be purged by an IS when the Remaining Lifetime expires. This will cause a temporary loss of reachability to destinations impacted by the content of that LSP.
1. 残りのライフタイムが期限切れになると、ISによってLSPが削除されます。これにより、そのLSPのコンテンツによって影響を受ける宛先への到達可能性が一時的に失われます。
2. Unnecessary LSP flooding will occur as a result of the premature purge and subsequent regeneration/flooding of a new version of the LSP by the originator.
2. 不要なLSPフラッディングは、オリジネーターによる早期のパージと、それに続く新しいバージョンのLSPの再生/フラッディングの結果として発生します。
If the corrupted Remaining Lifetime is only modestly shorter than the lifetime assigned by the originator, the negative impacts are also modest. If, however, the corrupted Remaining Lifetime becomes very small, then the negative impacts can become significant, especially in cases where the cause of the corruption is persistent so that the cycle repeats itself frequently.
破損したRemaining Lifetimeが、オリジネーターによって割り当てられたライフタイムよりもほんの少しだけ短い場合、マイナスの影響も控えめです。ただし、破損した残存寿命が非常に短くなると、特に破損の原因が持続し、サイクルが頻繁に繰り返される場合に、悪影響が大きくなる可能性があります。
A backwards-compatible solution to this problem is defined in the following sections.
この問題に対する下位互換性のあるソリューションは、次のセクションで定義されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
As discussed in the previous section, the problematic case is when the Remaining Lifetime is corrupted and becomes much smaller than it should be. The goal of the solution is then to prevent premature purging.
前のセクションで説明したように、問題となるケースは、残りのライフタイムが破損し、本来のサイズよりも大幅に小さくなる場合です。ソリューションの目標は、時期尚早なパージを防ぐことです。
Under normal circumstances, updates to an LSP -- including purging, if appropriate -- are the responsibility of the originator of the LSP. There is a maximum time between generations of a given LSP. Once this time has expired, it is the responsibility of the originator to refresh the LSP (i.e., issue a new version with a higher sequence number) even if the contents of the LSP have not changed. [ISO10589] defines maximumLSPGenerationInterval to be sufficiently less than the maximum lifetime of an LSP so that the new version can be flooded network wide before the old version ages out on any IS.
通常の状況では、LSPの更新（適切な場合はパージを含む）は、LSPの作成者の責任です。特定のLSPの生成の間には最大時間があります。この時間が経過すると、LSPの内容が変更されていなくても、LSPを更新する（つまり、シーケンス番号が大きい新しいバージョンを発行する）のは作成者の責任です。 [ISO10589]は、LSPGenerationIntervalをLSPの最大存続期間よりも十分短くなるように定義しているため、ISで古いバージョンが期限切れになる前に、新しいバージョンをネットワーク全体にフラッディングできます。
[ISO10589] defines two cases where a system other than the originator of an LSP is allowed to purge an LSP:
[ISO10589]は、LSPの発信者以外のシステムがLSPをパージできる2つのケースを定義しています。
1. The LSP ages out. This should only occur if the originating IS is no longer reachable and therefore is unable to update the LSP.
1. LSPは期限切れになります。これは、元のISに到達できなくなったためにLSPを更新できない場合にのみ発生します。
2. There is a Designated Intermediate System (DIS) change on a LAN. The pseudonode LSPs generated by the previous DIS are no longer required and may be purged by the new DIS.
2. LANに指定中間システム（DIS）の変更があります。以前のDISによって生成された疑似ノードLSPは不要になり、新しいDISによって削除される場合があります。
In both of these cases, purging is not necessary for correct operation of the protocol. It is provided as an optimization to remove stale entries from the LSPDB.
これらのどちらの場合でも、プロトコルを正しく動作させるためにパージする必要はありません。 LSPDBから古いエントリを削除するための最適化として提供されています。
In cases where the Remaining Lifetime in a received LSP has been corrupted and is smaller than the Remaining Lifetime at the originating node, when the Remaining Lifetime expires on the receiving node, it can appear as if the originating IS has failed to regenerate the LSP before it ages out (case #1 above). To prevent this from having a negative impact, a modest change to the storage of "new" LSPs in the LSPDB is specified.
受信したLSPの残りのライフタイムが破損していて、元のノードの残りのライフタイムよりも短い場合、残りのライフタイムが受信ノードで期限切れになると、元のISがLSPの再生成に失敗したように見えることがあります。古くなります（上記のケース1）。これが悪影響を及ぼさないようにするために、LSPDB内の「新しい」LSPのストレージに対する適度な変更が指定されています。
Section 7.3.16 of [ISO10589] defines the rules to determine whether a received LSP is older, the same, or newer than the copy of the same LSP in the receiver's LSPDB. The key elements are:
[ISO10589]のセクション7.3.16は、受信したLSPがレシーバーのLSPDB内の同じLSPのコピーより古いか、同じか、または新しいかを決定するためのルールを定義しています。主な要素は次のとおりです。
o Higher sequence numbers are newer.
o シーケンス番号が大きいほど新しいです。
o If sequence numbers are the same, an LSP with a zero Remaining Lifetime (a purged LSP) is newer than the same LSP with a non-zero Remaining Lifetime.
o シーケンス番号が同じ場合、残存寿命がゼロのLSP（パージされたLSP）は、残存寿命がゼロでない同じLSPよりも新しいです。
o If both the received and local copy of the LSP have a non-zero Remaining Lifetime, they are considered the same even if the Remaining Lifetimes differ.
o LSPの受信コピーとローカルコピーの両方にゼロ以外の残存ライフタイムがある場合、残存ライフタイムが異なっていても、それらは同じであると見なされます。
Section 7.3.15.1.e(1) of [ISO10589] defines the actions to take on receipt of an LSP generated by another IS that is newer than the local copy and has a non-zero Remaining Lifetime. An additional action is defined by this document:
[ISO10589]のセクション7.3.15.1.e（1）は、ローカルコピーよりも新しい、残りのライフタイムがゼロでない別のISによって生成されたLSPの受信時に実行するアクションを定義しています。このドキュメントでは、追加のアクションを定義しています。
vi. If the Remaining Lifetime of the new LSP is less than MaxAge, it is set to MaxAge.
vi。新しいLSPの残りのライフタイムがMaxAge未満の場合、MaxAgeに設定されます。
This additional action ensures that no matter what value of Remaining Lifetime is received, a system other than the originator of an LSP will never purge the LSP until the LSP has existed in the database for at least MaxAge.
この追加のアクションにより、Remaining Lifetimeのどの値が受信されても、LSPがデータベースに少なくともMaxAge存在するまで、LSPのオリジネーター以外のシステムはLSPをパージしません。
It is important to note that no change is proposed for handling the receipt of purged LSPs. The rules specified in Section 7.3.15.1.b of [ISO10589] still apply, i.e., an LSP received with a zero Remaining Lifetime is still considered newer than a matching LSP with a non-zero Remaining Lifetime. Therefore, the changes proposed here will not result in LSPDB inconsistency among routers in the network.
パージされたLSPの受信を処理するための変更は提案されていないことに注意することが重要です。 [ISO10589]のセクション7.3.15.1.bで指定されたルールは引き続き適用されます。つまり、残存寿命がゼロのLSPは、残存寿命がゼロでない対応するLSPよりも新しいと見なされます。したがって、ここで提案された変更によって、ネットワーク内のルーター間でLSPDBが不整合になることはありません。
This section discusses some possible deployment issues for this protocol extension.
このセクションでは、このプロトコル拡張の展開に関するいくつかの問題について説明します。
[ISO10589] defines MaxAge (the maximum value for the Remaining Lifetime in an LSP) as an architectural constant of 20 minutes (1200 seconds). However, in practice, implementations have supported allowing this value to be configurable. The common intent of a configurable value is to support longer lifetimes than the default, thus reducing the periodic regeneration of LSPs in the absence of topology changes. See a discussion of this point in [RFC3719]. It is therefore possible for the value of MaxAge on the IS that originates an LSP to be higher or lower than the value of MaxAge on the ISs that receive the LSP.
[ISO10589]は、MaxAge（LSPの残りのライフタイムの最大値）を20分のアーキテクチャ定数（1200秒）として定義しています。ただし、実際には、実装はこの値を構成可能にすることをサポートしています。設定可能な値の一般的な目的は、デフォルトよりも長いライフタイムをサポートすることです。これにより、トポロジが変更されていない場合のLSPの定期的な再生成が削減されます。この点についての議論は[RFC3719]で見てください。したがって、LSPを発信するIS上のMaxAgeの値が、LSPを受信するIS上のMaxAgeの値よりも高いまたは低い可能性があります。
If the value of MaxAge of the IS that originated the LSP is smaller than the value of MaxAge of the receiver of an LSP, then setting the Remaining Lifetime of the received LSP to the local value of MaxAge will ensure that it is not purged prematurely. However, if the value of MaxAge on the receiver is less than that of the originator, then it is still possible to have an LSP purged prematurely when using the extension defined in the previous section. Implementors of this extension may wish to protect against this case by making the value to which the Remaining Lifetime is set under the conditions described in the previous section configurable. If that is done, the configured value MUST be greater than or equal to the locally configured value of MaxAge.
LSPを生成したISのMaxAgeの値がLSPのレシーバーのMaxAgeの値よりも小さい場合は、受信したLSPの残りのライフタイムをMaxAgeのローカル値に設定することで、早期にパージされないようにします。ただし、レシーバーのMaxAgeの値がオリジネーターの値よりも小さい場合でも、前のセクションで定義された拡張機能を使用すると、LSPが時期尚早にパージされる可能性があります。この拡張機能の実装者は、前のセクションで説明した条件下で残りのライフタイムが設定される値を構成可能にすることによって、このケースから保護することを望む場合があります。その場合、構成された値は、ローカルで構成されたMaxAgeの値以上である必要があります。
Reporting reception of an LSP with a possible corrupt Remaining Lifetime field can be useful in identifying a problem in the network. In order to minimize the reports of false positives, the following algorithm SHOULD be used in determining whether the Remaining Lifetime in the received LSP is possibly corrupt:
破損している可能性のある残存ライフタイムフィールドを含むLSPの受信を報告すると、ネットワークの問題を特定するのに役立ちます。誤検知のレポートを最小限に抑えるために、次のアルゴリズムを使用して、受信したLSPの残りのライフタイムが破損している可能性があるかどうかを判断する必要があります。
o The LSP has passed all acceptance tests as specified in Section 7.3.15.1 of [ISO10589].
o [ISO10589]のセクション7.3.15.1で指定されているように、LSPはすべての受け入れテストに合格しています。
o The LSP is newer than the copy in the local LSPDB (including the case of not being present in the LSPDB).
o LSPがローカルLSPDB内のコピーより新しい（LSPDBに存在しない場合を含む）。
o The Remaining Lifetime in the received LSP is less than ZeroAgeLifetime.
o 受信したLSPの残りのライフタイムは、ZeroAgeLifetime未満です。
o The adjacency to the neighbor from which the LSP is received has been up for a minimum of ZeroAgeLifetime.
o LSPの受信元であるネイバーへの隣接は、少なくともZeroAgeLifetimeの間アップしています。
In such a case, an IS SHOULD generate a CorruptRemainingLifetime event.
そのような場合、ISはCorruptRemainingLifetimeイベントを生成する必要があります（SHOULD）。
Note that it is not possible to guarantee that all cases of a corrupt Remaining Lifetime will be detected using the above algorithm. It is also not possible to guarantee that all CorruptRemainingLifetime events reported using the above algorithm are valid. As a diagnostic aid, an implementation MAY wish to retain the value of the Remaining Lifetime received when the LSP was added to the LSPDB.
上記のアルゴリズムを使用して、Remaining Lifetimeの破損がすべて検出されることを保証することはできないことに注意してください。上記のアルゴリズムを使用して報告されたすべてのCorruptRemainingLifetimeイベントが有効であることを保証することもできません。診断支援として、LSPがLSPDBに追加されたときに受信したRemaining Lifetimeの値を保持したい場合があります。
The extensions defined in this document may result in retaining an LSP longer than its original lifetime. In order for this to occur, the scheduled refresh of the LSP by the originator of the LSP must fail to occur -- this implies that the originator is no longer reachable. In such a case, its neighbors will update their own LSPs to report the loss of connectivity to the originator. [ISO10589] specifies that LSPs from a node that is unreachable (failure of the two-way connectivity check) will not be used. Note that this behavior applies to ALL information in the set of LSPs from such a node.
このドキュメントで定義されている拡張により、LSPが元の寿命よりも長く維持される場合があります。これが発生するためには、LSPのオリジネーターによるLSPのスケジュールされた更新が失敗する必要があります-これは、オリジネーターに到達できなくなったことを意味します。このような場合、そのネイバーは独自のLSPを更新して、発信者への接続の喪失を報告します。 [ISO10589]は、到達不能（双方向接続チェックの失敗）のノードからのLSPが使用されないことを指定します。この動作は、そのようなノードからのLSPセット内のすべての情報に適用されることに注意してください。
Retention of stale LSPs therefore has no negative side effects other than requiring additional memory for the LSPDB. In networks where a combination of pathological behaviors (e.g., LSP corruption and frequent resetting of nodes in the network) is seen, this could lead to a large number of stale LSPs being retained, but such networks are already compromised.
したがって、古くなったLSPを保持しても、LSPDBに追加のメモリを必要とする以外に悪影響はありません。病理学的動作の組み合わせが見られるネットワーク（LSPの破損やネットワーク内のノードの頻繁なリセットなど）では、多数の古いLSPが保持される可能性がありますが、そのようなネットワークは既に侵害されています。
The ability to introduce corrupt LSPs is not altered by the rules defined in this document. Use of authentication as defined in [RFC5304] and [RFC5310] prevents such LSPs from being intentionally introduced. A man-in-the-middle attack that modifies an existing LSP by changing the Remaining Lifetime to a small value can cause premature purges even in the presence of cryptographic authentication. The mechanisms defined in this document prevent such an attack from being effective.
破損したLSPを導入する機能は、このドキュメントで定義されているルールによって変更されません。 [RFC5304]と[RFC5310]で定義されている認証を使用すると、そのようなLSPが意図的に導入されるのを防ぎます。 Remaining Lifetimeを小さい値に変更して既存のLSPを変更する中間者攻撃では、暗号化認証が存在していても、早期のパージが発生する可能性があります。このドキュメントで定義されているメカニズムは、このような攻撃の効果を防ぎます。
[ISO10589] International Organization for Standardization, "Information technology -- Telecommunications and information exchange between systems -- Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/IEC 10589:2002, Second Edition, November 2002.
[ISO10589]国際標準化機構、「情報技術-システム間のテレコミュニケーションおよび情報交換-コネクションレスモードのネットワークサービス（ISOを提供するためのプロトコルと組み合わせて使用するための中間システムから中間システムのドメイン内ルーティング情報交換プロトコル8473） "、ISO / IEC 10589：2002、Second Edition、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5304] Li、T。およびR. Atkinson、「IS-IS Cryptographic Authentication」、RFC 5304、DOI 10.17487 / RFC5304、2008年10月、<http://www.rfc-editor.org/info/rfc5304>。
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic Authentication", RFC 5310, DOI 10.17487/RFC5310, February 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5310] Bhatia、M.、Manral、V.、Li、T.、Atkinson、R.、White、R。、およびM. Fanto、「IS-IS Generic Cryptographic Authentication」、RFC 5310、DOI 10.17487 / RFC5310、 2009年2月、<http://www.rfc-editor.org/info/rfc5310>。
[PROB-STATEMENT] Decraene, B. and C. Schmitz, "IS-IS LSP lifetime corruption - Problem Statement", Work in Progress, draft-decraene-isis-lsp-lifetime-problem-statement-02, July 2016.
[PROB-STATEMENT] Decraene、B。およびC. Schmitz、「IS-IS LSPのライフタイム破損-問題ステートメント」、進行中の作業、draft-decraene-isis-lsp-lifetime-problem-statement-02、2016年7月。
[RFC3719] Parker, J., Ed., "Recommendations for Interoperable Networks using Intermediate System to Intermediate System (IS-IS)", RFC 3719, DOI 10.17487/RFC3719, February 2004, <http://www.rfc-editor.org/info/rfc3719>.
[RFC3719] Parker、J。、編、「Intermediate System to Intermediate System（IS-IS）を使用した相互運用ネットワークの推奨事項」、RFC 3719、DOI 10.17487 / RFC3719、2004年2月、<http：//www.rfc-editor .org / info / rfc3719>。
Acknowledgements
謝辞
The problem statement in [PROB-STATEMENT] motivated this work.
[PROB-STATEMENT]の問題ステートメントがこの作業の動機となりました。
Contributors
貢献者
The following individual contributed substantially to the content of this document and should be considered a co-author:
次の個人は、このドキュメントの内容に実質的に貢献しており、共著者と見なされます。
Stefano Previdi Cisco Systems Email: sprevidi@cisco.com
Stefano PrevidiシスコシステムズEメール：sprevidi@cisco.com
Authors' Addresses
著者のアドレス
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States of America
Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、カリフォルニア州95035アメリカ合衆国
Email: ginsberg@cisco.com
Paul Wells Cisco Systems 170 W. Tasman Dr. San Jose, CA 95035 United States of America
Paul Wells Cisco Systems 170 W. Tasman Dr. San Jose、CA 95035アメリカ合衆国
Email: pauwells@cisco.com
Bruno Decraene Orange 44 avenue de la Republique, CS 50010 92326 Chatillon Cedex 92794 France
Bruno Decraene Orange 44 avenue de la Republique、CS 50010 92326 Chatillon Cedex 92794 France
Email: bruno.decraene@orange.com
Tony Przygienda Juniper 1137 Innovation Way Sunnyvale, CA 94089 United States of America
Tony Przygienda Juniper 1137 Innovation Wayサニーベール、カリフォルニア州94089アメリカ合衆国
Email: prz@juniper.net
Hannes Gredler RtBrick Inc.
Hannes Gredler RtBrick Inc.
Email: hannes@rtbrick.com