draft-ietf-pce-iro-update-00.txt   draft-ietf-pce-iro-update-01.txt 
PCE Working Group D. Dhody PCE Working Group D. Dhody
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Updates: 5440 (if approved) March 6, 2015 Updates: 5440 (if approved) March 6, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: September 7, 2015 Expires: September 7, 2015
Update to Include Route Object (IRO) specification in Path Computation Update to Include Route Object (IRO) specification in Path Computation
Element communication Protocol (PCEP) Element communication Protocol (PCEP)
draft-ietf-pce-iro-update-00 draft-ietf-pce-iro-update-01
Abstract Abstract
During discussions of a document to provide a standard representation During discussions of a document to provide a standard representation
and encoding of Domain-Sequence within the Path Computation Element and encoding of Domain-Sequence within the Path Computation Element
(PCE) communication Protocol (PCEP) for communications between a Path (PCE) communication Protocol (PCEP) for communications between a Path
Computation Client (PCC) and a PCE, or between two PCEs. It was Computation Client (PCC) and a PCE, or between two PCEs. It was
determined that there was a need for clarification with respect to determined that there was a need for clarification with respect to
the ordered nature of the Include Route Object (IRO). the ordered nature of the Include Route Object (IRO).
skipping to change at page 3, line 47 skipping to change at page 3, line 47
objects as strict hops, others consider loose or support both. The objects as strict hops, others consider loose or support both. The
results shown in this survey seems to suggest that most results shown in this survey seems to suggest that most
implementations would be fine with updating [RFC5440] to specify IRO implementations would be fine with updating [RFC5440] to specify IRO
as an ordered list as well as to enable support for Loose bit (L bit) as an ordered list as well as to enable support for Loose bit (L bit)
such that both strict and loose hops could be supported in the IRO. such that both strict and loose hops could be supported in the IRO.
This document thus updates [RFC5440] regarding the IRO specification This document thus updates [RFC5440] regarding the IRO specification
making IRO as an ordered list as well as support for Loose bit (L making IRO as an ordered list as well as support for Loose bit (L
bit). bit).
The content of an IRO object is an ordered list of subobjects The content of an IRO object MUST be an ordered list of subobjects
representing a series of abstract nodes. An abstract node may just representing a series of abstract nodes. An abstract node may just
be a simple abstract node comprising one node or a group of nodes for be a simple abstract node comprising one node or a group of nodes for
example an AS (comprising of multiple hops within the AS) (refer example an AS (comprising of multiple hops within the AS) (refer
[RFC3209] for details). Further each subobject has an attribute [RFC3209] for details). Further, the loose or strict property of the
called 'L bit', which is set if the subobject represents a loose hop. subobject MUST be interpreted based on L bit, which is set if the
subobject represents a loose hop. If the bit is not set, the
If the bit is not set, the subobject represents a strict hop. The subobject represents a strict hop. The interpretation of Loose bit
interpretation of Loose bit (L bit) is as per section 4.3.3.1 of (L bit) is as per section 4.3.3.1 of [RFC3209].
[RFC3209].
3. Other Considerations 3. Other Considerations
Based on the survey, it should be noted that most implementation Based on the survey, it should be noted that most implementation
already support the update in the IRO specification as per this already support the update in the IRO specification as per this
document. The other implementation are expected to make an update to document. The other implementation are expected to make an update to
the IRO procedures. the IRO procedures.
4. Security Considerations 4. Security Considerations
skipping to change at page 6, line 31 skipping to change at page 6, line 31
captures the results. It further list some conclusions and action captures the results. It further list some conclusions and action
points. points.
This document was considered as one possible venue to handle the This document was considered as one possible venue to handle the
proposed action points. proposed action points.
Author's Address Author's Address
Dhruv Dhody Dhruv Dhody
Huawei Technologies Huawei Technologies
Leela Palace Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560008 Bangalore, Karnataka 560037
India India
EMail: dhruv.ietf@gmail.com EMail: dhruv.ietf@gmail.com
 End of changes. 4 change blocks. 
10 lines changed or deleted 9 lines changed or added

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