Re: [Gen-art] Gen-art] Review: draft-ietf-pce-pcep-domain-sequence

Mon, 02 Nov 2015 20:15:13 -0800 

Hi Julien, All,

So now we have - (and thanks for bearing with me, as we get there...)

   IGP Area subobjects in the XRO are local to the current AS.  In case
   of multi-AS path computation to exclude an IGP area in a different
   AS, IGP Area subobject should be part of Explicit Exclusion Route
   Subobject (EXRS) in the IRO to specify the AS in which the IGP area
   is to be excluded.  Further policy may be applied to prune/ignore
   Area subobjects in XRO after "current AS" change during path
   computation.

I have also attached the diff of the working copy to show the GenArt and IANA 
review changes so far. 

Regards,
Dhruv

> -----Original Message-----
> From: Julien Meuric [mailto:[email protected]]
> Sent: 03 November 2015 00:57
> To: Dhruv Dhody; Joel Halpern Direct; Dhruv Dhody
> Cc: A. Jean Mahoney; General Area Review Team; draft-ietf-pce-pcep-
> [email protected]
> Subject: Re: Gen-art] Review: draft-ietf-pce-pcep-domain-sequence
> 
> Hi,
> 
> How about adding a sentence reminding that "A" stands for "Autonomous"?
> E.g., "policies may apply at AS boundaries and Area IDs after AS change
> may be pruned/ignored."
> 
> Regard,
> 
> Julien
> 
> 
> Nov. 02, 2015 - [email protected]:
> > Hi All,
> >
> > How is this -
> >
> >     IGP Area subobjects in the XRO are local to the current AS.  In
> case
> >     of multi-AS path computation to exclude an IGP area in a
> different
> >     AS, IGP Area subobject should be part of Explicit Exclusion Route
> >     Subobject (EXRS) in the IRO to specify the AS in which the IGP
> area
> >     is to be excluded.
> >
> > I have attached the working copy diff for easy reference.
> >
> > Regards,
> > Dhruv
> >
> >> -----Original Message-----
> >> From: Dhruv Dhody
> >> Sent: 02 November 2015 00:33
> >>
> >> Hi All,
> >>
> >> Sorry for delay in replying, let me try to send you proposed text
> >> tomorrow as per Julien's suggestion!
> >>
> >> Regards,
> >> Dhruv
> >>
> >>> -----Original Message-----
> >>> From: Julien Meuric [mailto:[email protected]]
> >>> Sent: 31 October 2015 00:35
> >>>
> >>> Hi Joel, hi Dhruv,
> >>>
> >>> Focusing on the Area ID issue, I'd support adding some text along
> >> with
> >>> Dhruv's proposal, but stricter (not just deferring to
> >>> "implementation's feeling"). I.e., Area IDs are AS-specific and
> >>> mustn't cross AS borders; AS-local Area IDs may be used inside an
> AS
> >>> (without restricting to the origin AS).
> >>>
> >>> See you in Yokohama,
> >>>
> >>> Julien
> >>>
> >>>
> >>> Oct. 30, 2015 - [email protected]:
> >>>>>           Given that Exclude Route Objects are not interleaved
> with
> >>>>>      include Objects, is there a restriction that Area IDs may
> >>>>> only
> >>> be
> >>>>>      excluded from paths within a single AS?
> >>>>>
> >>>>>
> >>>>> [Dhruv]: I guess this would depend on the PCE behavior during
> >>>>> inter-AS path computation i.e. PCEmay feel the area id
> subobjectis
> >>>>> irreleventand strips from the XRO before sending the request to
> >>>>> another PCE ​ or it might keep it intact.
> >>>>>
> >>>>>
> >>>>> This would be in s
> >>>>> ​pi​
> >>>>> ritof RFC 4874 where
> >>>>> ​-
> >>>>>
> >>>>>
> >>>>>
> >>>>> The number of subobjects to be avoided, specified in the
> >>>>>      signaled XRO, may be constant throughout the whole path
> >>>>> setup,
> >>> or the
> >>>>>      subobjects to be avoided may be removed from the XRO as they
> >>> become
> >>>>>      irrelevant in the subsequent hops of the path setup.
> >>>>>
> >>>>> We can always
> >>>>> ​use
> >>>>> EXRS in IRO specify the intentions much more clearly.
> >>>>>
> >>>>> If you agree, we can work on some text to add.
> >>>>
> >>>> I still can not see how the Excluded Route Object with an Area ID
> >>> will
> >>>> work.  How will a PCE which receives such a request know what AS
> it
> >>>> applies to?  It works fine if the whole path is within one AS.
> But
> >>> if
> >>>> this is a multi-AS request, the AS elements, if present at all,
> are
> >>> in
> >>>> the IRO.
> >>>> The most obvious approach would be to declare that the PCE shall
> >>>> assume that all Area ID exclusions apply to the origin AS.
Title: Diff: draft-ietf-pce-pcep-domain-sequence-09.txt - draft-ietf-pce-pcep-domain-sequence-10.txt
Content-Type: text/html
< draft-ietf-pce-pcep-domain-sequence-09.txt   draft-ietf-pce-pcep-domain-sequence-10.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: March 23, 2016 R. Casellas Expires: May 5, 2016 R. Casellas
CTTC CTTC
September 20, 2015 November 2, 2015
Standard Representation of Domain-Sequence Domain Subobjects for Path Computation Element (PCE) Communication
draft-ietf-pce-pcep-domain-sequence-09 Protocol (PCEP).
draft-ietf-pce-pcep-domain-sequence-10
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 System (AS). This Gateway Protocol (IGP) area or an Autonomous System (AS). This
skipping to change at page 1, line 45 skipping to change at page 1, line 46
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 March 23, 2016. This Internet-Draft will expire on May 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 2, line 39 skipping to change at page 2, line 39
3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7 3.3. Domain-Sequence Representation . . . . . . . . . . . . . 7
3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7 3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7
3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8
3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8 3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8
3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9 3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Update in IRO specification . . . . . . . . . . . . . 10 3.4.2. Update in IRO specification . . . . . . . . . . . . . 10
3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10 3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10
3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11 3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11
3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11 3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11
3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12 3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 12
3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12 3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 13
3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13 3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 13
3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13 3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 14
3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15 3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 15
3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 15 3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16 4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 16
4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18 4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 18
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19 4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 19
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21 4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 21
4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23 4.3. Boundary Node and Inter-AS-Link . . . . . . . . . . . . . 23
4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24 4.4. PCE Serving multiple Domains . . . . . . . . . . . . . . 24
4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 24 4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 24
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 25 5. Other Considerations . . . . . . . . . . . . . . . . . . . . 25
5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 25 5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 25
5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 25 5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 26 6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
8. Manageability Considerations . . . . . . . . . . . . . . . . 26 8. Manageability Considerations . . . . . . . . . . . . . . . . 26
8.1. Control of Function and Policy . . . . . . . . . . . . . 26 8.1. Control of Function and Policy . . . . . . . . . . . . . 27
8.2. Information and Data Models . . . . . . . . . . . . . . . 27 8.2. Information and Data Models . . . . . . . . . . . . . . . 27
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 27
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 27
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 27 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 27
8.6. Impact On Network Operations . . . . . . . . . . . . . . 27 8.6. Impact On Network Operations . . . . . . . . . . . . . . 27
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.1. Normative References . . . . . . . . . . . . . . . . . . 28 10.1. Normative References . . . . . . . . . . . . . . . . . . 28
10.2. Informative References . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
A Path Computation Element (PCE) may be used to compute end-to-end A Path Computation Element (PCE) may be used to compute end-to-end
paths across multi-domain environments using a per-domain path paths across multi-domain environments using a per-domain path
computation technique [RFC5152]. The backward recursive path computation technique [RFC5152]. The backward recursive path
computation (BRPC) mechanism [RFC5441] also defines a PCE-based path computation (BRPC) mechanism [RFC5441] also defines a PCE-based path
computation procedure to compute inter-domain constrained path for computation procedure to compute inter-domain constrained path for
(G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume (G)MPLS TE LSPs. However, both per-domain and BRPC techniques assume
that the sequence of domains to be crossed from source to destination that the sequence of domains to be crossed from source to destination
skipping to change at page 12, line 38 skipping to change at page 12, line 38
that has this link. that has this link.
* Otherwise, it assumes that the subobject belongs to the current * Otherwise, it assumes that the subobject belongs to the current
Area. Area.
o In case the current PCE is not responsible for the path o In case the current PCE is not responsible for the path
computation in the current AS or Area, then the PCE selects the computation in the current AS or Area, then the PCE selects the
"next PCE" in the domain-sequence based on the current AS and "next PCE" in the domain-sequence based on the current AS and
Area. Area.
Note that it is advised that, PCC should use AS and Area subobject
while building the domain-sequence in IRO and avoid using other
mechanism to change the "current AS" and "current Area" as described
above.
3.5. Exclude Route Object (XRO) 3.5. Exclude Route Object (XRO)
The Exclude Route Object (XRO) [RFC5521] is an optional object used The Exclude Route Object (XRO) [RFC5521] is an optional object used
to specify exclusion of certain abstract nodes or resources from the to specify exclusion of certain abstract nodes or resources from the
whole path. whole path.
3.5.1. Subobjects 3.5.1. Subobjects
Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477], Some subobjects to be used in XRO as defined in [RFC3209], [RFC3477],
[RFC4874], and [RFC5520], but new subobjects related to Domain- [RFC4874], and [RFC5520], but new subobjects related to Domain-
skipping to change at page 15, line 10 skipping to change at page 15, line 19
All other fields are consistent with the definition in Section 3.4. All other fields are consistent with the definition in Section 3.4.
All the processing rules are as per [RFC5521]. All the processing rules are as per [RFC5521].
Note that, if a PCE receives an XRO in a PCReq message that contains Note that, if a PCE receives an XRO in a PCReq message that contains
subobjects defined in this document, that it does not recognize, it subobjects defined in this document, that it does not recognize, it
will respond according to the rules for a malformed object as per will respond according to the rules for a malformed object as per
[RFC5440]. [RFC5440].
IGP Area subobjects in the XRO are local to the current AS. In case
of multi-AS path computation to exclude an IGP area in a different
AS, IGP Area subobject should be part of Explicit Exclusion Route
Subobject (EXRS) in the IRO to specify the AS in which the IGP area
is to be excluded. Further policy may be applied to prune/ignore
Area subobjects in XRO after "current AS" change during path
computation.
3.6. Explicit Exclusion Route Subobject (EXRS) 3.6. Explicit Exclusion Route Subobject (EXRS)
Explicit Exclusion Route Subobject (EXRS) [RFC5521] is used to EXRS [RFC5521] is used to specify exclusion of certain abstract nodes
specify exclusion of certain abstract nodes between a specific pair between a specific pair of nodes.
of nodes.
The EXRS subobject can carry any of the subobjects defined for The EXRS subobject can carry any of the subobjects defined for
inclusion in the XRO, thus the new subobjects to support 4 byte AS inclusion in the XRO, thus the new subobjects to support 4 byte AS
and IGP (OSPF / ISIS) Area can also be used in the EXRS. The and IGP (OSPF / ISIS) Area can also be used in the EXRS. The
meanings of the fields of the new XRO subobjects are unchanged when meanings of the fields of the new XRO subobjects are unchanged when
the subobjects are included in an EXRS, except that scope of the the subobjects are included in an EXRS, except that scope of the
exclusion is limited to the single hop between the previous and exclusion is limited to the single hop between the previous and
subsequent elements in the IRO. subsequent elements in the IRO.
The EXRS subobject should be interpreted in the context of the The EXRS subobject should be interpreted in the context of the
skipping to change at page 26, line 27 skipping to change at page 26, line 27
pcep.xhtml#xro-subobject pcep.xhtml#xro-subobject
Upon approval of this document, IANA is requested to make identical Upon approval of this document, IANA is requested to make identical
additions to these registries as follows: additions to these registries as follows:
Subobject Type Reference Subobject Type Reference
TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ] TBD1 4 byte AS number [This I.D.][DOMAIN-SUBOBJ]
TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ] TBD2 OSPF Area ID [This I.D.][DOMAIN-SUBOBJ]
TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ] TBD3 IS-IS Area ID [This I.D.][DOMAIN-SUBOBJ]
Further upon approval of this document, IANA is requested to add a
reference to this document to the new RSVP numbers that are
registered by [DOMAIN-SUBOBJ].
7. Security Considerations 7. Security Considerations
This document specifies a standard representation of Domain-Sequence This document specifies a standard representation of Domain-Sequence
and new subobjects, which could be used in inter-domain PCE scenarios and new subobjects, which could be used in inter-domain PCE scenarios
as explained in other RFC and drafts. The new subobjects and Domain- as explained in other RFC and drafts. The new subobjects and Domain-
Sequence mechanisms defined in this document allow finer and more Sequence mechanisms defined in this document allow finer and more
specific control of the path computed by a cooperating PCE(s). Such specific control of the path computed by a cooperating PCE(s). Such
control increases the risk if a PCEP message is intercepted, control increases the risk if a PCEP message is intercepted,
modified, or spoofed because it allows the attacker to exert control modified, or spoofed because it allows the attacker to exert control
over the path that the PCE will compute or to make the path over the path that the PCE will compute or to make the path
skipping to change at page 29, line 31 skipping to change at page 29, line 38
[IRO-UPDATE] [IRO-UPDATE]
Dhody, D., "Update to Include Route Object (IRO) Dhody, D., "Update to Include Route Object (IRO)
specification in Path Computation Element communication specification in Path Computation Element communication
Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015. Protocol (PCEP. (draft-ietf-pce-iro-update-02)", May 2015.
[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-ietf-teas-rsvp-te- Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te-
domain-subobjects-02)", July 2015. domain-subobjects-04)", November 2015.
10.2. Informative References 10.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic Inter-Domain Multiprotocol Label Switching Traffic
 End of changes. 14 change blocks. 
14 lines changed or deleted 31 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/ 
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to