draft-ietf-ccamp-lsp-hierarchy-bis-05.txt   draft-ietf-ccamp-lsp-hierarchy-bis-06.txt 
Network Working Group K. Shiomoto (Ed.) Network Working Group K. Shiomoto (Ed.)
Internet Draft NTT Internet Draft NTT
Updates: 3477, 4206 A. Farrel (Ed.) Updates: 3477, 4206 A. Farrel (Ed.)
Proposed Category: Proposed Standard Old Dog Consulting Proposed Category: Proposed Standard Old Dog Consulting
Created: October 16, 2008 Created: December 9, 2008
Expires: April 16, 2009 Expires: June 9, 2009
Procedures for Dynamically Signaled Procedures for Dynamically Signaled
Hierarchical Label Switched Paths Hierarchical Label Switched Paths
draft-ietf-ccamp-lsp-hierarchy-bis-05.txt draft-ietf-ccamp-lsp-hierarchy-bis-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with
applicable patent or other IPR claims of which he or she is aware the provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
skipping to change at page 4, line 42 skipping to change at page 4, line 42
switching type to be included (stitched) as hops in an end-to-end switching type to be included (stitched) as hops in an end-to-end
LSP. The stitching LSP (S-LSP) is used in the control plane in the LSP. The stitching LSP (S-LSP) is used in the control plane in the
same way as an H-LSP, but in the data plane the LSPs are stitched so same way as an H-LSP, but in the data plane the LSPs are stitched so
that there is no label stacking or nesting of technologies. Thus, an that there is no label stacking or nesting of technologies. Thus, an
S-LSP must be of the same switching technology as the end-to-end LSP S-LSP must be of the same switching technology as the end-to-end LSP
that it facilitates. that it facilitates.
1.1.3. Private Links 1.1.3. Private Links
An H-LSP or S-LSP can be used as a private link. Such links are known An H-LSP or S-LSP can be used as a private link. Such links are known
by their end-points, but are not more widely known. They can be used by their end-points, but are not more widely known and are not
to carry traffic between the end-points, but are not usually used to advertised by routing protocols. They can be used to carry traffic
carry traffic that is going beyond the egress of the LSP. between the end-points, but are not usually used to carry traffic
that is going beyond the egress of the LSP.
1.1.4. Routing Adjacencies 1.1.4. Routing Adjacencies
A routing adjacency is formed between two IGP-speakers that are A routing adjacency is formed between two IGP-speakers that are
logically adjacent. In this sense, 'logically adjacent' means that logically adjacent. In this sense, 'logically adjacent' means that
the routers have a protocol tunnel between them through which they the routers have a protocol tunnel between them through which they
can exchange routing protocol messages. The tunnel is also usually can exchange routing protocol messages. The tunnel is also usually
available for carrying IP data although a distinction should be made available for carrying IP data although a distinction should be made
in GMPLS networks between data plane traffic and control plane in GMPLS networks between data plane traffic and control plane
traffic. traffic.
skipping to change at page 10, line 44 skipping to change at page 10, line 44
2.2. LSP Usage Indication 2.2. LSP Usage Indication
The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions
field to say how the LSP is to be used. The following categories are field to say how the LSP is to be used. The following categories are
supported: supported:
- LSP is used as an advertised TE link - LSP is used as an advertised TE link
- LSP is used to form a routing adjacency - LSP is used to form a routing adjacency
- LSP is used to form an advertised TE link and a routing adjacency - LSP is used to form an advertised TE link and a routing adjacency
- LSP forms a private link and is not advertised - LSP forms a private link and is not advertised
- The LSP is used as part of a link bundle
- The LSP is used as a hierarchical LSP or a stitching segment
2.3. IGP Instance Identification 2.3. IGP Instance Identification
An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to
identify the IGP instance into which the link formed by the LSP is to identify the IGP instance into which the link formed by the LSP is to
be advertised. If the TLV is absent and the link is to be advertised be advertised. If the TLV is absent and the link is to be advertised
as indicated by the Actions field, the link is advertised in the same as indicated by the Actions field, the link is advertised in the same
instance of the IGP as was used to advertise the TE links it instance of the IGP as was used to advertise the TE links it
traverses. traverses.
skipping to change at page 24, line 44 skipping to change at page 24, line 44
11 = Link address type or family not supported [This.doc] 11 = Link address type or family not supported [This.doc]
12 = IGP instance unknown [This.doc] 12 = IGP instance unknown [This.doc]
13 = IGP instance advertisement not allowed by policy [This.doc] 13 = IGP instance advertisement not allowed by policy [This.doc]
14 = Component link identifier not valid [This.doc] 14 = Component link identifier not valid [This.doc]
15 = Unsupported component link identifier address [This.doc] 15 = Unsupported component link identifier address [This.doc]
family family
16 = Component link identifier missing [This.doc] 16 = Component link identifier missing [This.doc]
6. Acknowledgements 6. Acknowledgements
The authors would like to thank John Drake, Yakov Rekhter, and Igor The authors would like to thank John Drake, Yakov Rekhter, Igor
Bryskin for their valuable discussions and comments. Bryskin, and Lucy Yong for their valuable discussions and comments.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
skipping to change at page 27, line 41 skipping to change at page 27, line 41
United States of America United States of America
Email: arthi@juniper.net Email: arthi@juniper.net
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive 2000 Innovation Drive
Kanata, Ontario, K2K 3E8 Kanata, Ontario, K2K 3E8
Canada. Canada.
EMail: zali@cisco.com EMail: zali@cisco.com
Intellectual Property Statement Full Copyright Statement
The IETF takes no position regarding the validity or scope of any Copyright (c) 2008 IETF Trust and the persons identified as the
Intellectual Property Rights or other rights that might be claimed to document authors. All rights reserved.
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any This document is subject to BCP 78 and the IETF Trust's Legal
assurances of licenses to be made available, or the result of an Provisions Relating to IETF Documents
attempt made to obtain a general license or permission for the use of (http://trustee.ietf.org/license-info) in effect on the date of
such proprietary rights by implementers or users of this publication of this document. Please review these documents
specification can be obtained from the IETF on-line IPR repository at carefully, as they describe your rights and restrictions with respect
http://www.ietf.org/ipr. to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at any standard or specification contained in an IETF Document. Please
ietf-ipr@ietf.org. address the information to the IETF at ietf-ipr@ietf.org.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the The definitive version of an IETF Document is that published by, or
rights, licenses and restrictions contained in BCP 78, and except as under the auspices of, the IETF. Versions of IETF Documents that are
set forth therein, the authors retain all their rights. published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
This document and the information contained herein are provided on an For the avoidance of doubt, each Contributor to the IETF Standards
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS Process licenses each Contribution that he or she makes as part of
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND the IETF Standards Process to the IETF Trust pursuant to the
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS provisions of RFC 5378. No language to the contrary, or terms,
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF conditions or rights that differ from or are inconsistent with the
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED rights and licenses granted under RFC 5378, shall have any effect and
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 12 change blocks. 
34 lines changed or deleted 59 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/