While I'm on a roll reviewing PCE documents, and while Young is being
active, I just had a look at his new revision on this draft.
Glad that it is alive again because we seem to have a number of documents
that relate to it.
Only a few comments, but I think tidying these gets us close to "done".
Thanks,
Adrian
===
You should move "Conventions used in this document" down to become
Section 2 and replace it with the new text...
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
That requires you to make an addition to the normative references for
RFC 8174.
---
2.
OLD
For Passive Stateful PCE where PCReq/PCRep messages are used to
convey path computation instruction. As GMPLS-technology specific
Objects/TLVs are defined in [PCEP-GMPLS], this document just points
to the work in [PCEP-GMPLS] and add only the stateful PCE aspect
only if applicable.
NEW
For Passive Stateful PCEs, PCReq/PCRep messages are used to convey
path computation instructions. GMPLS-technology specific Objects and
TLVs are defined in [PCEP-GMPLS], so this document just points at
that work and only adds the stateful PCE aspects where applicable.
END
---
4.2
You have "ERO object" and "RRO object". That would be EROO and RROO?
I think that if you expand the terms on first use, then the use of the
abbreviations will be easier.
In the same section you have IRO and XRO which you should expand.
---
4.2 needs a reference to RFC 5511. I suggest...
OLD
To be more specific, the <attribute-list> is updated as
follows:
NEW
To be more specific, the <attribute-list> is updated as
follows using the notation of [RFC5511]:
END
Obviously, you need to add that to the references section as well.
---
At the end of 4.2 you have
Moreover, if the status
of the protecting LSP changes from non-operational to operational,
this SHOULD to be synchronized to the stateful PCE using a PCRpt
message.
Reviewers are likely to ask "under what circumstances can an
implementation vary this procedure and why?"
You may also get asked about the use of the passive voice in this
sentence. Who should synchonise it to the stateful PCE?
---
The final sentence of 4.3 says...
Note this MAY also be applicable to packet
networks.
I think probably s/MAY also be/is also/
---
4.3.2
You rightly say...
X bit and Attribute fields are defined in [RFC5521].
So you can safely (should) delete ...
X bit: indicates whether the exclusion is mandatory (X=1) and MUST
be accommodated, or desired (X=0) and SHOULD be accommodated.
.... and ...
Attributes: indicates how the exclusion object is to be
interpreted. Currently, Interface (Attributes = 0), Node
(Attributes =1) and SRLG (Attributes =2) are defined in [RFC5521]
and this document does not define new values.
---
4.3.2 s/a LSP/an LSP/
---
4.3.2 s/exclude it from the/exclude from the/
---
I'm trying to reconcile 4.3.3 with 5.3. The problems are:
- 5.3 "new registry" but I think the registry already exists
- 5.3 (correctly) says that the new bit position is TBD allowing IANA
to make the best selection, but Figure 3 shows a specific position
for the B-bit
I would replace the text in the two sections as follows...
4.3.3
OLD
The format of the SRP object is defined in [RFC8231] and included
here for easy reference with the addition of the new B flag. This
SRP object is used in PCUpd and PCInit messages for GMPLS.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |B|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The SRP Object Format
A new flag is defined to indicate a bidirectional co-routed LSP
setup operation initiated by the PCE:
B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a
request to create a uni-directional LSP. If set to 1, it indicates
a request to create a bidirectional co-routed LSP.
NEW
The format of the SRP object is defined in [RFC8231]. The object is
used in PCUpd and PCInit messages for GMPLS.
This document defines a new flag to be carried in the Flags field of
the SRP object. This flag indicates a bidirectional co-routed LSP
setup operation initiated by the PCE as follows:
B (Bidirectional LSP -- 1 bit): If set to 0, it indicates a
request to create a uni-directional LSP. If set to 1, it
indicates a request to create a bidirectional co-routed LSP.
The bit position is TBD5 as assigned by IANA (see Section 5.3)
END
5.3
OLD
IANA has created a new subregistry, named "SRP Object Flag Field",
within the "Path Computation Element Protocol (PCEP) Numbers"
registry, to manage the Flag field of the SRP object. New values
are to be assigned by Standards Action [RFC8126]. Each bit is
tracked with the following qualities: bit number (counting from bit
0 as the most significant bit), description, and defining RFC.
The following values are defined in this document:
Bit Description Reference
--- ---------------------------- ----------
TDB Bi-directional co-routed LSP [This.I-D]
NEW
IANA maintains a subregistry, named the "SRP Object Flag Field",
within the "Path Computation Element Protocol (PCEP) Numbers"
registry, to manage the Flag field of the SRP object.
IANA is requested to make an assignment from this registry as
follows:
Bit Description Reference
--- ---------------------------- ----------
TDB5 Bi-directional co-routed LSP [This.I-D]
END
---
Section 5 has
IANA is requested to allocate new Types for the TLV/Object defined
in this document.
I think you should delete that text. It doesn't seem to belong to this
document.
---
6. s/presented in the next sections./presented in the next section./
-----Original Message-----
From: Pce <[email protected]> On Behalf Of Leeyoung
Sent: 05 December 2018 17:21
To: [email protected]
Subject: Re: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt
Hi,
Just to revive the expired WG draft. Sorry that we slipped this one.
Best regards,
Young
-----Original Message-----
From: Pce [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Wednesday, December 5, 2018 9:25 AM
To: [email protected]
Cc: [email protected]
Subject: [Pce] I-D Action: draft-ietf-pce-pcep-stateful-pce-gmpls-09.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 : Path Computation Element (PCE) Protocol Extensions
for Stateful PCE Usage in GMPLS-controlled Networks
Authors : Xian Zhang
Young Lee
Fatai Zhang
Ramon Casellas
Oscar Gonzalez de Dios
Zafar Ali
Filename : draft-ietf-pce-pcep-stateful-pce-gmpls-09.txt
Pages : 15
Date : 2018-12-05
Abstract:
The Path Computation Element (PCE) facilitates Traffic Engineering
(TE) based path calculation in large, multi-domain, multi-region, or
multi-layer networks. The PCE communication Protocol (PCEP) has been
extended to support stateful PCE functions where the PCE retains
information about the paths already present in the network, but
those extensions are technology-agnostic. This memo provides
extensions required for PCEP so as to enable the usage of a stateful
PCE capability in GMPLS-controlled networks.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-stateful-pce-gmpls/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-stateful-pce-gmpls-09
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-stateful-pce-gmpls
-09
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-stateful-pce-gmpls-09
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
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
