Re: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt
Hi Jon,
There is one issue which I would like to discuss and it came up during the
EANTC multi-vendor interop in March 2018.
The rule for handling MSD in Section 5.5 seems to be overly restrictive. The
MSD value advertised in the Open message is useful as an upper bound for both
pce-initiated LSP and pcc-initiated LSP. However, PCC may want to set a MSD
value for a specific pcc-initiated LSP which is lower than that in the Open
Object. The rules in Section 5.5 do not allow that as the presence of the MSD
Metric object in the path request message is errored if a non-zero MSD was
included in the Open message. If on the other hand you set the MSD in the Open
message to zero, PCE will not discover the MSD to enforce for pce-initiated LSP.
What I would like to propose is to relax the rule such that a path request is
only errored when the MSD Metric value is higher than that in the Open message.
That way we can achieve the desired behavior for both pce-initiated and
pcc-initiated LSP.
Here is the relevant paragraph in Section 5.5:
"
If a PCEP session is established with a non-zero MSD value, then the
PCC MUST NOT send an MSD METRIC object. If the PCE receives a path
computation request with an MSD METRIC object on a session with a
non-zero MSD value then it MUST consider the request invalid and send
a PCErr with Error-Type = 10 ("Reception of an invalid object") and
Error-Value 9 ("Default MSD is specified for the PCEP session").
"
Mustapha.
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Friday, June 29, 2018 1:22 PM
To: pce@ietf.org
Subject: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt
This new version addresses the feedback received during working group last
call. My apologies for the long delay.
Many thanks to those who took the time to review and comment on this. The
result is that the draft has been substantially tightened and many ambiguities
resolved.
I will be replying to the individual commenters today.
Best regards
Jon
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 29 June 2018 18:20
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element WG of the IETF.
Title : PCEP Extensions for Segment Routing
Authors : Siva Sivabalan
Clarence Filsfils
Jeff Tantsura
Wim Henderickx
Jon Hardwick
Filename: draft-ietf-pce-segment-routing-12.txt
Pages : 32
Date: 2018-06-29
Abstract:
Segment Routing (SR) enables any head-end node to select any path
without relying on a hop-by-hop signaling technique (e.g., LDP or
RSVP-TE). It depends only on "segments" that are advertised by Link-
State Interior Gateway Protocols (IGPs). A Segment Routed Path can
be derived from a variety of mechanisms, including an IGP Shortest
Path Tree (SPT), explicit configuration, or a Path Computation
Element (PCE). This document specifies extensions to the Path
Computation Element Protocol (PCEP) that allow a stateful PCE to
compute and initiate Traffic Engineering (TE) paths, as well as a PCC
to request a path subject to certain constraints and optimization
criteria in SR networks.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-segment-routing-12
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-12
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-12
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Hi Cyril Many apologies for the delay – please see below. Cheers Jon From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cyril Margaria Sent: 30 January 2018 16:49 To: Dhruv Dhody Cc: pce@ietf.org Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11 Hi, I have the following (hopefully not too late) comments/questions: Section 5.3 ERO Object S: When this bit is set, the SID value in the subobject body is null. In this case, the PCC is responsible for choosing the SID value, e.g., by looking up its TED using the NAI which, in this case, MUST be present in the subobject. - What is the associated procedure if the PCC cannot resolve the NAI to a SID? Should there be associated error codes. For instance the PCC may not be able to resolve the NAI at all or the resolution may fail. In case the PCC does not support the NAI resolution, having this capability part of the capability exchange would improve interop, as the PCE can be capable to provide the SID. [Jon] I agree that a capability would be good. Yes, if the NAI cannot be resolved, it should be rejected. I have added both of these to the latest draft. [/Jon] - If Both S and F are cleared, should the PCC do the NAI resolution and verify that the SID match? Would error codes be needed) [Jon] If the SID is a bare label then the NAI may be given to help identify the next hop. If the SID is an index and NAI is given as well, then the PCC SHOULD use the SID, because it is a more explicit instruction. The PCE MAY give both SID and NAI for diagnostic / logging purposes. I don’t think we should require the PCC to validate SID==NAI in that case; it should just use the SID as given. I will clarify in the draft. [/Jon] Thanks, Cyril On 30 January 2018 at 01:19, Dhruv Dhody mailto:dhruv.dh...@huawei.com>> wrote: Hi, I had reviewed and given comments on the I-D in the past, which the authors had addressed. I found these additional nits/suggestions. Apologies for being late by a day. Suggestions --- Section 1 (1) Though it is true that a child PCE act as a PCC towards the parent PCE, I feel it is not wise to say the opposite, that is a PCC is acting as a PCE in this context. I see no advantage to bring up the H-PCE in this context. I suggest we remove it. A PCE, or a PCC operating as a PCE (in hierarchical PCE environment), computes paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on various constraints and optimization criteria. (2) Since this document is related to MPLS data plane only, it would be nice to include a pointer to the SRv6 work in PCEP for the benefit of the readers. (3) Regarding first mention of PST OLD: This specification relies on the procedures specified in [I- D.ietf-pce-lsp-setup-type]. NEW: This specification relies on the procedures specified in [I- D.ietf-pce-lsp-setup-type] for the path setup type for SR. Section 3 (4) Regarding this text - SR-TE LSPs computed by a PCE can be represented in one of the following forms: o An ordered set of IP address(es) representing network nodes/links: In this case, the PCC needs to convert the IP address(es) into the corresponding MPLS labels by consulting its Traffic Engineering Database (TED). o An ordered set of SID(s). o An ordered set of both MPLS label(s) and IP address(es): In this case, the PCC needs to convert the IP address(es) into the corresponding SID(s) by consulting its TED. Each SR-ERO object can include both SID and NAI (IP address); this case is different from the case 3 above, I suggest if some text can be added to make things clearer. Section 5.1.1 (5) Why SHOULD in this text? A PCEP speaker SHOULD indicate its support of the function described in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object with this new PST included in the PST list. Section 6 (6) Regarding, A PCEP speaker that does not support the SR PCEP capability cannot recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a PCEP error with Error-Type = 4 (Not supported object) and Error-Value = 2 (Not supported object Type) as per [RFC5440]. RFC 5440 did not state the behavior for unknown sub-object. My suggestion would be - A PCEP speaker that does not support the SR PCEP capability and thus cannot recognize the SR-ERO or SR-RRO subobjects, it will respond according to the rules for a malformed object as per [RFC5440]. Section 7 (7) Suggest to make Manageability Consideration section as per RFC 6123 (8) PCEP-Yang should be mentioned in section 7.2 Section 8 (9) Suggest we expand the security consideration section a bit based on recent DISCUSSes. Nits Sec
Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Hi Dhruv
Thanks – I have addressed this case in the latest version.
Jon
From: dhruvdh...@gmail.com [mailto:dhruvdh...@gmail.com] On Behalf Of Dhruv
Dhody
Sent: 04 March 2018 05:41
To: draft-ietf-pce-segment-rout...@ietf.org
Cc: Julien Meuric ; pce@ietf.org; Dhruv Dhody
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Hi,
As I was updating the PCEP-SRv6 document [1], I noticed that the behavior for
'the unknown ST (SID Type)' is not defined in the SR-ERO/SR-RRO. Could the
authors take this into consideration while they make an update.
Also an IANA code point sub registry needs to be setup in this document for the
ST Type, so that future extensions (like SRv6) can define new ST types.
Thanks!
Dhruv
[1] https://datatracker.ietf.org/doc/draft-negi-pce-segment-routing-ipv6/
On Tue, Jan 30, 2018 at 2:49 PM, Dhruv Dhody
mailto:dhruv.dh...@huawei.com>> wrote:
Hi,
I had reviewed and given comments on the I-D in the past, which the
authors had addressed. I found these additional nits/suggestions.
Apologies for being late by a day.
Suggestions
---
Section 1
(1) Though it is true that a child PCE act as a PCC towards the
parent PCE, I feel it is not wise to say the opposite, that is a PCC
is acting as a PCE in this context. I see no advantage to bring up the
H-PCE in this context. I suggest we remove it.
A PCE, or a PCC operating as a PCE (in hierarchical PCE
environment), computes paths for MPLS Traffic Engineering LSPs
(MPLS-TE LSPs) based on various constraints and optimization
criteria.
(2) Since this document is related to MPLS data plane only, it would
be nice to include a pointer to the SRv6 work in PCEP for the benefit
of the readers.
(3) Regarding first mention of PST
OLD:
This specification relies on the procedures specified in [I-
D.ietf-pce-lsp-setup-type].
NEW:
This specification relies on the procedures specified in [I-
D.ietf-pce-lsp-setup-type] for the path setup type for SR.
Section 3
(4) Regarding this text -
SR-TE LSPs
computed by a PCE can be represented in one of the following forms:
o An ordered set of IP address(es) representing network nodes/links:
In this case, the PCC needs to convert the IP address(es) into the
corresponding MPLS labels by consulting its Traffic Engineering
Database (TED).
o An ordered set of SID(s).
o An ordered set of both MPLS label(s) and IP address(es): In this
case, the PCC needs to convert the IP address(es) into the
corresponding SID(s) by consulting its TED.
Each SR-ERO object can include both SID and NAI (IP address); this
case is different from the case 3 above, I suggest if some text can
be added to make things clearer.
Section 5.1.1
(5) Why SHOULD in this text?
A PCEP speaker SHOULD indicate its support of the function described
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
OPEN object with this new PST included in the PST list.
Section 6
(6) Regarding,
A PCEP speaker that does not support the SR PCEP capability cannot
recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
PCEP error with Error-Type = 4 (Not supported object) and Error-Value
= 2 (Not supported object Type) as per [RFC5440].
RFC 5440 did not state the behavior for unknown sub-object. My
suggestion would be -
A PCEP speaker that does not support the SR PCEP capability and
thus cannot recognize the SR-ERO or SR-RRO subobjects, it will
respond according to the rules for a malformed object as per
[RFC5440].
Section 7
(7) Suggest to make Manageability Consideration section as per RFC
6123
(8) PCEP-Yang should be mentioned in section 7.2
Section 8
(9) Suggest we expand the security consideration section a bit based
on recent DISCUSSes.
Nits
Section 5.3.1
s/MUST not/MUST NOT/
Section 5.3.3
(2)
OLD:
A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
message and MUST send a PCErr message with Error-Type=3 ("Unknown
Object") and Error-Value=2 ("Unrecognized object Type") or Error-
Type=4 ("Not supported object") and Error-Value=2 ("Not supported
object Type"), defined in [RFC5440].
NEW:
A PCEP speaker that does not recognize or support the SR-ERO
subobject in PCRep, PCInitiate, PCUpd or PCRpt messages MUST
reject the entire PCEP message and MUST send a PCErr message with
Error-Type=3 ("Unknown Object") and Error-Value=2 ("Unrecognized
object Type") or Error- Type=4 ("Not supported object") and Error-
Value=2 ("Not supported object Type"), defined in [RFC5440].
(3) I agree with Adrian that the ".. not identical" needs to ch
Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Hi Dhruv
My apologies for the delay. Please find my replies and comments below.
Cheers
Jon
-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: 30 January 2018 09:20
To: Julien Meuric ; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Hi,
I had reviewed and given comments on the I-D in the past, which the
authors had addressed. I found these additional nits/suggestions.
Apologies for being late by a day.
Suggestions
---
Section 1
(1) Though it is true that a child PCE act as a PCC towards the
parent PCE, I feel it is not wise to say the opposite, that is a PCC
is acting as a PCE in this context. I see no advantage to bring up the
H-PCE in this context. I suggest we remove it.
A PCE, or a PCC operating as a PCE (in hierarchical PCE
environment), computes paths for MPLS Traffic Engineering LSPs
(MPLS-TE LSPs) based on various constraints and optimization
criteria.
[Jon] OK with me - I'll trim it. [/Jon]
(2) Since this document is related to MPLS data plane only, it would
be nice to include a pointer to the SRv6 work in PCEP for the benefit
of the readers.
[Jon] Changed introduction text as follows and added normative references.
The SR architecture can be implemented using either an MPLS forwarding plane
[I-D.ietf-spring-segment-routing-mpls] or an IPv6 forwarding plane
[I-D.ietf-6man-segment-routing-header]. The MPLS forwarding plane can be
applied to SR without any change, in which case an SR path corresponds to an
MPLS Label Switching Path (LSP). This document is relevant to the MPLS
forwarding plane only.
[/Jon]
(3) Regarding first mention of PST
OLD:
This specification relies on the procedures specified in [I-
D.ietf-pce-lsp-setup-type].
NEW:
This specification relies on the procedures specified in [I-
D.ietf-pce-lsp-setup-type] for the path setup type for SR.
[Jon] I changed it to:
This specification relies on the procedures specified in [I-
D.ietf-pce-lsp-setup-type] to exchange the segment routing
capability and to specify that the path setup type of an LSP
is segment routing..
[/Jon]
Section 3
(4) Regarding this text -
SR-TE LSPs
computed by a PCE can be represented in one of the following forms:
o An ordered set of IP address(es) representing network nodes/links:
In this case, the PCC needs to convert the IP address(es) into the
corresponding MPLS labels by consulting its Traffic Engineering
Database (TED).
o An ordered set of SID(s).
o An ordered set of both MPLS label(s) and IP address(es): In this
case, the PCC needs to convert the IP address(es) into the
corresponding SID(s) by consulting its TED.
Each SR-ERO object can include both SID and NAI (IP address); this
case is different from the case 3 above, I suggest if some text can
be added to make things clearer.
[Jon] Changed bullet 2 to:
An ordered set of SIDs, with or without the corresponding IP addresses.
[/Jon]
Section 5.1.1
(5) Why SHOULD in this text?
A PCEP speaker SHOULD indicate its support of the function described
in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
OPEN object with this new PST included in the PST list.
[Jon] For backwards compatibility with shipping implementations that omit it.
[/Jon]
Section 6
(6) Regarding,
A PCEP speaker that does not support the SR PCEP capability cannot
recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
PCEP error with Error-Type = 4 (Not supported object) and Error-Value
= 2 (Not supported object Type) as per [RFC5440].
RFC 5440 did not state the behavior for unknown sub-object. My
suggestion would be -
A PCEP speaker that does not support the SR PCEP capability and
thus cannot recognize the SR-ERO or SR-RRO subobjects, it will
respond according to the rules for a malformed object as per
[RFC5440].
[Jon] OK [/Jon]
Section 7
(7) Suggest to make Manageability Consideration section as per RFC
6123
[Jon] Done [/Jon]
(8) PCEP-Yang should be mentioned in section 7.2
[Jon] Done [/Jon]
Section 8
(9) Suggest we expand the security consideration section a bit based
on recent DISCUSSes.
[Jon] Have tweaked it a bit but I think (nay, hope) what we have is OK as it
passed for the LSP setup type draft. [/Jon]
Nits
Section 5.3.3
(2)
OLD:
A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
message and MUST send a PCErr message with Error-Type=3 ("Unknown
Object") and Error-Value=2 ("Unrecognized object Type") or Error-
Type=4 ("Not supported object") and Error-Value=2 ("Not supported
Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11
Hi Adrian
Sorry for the delay. Thanks again for the carefully considered feedback. I've
trimmed out points below where I agreed and no comment was necessary. Please
find answers and clarifications below.
---
Section 3
o An ordered set of IP address(es) representing network nodes/links:
In this case, the PCC needs to convert the IP address(es) into the
corresponding MPLS labels by consulting its Traffic Engineering
Database (TED).
But I am surprised that this work is offloaded to the PCC since the PCE has all
the information to do this task. Why did the WG want to add this option?
And then...
o An ordered set of SID(s)
s/SID(s)/SIDs/
This list of SIDs would need to be converted to labels by the PCC by applying
the SRGB offsets. Again, why make the PCC do this?
And finally...
o An ordered set of both MPLS label(s) and IP address(es): In this
case, the PCC needs to convert the IP address(es) into the
corresponding SID(s) by consulting its TED.
This mixture of the previous two cases seems to compound the level of
complexity. Can't the PCE just know it is making an SR path and supply a list
of MPLS labels corresponding to the SIDs?
[Jon] Having consulted the authors, the reason is that different PCE
implementations have different approaches, which can all be accommodated fairly
straightforwardly in the draft's format. Having said that, it seems harsh to
force the PCC into having to provide an NAI-resolution service for the PCE.
Therefore, I have added a capability flag so that the PCC can indicate that it
cannot / will not do NAI resolution. [/Jon]
---
5.1.2 > 6
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is
absent, then the PCEP speaker MUST send a PCErr message with Error-
Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
close the PCEP session.
Suppose an implementation receives an Open with PST=1 but doesn't understand
(or doesn't support) that value. Is it still required to perform this check?
Hopefully not.
[Jon] Nope. Have changed to
If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
PST list containing PST=1, and supports that path setup type, then it
checks for the presence of the SR-PCE-CAPABILITY sub-TLV. If that sub-TLV is
absent, then the PCEP speaker MUST send a PCErr message with Error-
Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
close the PCEP session.
[/Jon]
---
5.3.1 (under Length) has
As mentioned earlier, an SR-ERO
subobject MUST have at least SID or NAI.
This is good and does tie in with what is written in earlier sections.
However, 5.3.1 starts with
An SR-ERO subobject consists of a 32-bit header followed by the SID
and the NAI associated with the SID. The SID is a 32-bit number.
The size of the NAI depends on its respective type, as described in
the following sections.
That makes it sound like they are both mandatory, and the figure doesn't help.
A little rewording would go a long way, and you could add "(optional)"
to the figure.
[Jon] I have modified the preamble to the following, and have added the word
"optional" to the diagram.
An SR-ERO subobject consists of a 32-bit header followed by the SID
and/or the NAI associated with the SID. The SID is a 32-bit number.
The size of the NAI depends on its respective type, as described in
the following sections. At least one of the SID and the NAI MUST be
included in the SR-ERO subobject, and both MAY be included.
[/Jon]
---
5.3.1
SID Type (ST) indicates the type of information associated with the
SID contained in the object body. When ST value is 0, SID MUST
NOT be null and NAI MUST be null.
Does "null" mean "all zeros" or "absent"?
See also the definition of the S and F flags.
[Jon] It means "absent" (see definition of Length field). But this is not
particularly clear, so I have changed all instances of "null" to "absent".
[/Jon]
---
5.3.1
Other ST values are described
later in this document.
It would be friendly to provide a list somewhere.
Do you need a registry?
[Jon] I have added a list and created a registry. [/Jon]
---
5.3.1
Flags is used to carry any additional information pertaining to SID.
You need to say how to set the unused bits.
Do you need a registry?
[Jon] I have created a registry. [/Jon]
---
5.3.3
If a PCC receives a stack of SR-ERO subobjects, and the number of
stack exceeds the maximum number of SIDs that the PCC can impose on
the packet, it MAY send a PCErr message with Error-Type = 10
("Reception of an invalid object") and Error-Value = 3 ("Unsupported
nu
[Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt
This new version addresses the feedback received during working group last call. My apologies for the long delay. Many thanks to those who took the time to review and comment on this. The result is that the draft has been substantially tightened and many ambiguities resolved. I will be replying to the individual commenters today. Best regards Jon -Original Message- From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: 29 June 2018 18:20 To: i-d-annou...@ietf.org Cc: pce@ietf.org Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Clarence Filsfils Jeff Tantsura Wim Henderickx Jon Hardwick Filename: draft-ietf-pce-segment-routing-12.txt Pages : 32 Date: 2018-06-29 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-12 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
[Pce] I-D Action: draft-ietf-pce-segment-routing-12.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Path Computation Element WG of the IETF. Title : PCEP Extensions for Segment Routing Authors : Siva Sivabalan Clarence Filsfils Jeff Tantsura Wim Henderickx Jon Hardwick Filename: draft-ietf-pce-segment-routing-12.txt Pages : 32 Date: 2018-06-29 Abstract: Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-pce-segment-routing-12 https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
