draft-ietf-pce-pcep-domain-sequence-04.txt   draft-ietf-pce-pcep-domain-sequence-05.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft U. Palle Internet-Draft U. Palle
Intended status: Experimental Huawei Technologies Intended status: Experimental Huawei Technologies
Expires: July 11, 2014 R. Casellas Expires: January 2, 2015 R. Casellas
CTTC CTTC
January 7, 2014 July 1, 2014
Standard Representation Of Domain-Sequence Standard Representation Of Domain-Sequence
draft-ietf-pce-pcep-domain-sequence-04 draft-ietf-pce-pcep-domain-sequence-05
Abstract Abstract
The ability to compute shortest constrained Traffic Engineering Label The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains has been Generalized MPLS (GMPLS) networks across multiple domains has been
identified as a key requirement. In this context, a domain is a identified as a key requirement. In this context, a domain is a
collection of network elements within a common sphere of address collection of network elements within a common sphere of address
management or path computational responsibility such as an Interior management or path computational responsibility such as an Interior
Gateway Protocol (IGP) area or an Autonomous Systems (AS). This Gateway Protocol (IGP) area or an Autonomous Systems (AS). This
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 11, 2014. This Internet-Draft will expire on January 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 19 skipping to change at page 3, line 19
7.1. Control of Function and Policy . . . . . . . . . . . . . 29 7.1. Control of Function and Policy . . . . . . . . . . . . . 29
7.2. Information and Data Models . . . . . . . . . . . . . . . 29 7.2. Information and Data Models . . . . . . . . . . . . . . . 29
7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 29
7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 29
7.5. Requirements On Other Protocols . . . . . . . . . . . . . 30 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 30
7.6. Impact On Network Operations . . . . . . . . . . . . . . 30 7.6. Impact On Network Operations . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Sample Text for the IRO survey . . . . . . . . . . . 33
1. Introduction 1. Introduction
A PCE may be used to compute end-to-end paths across multi-domain A PCE may be used to compute end-to-end paths across multi-domain
environments using a per-domain path computation technique [RFC5152]. environments using a per-domain path computation technique [RFC5152].
The so called backward recursive path computation (BRPC) mechanism The so called backward recursive path computation (BRPC) mechanism
[RFC5441] defines a PCE-based path computation procedure to compute [RFC5441] defines a PCE-based path computation procedure to compute
inter-domain constrained (G)MPLS TE LSPs. However, both per-domain inter-domain constrained (G)MPLS TE LSPs. However, both per-domain
and BRPC techniques assume that the sequence of domains to be crossed and BRPC techniques assume that the sequence of domains to be crossed
from source to destination is known, either fixed by the network from source to destination is known, either fixed by the network
skipping to change at page 9, line 42 skipping to change at page 9, line 42
Area-Len: Variable (Length of the actual (non-padded) IS-IS Area Area-Len: Variable (Length of the actual (non-padded) IS-IS Area
Identifier in octets; Valid values are from 2 to 11 inclusive). Identifier in octets; Valid values are from 2 to 11 inclusive).
Reserved: Zero at transmission, ignored at receipt. Reserved: Zero at transmission, ignored at receipt.
IS-IS Area Id: The variable-length IS-IS area identifier. Padded IS-IS Area Id: The variable-length IS-IS area identifier. Padded
with trailing zeroes to a four-byte boundary. with trailing zeroes to a four-byte boundary.
3.4.2. Option (A): New IRO Object Type 3.4.2. Option (A): New IRO Object Type
[Editor's Note: Currently there is a discussion going on in the
working group (WG) to evaluate if the existing IRO as per [RFC5440]
can be considered to be ordered in nature. It has been suggested
that a poll could be issued to gather feedback from the current
implementations, based on which WG could decide to clarify the
position on IRO. The following section would be revaluated and
updated based on that decision. See Appendix A for the sample survey
text.]
[RFC5440] in its description of IRO does not require the subobjects [RFC5440] in its description of IRO does not require the subobjects
to be in a given particular order. When considering a Domain- to be in a given particular order. When considering a Domain-
Sequence, the domain relative ordering is a basic criterion and, as Sequence, the domain relative ordering is a basic criterion and, as
such, this option suggest a new IRO object type. such, this option suggest a new IRO object type.
IRO Object-Class is 10. IRO Object-Class is 10.
IRO Object-Type is TBD. (2 suggested value to IANA) IRO Object-Type is TBD. (2 suggested value to IANA)
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 32, line 10 skipping to change at page 32, line 10
[RFC6805] King, D. and A. Farrel, "The Application of the Path [RFC6805] King, D. and A. Farrel, "The Application of the Path
Computation Element Architecture to the Determination of a Computation Element Architecture to the Determination of a
Sequence of Domains in MPLS and GMPLS", RFC 6805, November Sequence of Domains in MPLS and GMPLS", RFC 6805, November
2012. 2012.
[PCE-P2MP-PROCEDURES] [PCE-P2MP-PROCEDURES]
Zhao, Q., Dhody, D., Ali, Z., Saad,, T., Sivabalan,, S., Zhao, Q., Dhody, D., Ali, Z., Saad,, T., Sivabalan,, S.,
and R. Casellas, "PCE-based Computation Procedure To and R. Casellas, "PCE-based Computation Procedure To
Compute Shortest Constrained P2MP Inter-domain Traffic Compute Shortest Constrained P2MP Inter-domain Traffic
Engineering Label Switched Paths (draft-ietf-pce-pcep- Engineering Label Switched Paths (draft-ietf-pce-pcep-
inter-domain-p2mp-procedures)", July 2013. inter-domain-p2mp-procedures)", June 2014.
[PCEP-MIB] [PCEP-MIB]
Koushik, A., Emile, S., Zhao, Q., King, D., and J. Koushik, A., Emile, S., Zhao, Q., King, D., and J.
Hardwick, "PCE communication protocol(PCEP) Management Hardwick, "PCE communication protocol(PCEP) Management
Information Base", July 2013. Information Base", April 2014.
[PCE-P2MP-PER-DEST] [PCE-P2MP-PER-DEST]
Dhody, D., Palle, U., and V. Kondreddy, "Supporting Dhody, D., Palle, U., and V. Kondreddy, "Supporting
explicit inclusion or exclusion of abstract nodes for a explicit inclusion or exclusion of abstract nodes for a
subset of P2MP destinations in Path Computation Element subset of P2MP destinations in Path Computation Element
Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp- Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp-
per-destination)", October 2013. per-destination)", March 2014.
[DOMAIN-SUBOBJ] [DOMAIN-SUBOBJ]
Dhody, D., Palle, U., Kondreddy, V., and R. Casellas, Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
"Domain Subobjects for Resource ReserVation Protocol - "Domain Subobjects for Resource ReserVation Protocol -
Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te- Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te-
domain-subobjects)", January 2014. domain-subobjects)", July 2014.
[ISO10589] [ISO10589]
ISO, "Intermediate system to Intermediate system routing ISO, "Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, 1992. Service (ISO 8473)", ISO/IEC 10589:2002, 1992.
Appendix A. Sample Text for the IRO survey
During discussion of draft-ietf-pce-pcep-domain-sequence-04, it has been
noted that RFC5440 does not define whether the sub-objects in the IRO
are ordered or unordered.
We would like to do an informal and *confidential* survey of current
implementations, to help clarify this situation.
1. IRO Encoding
a. Does your implementation construct IRO?
b. If your answer to part (a) is Yes, does your implementation
construct the IRO as an ordered list always, sometimes or never?
c. If your answer to part (b) is Sometimes, what criteria do you use
to decide if the IRO is an ordered or unordered list?
d. If your answer to part (b) is Always or Sometimes, does your
implementation construct the IRO as a sequence of strict hops
or as a sequence of loose hops?
2. IRO Decoding
a. Does your implementation decode IRO?
b. If your answer to part (a) is Yes, does your implementation
interpret the decoded IRO as an ordered list always, sometimes
or never?
c. If your answer to part (b) is Sometimes, what criteria do you use
to decide if the IRO is an ordered or unordered list?
d. If your answer to part (b) is Always or Sometimes, does your
implementation interpret the IRO as a sequence of strict hops
or as a sequence of loose hops?
3. Impact
a. Will there be an impact to your implementation if RFC 5440 is
updated to state that the IRO is an ordered list?
b. Will there be an impact to your implementation if RFC 5440 is
updated to state that the IRO is an unordered list?
c. If RFC 5440 is updated to state that the IRO is an ordered list,
will there be an impact to your implementation if RFC 5440 is also
updated to allow IRO sub-objects to use the loose bit (L-bit)?
4. Respondents
a. Are you a Vendor/Research Lab/Software House/Other (please
specify)?
b. If your answer to part (a) is Vendor, is the implementation for a
shipping product, product under development or a prototype?
Authors' Addresses Authors' Addresses
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
Udayasree Palle Udayasree Palle
Huawei Technologies Huawei Technologies
Leela Palace Leela Palace
Bangalore, Karnataka 560008 Bangalore, Karnataka 560008
INDIA INDIA
EMail: udayasree.palle@huawei.com EMail: udayasree.palle@huawei.com
Ramon Casellas Ramon Casellas
CTTC CTTC
 End of changes. 12 change blocks. 
8 lines changed or deleted 77 lines changed or added

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