[Pce] Experimental Error-Types and Error-values

[Adrian Farrel]

Hi working group,

I just refreshed draft-farrel-pce-experimental-errors and cleaned up a couple 
of nits.

It tweaks the scope of the IANA registry to carve out a few Error-Types to be 
for Experimental Use. It also describes how to experiment with Error-Types and 
Error-values

BIG QUESTION

Does the working group want to pursue this?
If so: chairs, can we consider adoption?
If not: I can get a little peace by dropping the draft

Cheers,
Adrian

-Original Message-
From: internet-dra...@ietf.org  
Sent: 03 July 2024 11:34
To: Adrian Farrel ; Haomian Zheng 
Subject: New Version Notification for 
draft-farrel-pce-experimental-errors-02.txt

A new version of Internet-Draft draft-farrel-pce-experimental-errors-02.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF repository.

Name: draft-farrel-pce-experimental-errors
Revision: 02
Title:Allowing Experimental Error Codes in the Path Computation Element 
Protocol
Date: 2024-07-03
Group:Individual Submission
Pages:7
URL:  
https://www.ietf.org/archive/id/draft-farrel-pce-experimental-errors-02.txt
Status:   https://datatracker.ietf.org/doc/draft-farrel-pce-experimental-errors/
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-farrel-pce-experimental-errors
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-farrel-pce-experimental-errors-02

Abstract:

   Experimental RFCs are often considered beneficial approaches to
   developing new protocol features.  To that end, sub-ranges of code
   point registries are often designated as for experimental use.

   IANA assigns values to the Path Computation Element Communication
   Protocol (PCEP) parameters (messages, objects, TLVs).  According to
   RFC 5440 as updated by RFC 8356, the allocation policies for the
   registries for PCEP messages, objects, and TLV types are IETF Review
   with some sub-ranges of these registries being assigned for
   Experimental Use.  However, the registry of PCEP Error-Types and
   Error-values has only the IETF Review assignment policy meaning that
   experimentation is somewhat limited.

   This document updates RFC 5440 by designating a range of PCEP Error-
   Types for Experimental Use.

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] A review of draft-ietf-pce-stateful-pce-vendor

[Adrian Farrel]

Hi,

I'm continuing my campaign of reviewing PCE I-Ds that have been around
for a while. This one had a very long run as an individual I-D, saw an
implementation reported back in 2020, and was adopted in July last year.
It seems the work is pretty stable. Perhaps it's time to polish it and
move to last call.

So here is a review. The document is really well written and easy to
read. I only find a few nits.

Cheers,
Adrian

===

Abstract

s/the associated and the dependent/any associated and dependent/

---

1.

s/[RFC7470] defined Vendor/[RFC7470] defined the Vendor/
s/defined VENDOR-INFORMATION-TLV/defined the VENDOR-INFORMATION-TLV/

OLD
   This document extends the usage of Vendor Information Object and
   VENDOR-INFORMATION-TLV to Stateful PCE.
NEW
   This document extends the usage of the Vendor Information Object and
   the VENDOR-INFORMATION-TLV to Stateful PCE.
END

---

2.

Somewhere in this document, you need a reference to RFC 5511.  The usual
form of words is something like...

   The message formats in this document are specified using Routing
   Backus-Naur Format (RBNF) encoding as specified in [RFC5511].

---

Section 2 uses the VENDOR-INFORMATION object. That's all fine, but it
would be good to be more explicit with the pointer to RFC 7470. 
Something like...

OLD
   The contents and format of the object are described in Section 4 of
   [RFC7470].
NEW
   The contents and format of the object, including the 
   VENDOR-INFORMATION object, are described in Section 4 of [RFC7470].
END

---

I think that the 1.5 lines of Section 4 could easily be placed at the
top of Section 2 and so remove the need for the section.

---

8.

Something we never included in RFC 7470 (and 7150, before it) was the
potential for the vendor-specific information to act as a covert
channel. That is, as a way for applications to exchange information 
that is out of scope of PCEP. It could be used by malign software that
has infected a PCE and PCC, It could even carry executable code.

The nature of vendor-specific information is that it cannot be decoded
or inspected by third parties. So it is difficult to protect against a
covert channel.

There is some protection in the "unrecognised object" and "unknown
enterprise number" for a receiver, but this doesn't provide full 
protection against misuse. That is hard to mitigate.

I think that we should have raised this point in 7470, and that it is
not really something specific for this document. However, I think this
work should mention the problem and say what can be done. Something 
like...

   The use of vendor-specific information as defined in [RFC7470] and
   in this document may provide a covert channel that could be misused
   by PCEP speaker implementations or by malign software at PCEP
   speakers.  There is little protection against this, however, an
   operator that monitors the PCEP sessions can determine that vendor-
   specific information is being used and ask their suppliers (the PCE
   and PCC implementers) to provide a mechanism to decode the vendor-
   specific information.

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] A review of draft-ietf-pce-state-sync-07

[Adrian Farrel]

Hi,

As this document approaches being ready for working group last call, I
thought it might be helpful if I did a review.

Cheers,
Adrian

===

The document title could do with some clean-up.
- Remove the full stop
- Perhaps make it more straight-forward. For example,  Procedures for
Communication between Stateful Path Computation Elements

---

Abstract para 2

s/an LSP/LSP/

---

Abstract para 3

s/a stateful/stateful/

---

1. para 2

s/paths,/paths)/

---

1. para 4

s/an LSP state/LSP state/
s/of a LSP/of an LSP/
s/to only a single PCE/to a single PCE/

---

1.

s/to allow a stateful/to allow stateful/

---

1.

OLD
   Further, the examples in this section are for illustrative purpose to
   showcase the need for inter-PCE stateful PCEP sessions.
NEW
   This section contains illustrative examples to showcase the need for
   inter-PCE stateful PCEP sessions.
END


However, I find the examples running through sections 1.2, 1.3, and 1.4 to
be quite unnecessary. There is a feeling of "trying too hard" to prove that
there are uses for the protocol extensions described in the body of the
document. I would have been very happy with just one paragraph listing out a
few of the possible use cases.

Further, section 4 (which seems to rework the examples in sections 1.2, 1.3,
and 1.4) is not really an explanation of how the protocol extension works,
but more of a set of use cases. Again, this feels like it is trying to prove
the value of the extension. Do we really need it? It is such a simple
protocol extension.

---

1.2 para 1

s/an LSP state/LSP state/
s/grants the control/grants control/

---

1.2 para 2

This is really to read.

   In a multi PCE deployment (redundancy, loadbalancing...), with the
   current specification defined in [RFC8231], when a PCE makes an
   update, it is the PCC that is in charge of reporting the LSP status
   to all PCEs with LSP parameter change which brings additional hops
   and delays in notifying the overall network of the LSP parameter
   change.

a) s/current specification/specification/

b) s/with LSP parameter change/with any LSP parameter changes/

c) I can't tell what the final part of the paragraph means. Is it the
   reporting that brings additional hops and delays? How does the
   reporting cause this?

---

1.2 para 4

s/As stateful PCE make/As a stateful PCE makes/

s/immediately to/to/

---

All the figures in the document need numbers and titles. The text should
refer to them using  rather than "the figure above" etc.

---

1.2

OLD
   PCE1 is responsible to compute paths for PCC1 and PCE2 is responsible
   to compute paths for PCC2.
NEW
   PCE1 is responsible for computing paths for PCC1, and PCE2 is
   responsible for computing paths for PCC2.
END

OLD
   PCE2 will so
   be notified of the change only after receiving the PCRpt message from
   PCC1.
NEW
   So PCE2 will
   be notified of the change only after receiving the PCRpt message from
   PCC1.
END

---

I'm confused by the example given in 1.2. LSP1 is under the control of PCE1,
so any changes that are made are made with the direct instruction from PCE1.
Therefore, it is not necessary to wait for the change to be reported by PCC1
- PCE2 can be notified of the intended change. Surely that would be more
efficient. (Yes, that would only be possible if there is a session between
the PCEs.)

Additionally, when the change is made in the network, it seems unlikely to
me that PCC1 would be aware that it is LSP2 that has had its resources
reduced because PCC1 does not know about the existence of LSP2. However, the
network nodes servicing LSP2 would know about this and so it would be
reported to PCC2 which can report it direct to PCE2.

(Note that this does not take anything away from the proposed protocol
extension. It is just a confusing example.)

---

1.3

s/failure, PCC/failure, the PCC/
s/sending new/sending a new/
Expand 'ERO' on first use.

---

1.3

   When the failed PCE or PCEP session comes back online, it will
   be up to the implementation to do preemption.  Doing preemption may
   lead to some disruption on the existing path if path results from
   both PCEs are not exactly the same.

The term 'preemption' may cause some confusion. I don't think you are
referring to the type of preemption of resources mentioned in the example in
the previous section. Perhaps...

   When the failed PCE or PCEP session comes back online, it will
   be up to the implementation whether to revert back to the original 
   primary PCE.  Reverting may lead to some disruption on the existing
   path if computation results from both PCEs are not exactly the same.

---

1.3

   By considering a network with
   multiple PCCs and implementing multiple stateful PCEs for redundancy
   purpose, there is no guarantee that at any time all the PCCs delegate
   their LSPs to the same PCE.

There is something not quite right about this sentence. Is there a 'not'
missing, such as...

   By considering a network with
   multiple PCCs and 

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Adrian Farrel]

Yeah Samuel,

 

The early names in PCEP did not foresee any future metrics that would need 
disambiguation. So the names are not very good. That’s a shame. But we don’t 
need to repeat the mistake :-)

 

Think about it a bit, and pick the names you think are right.


A

 

From: Samuel Sidor (ssidor)  
Sent: 24 June 2024 09:12
To: adr...@olddog.co.uk; 'Dhruv Dhody' ; pce@ietf.org
Cc: 'pce-chairs' ; draft-ietf-pce-sid-a...@ietf.org
Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

Hi Adrian,

 

I’m fine with renaming it, but in general, I don’t see same naming convention 
being followed often in PCEP. 

 

See for example – IGP or TE metric in PCEP – those would be also called as 
“Summed Path IGP metric” or “Summed Path TE metric” if we want to follow same 
convention.

Same thing for “Worst Leaf Summed …” – see for example “P2MP Path Delay metric”:

https://www.rfc-editor.org/rfc/rfc8233.html#section-3.1.6.1

It is also computed as worst leaf cumulative cost of all paths, but such naming 
convention was not used. What about just adding word “Path” into Bandwidth 
metric name, so it is clear that it is not link BW metric? 

 

So instead of currently used “Bandwidth Metric”, it would be “Path Bandwidth 
Metric”? That way name will be aligned with existing naming conventions in PCEP 
and name will be also indicating that it is not link BW.

 

(but I’m fine even with your proposal if you still prefer to explicitly 
indicate way to compute that metric in the name, maybe with just small 
modification and replacing “Summed” with “Cumulative”).

 

Thanks,

Samuel

 

From: Adrian Farrel mailto:adr...@olddog.co.uk> > 
Sent: Saturday, June 22, 2024 1:29 PM
To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com> >; 
pce@ietf.org <mailto:pce@ietf.org> 
Cc: 'pce-chairs' mailto:pce-cha...@ietf.org> >; 
draft-ietf-pce-sid-a...@ietf.org <mailto:draft-ietf-pce-sid-a...@ietf.org> 
Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

Although, I might be slightly wrong about the second metric because it is even 
more than that.

Perhaps “Worst Leaf Summed Path Bandwidth”?

 

A

 

From: Adrian Farrel mailto:adr...@olddog.co.uk> > 
Sent: 22 June 2024 12:13
To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com> >; 
'pce@ietf.org' mailto:pce@ietf.org> >
Cc: 'pce-chairs' mailto:pce-cha...@ietf.org> >; 
'draft-ietf-pce-sid-a...@ietf.org' mailto:draft-ietf-pce-sid-a...@ietf.org> >
Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

No objection, Dhruv, although it might be helpful to distinguish between the 
Bandwidth metric advertised per link and the new PCEP metric type.

Perhaps call the new metrics “Summed Path Bandwidth” and “Summed P2PM Path 
Bandwidth” because it is more descriptive?

 

Cheers,

Adrian

 

From: Dhruv Dhody mailto:d...@dhruvdhody.com> > 
Sent: 22 June 2024 09:41
To: pce@ietf.org <mailto:pce@ietf.org> 
Cc: pce-chairs mailto:pce-cha...@ietf.org> >; 
draft-ietf-pce-sid-a...@ietf.org <mailto:draft-ietf-pce-sid-a...@ietf.org> 
Subject: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for an 
early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

 

These are the codepoints for the latest changes made to align with 
draft-ietf-lsr-flex-algo-bw-con as per - 
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/ 

 

The chairs would like to know if there are any objections to adding these new 
metric types and keeping a range aside for user defined metrics. 


Further, RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Monday, July 8th, we will kick off the early allocation request.

 

Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

Thanks!
Dhruv & Julien

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Adrian Farrel]

Although, I might be slightly wrong about the second metric because it is even 
more than that.

Perhaps “Worst Leaf Summed Path Bandwidth”?

 

A

 

From: Adrian Farrel  
Sent: 22 June 2024 12:13
To: 'Dhruv Dhody' ; 'pce@ietf.org' 
Cc: 'pce-chairs' ; 'draft-ietf-pce-sid-a...@ietf.org' 

Subject: RE: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

No objection, Dhruv, although it might be helpful to distinguish between the 
Bandwidth metric advertised per link and the new PCEP metric type.

Perhaps call the new metrics “Summed Path Bandwidth” and “Summed P2PM Path 
Bandwidth” because it is more descriptive?

 

Cheers,

Adrian

 

From: Dhruv Dhody  
Sent: 22 June 2024 09:41
To: pce@ietf.org
Cc: pce-chairs ; draft-ietf-pce-sid-a...@ietf.org
Subject: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for an 
early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

 

These are the codepoints for the latest changes made to align with 
draft-ietf-lsr-flex-algo-bw-con as per - 
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/ 

 

The chairs would like to know if there are any objections to adding these new 
metric types and keeping a range aside for user defined metrics. 


Further, RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Monday, July 8th, we will kick off the early allocation request.

 

Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

Thanks!
Dhruv & Julien

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Early code point allocation for draft-ietf-pce-sid-algo-10

[Adrian Farrel]

No objection, Dhruv, although it might be helpful to distinguish between the 
Bandwidth metric advertised per link and the new PCEP metric type.

Perhaps call the new metrics “Summed Path Bandwidth” and “Summed P2PM Path 
Bandwidth” because it is more descriptive?

 

Cheers,

Adrian

 

From: Dhruv Dhody  
Sent: 22 June 2024 09:41
To: pce@ietf.org
Cc: pce-chairs ; draft-ietf-pce-sid-a...@ietf.org
Subject: [Pce] Early code point allocation for draft-ietf-pce-sid-algo-10

 

Hi WG,

We have received a request from the authors of draft-ietf-pce-sid-algo for an 
early code point allocation for the codepoints listed in -

https://www.ietf.org/archive/id/draft-ietf-pce-sid-algo-10.html#table-7

 

These are the codepoints for the latest changes made to align with 
draft-ietf-lsr-flex-algo-bw-con as per - 
https://mailarchive.ietf.org/arch/msg/pce/U2AIec7Vk9LomZM-LlvhxGywQgA/ 

 

The chairs would like to know if there are any objections to adding these new 
metric types and keeping a range aside for user defined metrics. 


Further, RFC 7120 requires one to meet the following criteria to proceed:

b. The format, semantics, processing, and other rules related to
handling the protocol entities defined by the code points
(henceforth called "specifications") must be adequately described
in an Internet-Draft.

c. The specifications of these code points must be stable; i.e., if
there is a change, implementations based on the earlier and later
specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria or believes that 
early allocation is not appropriate for any other reason, please send an email 
to the PCE mailing list explaining why. If the chairs hear no objections by 
Monday, July 8th, we will kick off the early allocation request.

 

Note that there was an earlier allocation request where some codepoints were 
already allocated by IANA - 
https://mailarchive.ietf.org/arch/msg/pce/8jv4slxI_K3p4qqUPRlAjSgScOA/

Thanks!
Dhruv & Julien

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: WGLC for draft-ietf-pce-pcep-color-04

[Adrian Farrel]

Hi,

 

I support publication of this document, but I think there are some

issues that need to be resolved first. See below.

 

Cheers,

Adrian

 

===

 

Because of the (obvious) risk of confusion of what is meant by "color",

I tried to unpick the references. The important text is in the

Introduction...

 

   This color attribute is used as a guiding criterion for mapping

   services onto the TE tunnel or policy ([RFC9012]).  The term color

   used in this document is not to be interpreted as the 'thread color'

   specified in [RFC3063] or the 'resource color' (or 'link color')

   specified in [RFC3630], [RFC5329], [RFC5305] and [RFC7308].

 

   Color is part of the tuple that identifies a Segment Routing (SR)

   policy ([RFC9256]) and is included in the Path Computation Element

   Protocol (PCEP) extensions defined for carrying the SR policy

   identifiers ([I-D.ietf-pce-segment-routing-policy-cp]).  The color

   encoding specified in SR policy identifier cannot be reused for other

   types of path setup.

 

The first paragraph is clear. And I had a quick re-read of 9012 to

establish the meaning. The key text there is, "The color value is user

defined and configured locally." 9012 does not mention "policy" in the

sense you use it here.

 

The second paragraph is less clear to me. It seems to limit the scope of

"color" to SR, but given the first paragraph, I'm hoping that is not the

intent. Additionally, I think that the final sentence is probably 

outside the scope of this document. Perhaps what you are trying to do

would be better as...

 

   This color attribute is used as a guiding criterion for mapping

   services onto the TE tunnel [RFC9012] or Segment Routing (SR) policy

   [RFC9256].  The term color used in this document is not to be

   interpreted as the 'thread color' specified in [RFC3063] or the

   'resource color' (or 'link color') specified in [RFC3630], [RFC5329],

   [RFC5305] and [RFC7308].

 

   In an SR network, color is part to the tuple that identifies an SR

   policy and is included in the Path Computation Element Protocol 

   (PCEP) extensions defined for carrying the SR policy identifiers

   ([I-D.ietf-pce-segment-routing-policy-cp]).

 

---

 

The final paragraph of the Introduction is interestingly forward-

looking. While the SR composite candidate paths use case has a 

pointer to an I-D that normatively relies on this draft, the second 

use case (reference a set of path constraints and optimization

criteria) is unexplained and unsubstantiated by a reference. I suggest

to drop it rather than provide a shopping list of potential use cases

that might or might not have any meaning.

 

---

 

Why does this document reference RFC 7525 and not RFC 9325 (see idnits)?

 

---

 

Section 2 discusses "service prefixes" and "service route" but provides

no explanation or reference. I think these terms a loaded and need to be

explained.

 

And, for example, you have:

   BGP Color Extended Community is commonly used to perform service

   mapping, although this specification does not mandate its usage.

But 9012 doesn't mention a "service" or "mapping" at all. 

 

---

 

There is a mismatch in Section 3. You have:

 

   The STATEFUL-PCE-CAPABILITY negotiation message is enhanced to carry

   the color capability, which allows PCC (Path Computation Client) and

   PCE (Path Computation Element) to determine how incompatibility

   should be handled, should only one of them support color.  An older

   implementation that does not recognize the new color TLV would ignore

   it upon receipt.  This can sometimes result in undesirable behavior.

   For example, if PCE passes color to a PCC that does not understand

   colors, the LSP may not be used as intended.  

 

But, you immediately counter this with:

 

   A PCE that has color capability MUST NOT send color TLV to a PCC that

   does not have color capability.  A PCE that does not have color

   capability can ignore color marking reported by PCC.

 

So, if the second paragraph is true, then the problem pointed out in

the first paragraph never arises.

 

---

 

Section 3 has:

 

   The color TLV

   is ignored if it shows up in the LSP Object of a message where the

   PCEP Path Setup Type [RFC8408] is Segment Routing or SRv6.

 

This seems to contradict the text in the Introduction that says:

 

   Color is part of the tuple that identifies a Segment Routing (SR)

   policy ([RFC9256]) and is included in the Path Computation Element

   Protocol (PCEP) extensions defined for carrying the SR policy

   identifiers ([I-D.ietf-pce-segment-routing-policy-cp]).

 

If the sole purpose of this document is to assign colors to RSVP-TE

LSPs, then fix the title, abstract, and introduction. If SR is supposed

to be in scope, then explain how this is done.

 

---

 

In section 3:

 

   If a PCC is unable to honor a color value passed in an LSP Update

   request, the PCC must keep the 

[Pce] Re: WG Adoption of draft-li-pce-controlled-id-space-16

[Adrian Farrel]

Hi,

 

Thanks for this relatively simple document. I suspect it provides a function 
that will be useful.

 

I do have some thoughts, however.

 

The Abstract says “This document describes a generic mechanism” but the 
document actually seems to have nothing generic in it and requires a new TLV 
for each new identifier space. I wondered if you might make it more generic by 
having a single TLV that includes:
-  Identifier type (e.g., MPLS label, SRv6 SID, …)
-  Identifier-type-specific data (64 bits can be unused or could 
contain the SRv6 SID structure) 
o   Alternatively, Identifier-type-specific data length + variable 
Identifier-type-specific data.
-  Range information
o   Format depends on the Identifier type
But, perhaps the point is that the PCC might want to report more than one 
identifier space in the same Open Message?
 
I did also start to worry about the size of this TLV. It could get pretty ugly 
in the (unlikely?) case that the PCC says all odd numbers are available, but 
all even numbers are unavailable.
This sent me to RFC 3473 and the Label Set object for GMPLS. We might have a 
look to see if there is anything to learn (especially about the options for 
include/exclude).
 

Anyway, these are technical details. They can be fixed in WG discussion.

 

Cheers,

Adrian

 

From: Dhruv Dhody  
Sent: 17 May 2024 12:10
To: pce@ietf.org
Cc: pce-chairs ; draft-li-pce-controlled-id-sp...@ietf.org
Subject: [Pce] WG Adoption of draft-li-pce-controlled-id-space-16

 

Hi WG,

This email begins the WG adoption poll for draft-li-pce-controlled-id-space-16

https://datatracker.ietf.org/doc/draft-li-pce-controlled-id-space/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 3rd June 2024.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien

___
Pce mailing list -- pce@ietf.org
To unsubscribe send an email to pce-le...@ietf.org

[Pce] Re: Changes for PCEP-LS IANA Considerations

[Adrian Farrel]

OK.

I chatted with the AD who skimmed the existing text and the registries.

To my (pleasant) surprise, he says he thinks that the current text is fine and 
that we are OK to have an Experimental I-D request code points from an “IETF 
Review” range in a registry notwithstanding the existence of an “Experimental 
Use” range in the same registry.

 

So, I guess I retract my suggested changes.

 

Cheers,

Adrian

 

From: Adrian Farrel  
Sent: 08 May 2024 09:07
To: 'Dhruv Dhody' 
Cc: draft-ietf-pce-pcep...@ietf.org; pce@ietf.org
Subject: [Pce] Re: Changes for PCEP-LS IANA Considerations

 

Thanks Dhruv,

 

--> WG: Dhruv and I chatted about this a bit in private. I am not convinced 
that the IESG will be happy with this, so I am asking the AD for an opinion.

 

FWIW, I don’t understand why the registries have Experimental Use ranges if the 
intention is to allow Experimental RFCs to assign code points from the normal 
ranges.

 

We’ll keep you posted about this.

 

Cheers,

Adrian

 

From: Dhruv Dhody  
Sent: 08 May 2024 05:56
To: adr...@olddog.co.uk
Cc: draft-ietf-pce-pcep...@ietf.org; pce@ietf.org
Subject: Re: [Pce] Changes for PCEP-LS IANA Considerations

 

Hi Adrian, 

 

Thanks for providing suggested changes but I would like to keep the IANA 
considerations as it is and allocate from the 'IETF Review' codespace which 
allows any type of RFC including experimental. I found some recent experimental 
RFCs - 9531 and 9268 that follow the same approach. 

 

Thanks!

Dhruv  

 

On Mon, May 6, 2024 at 3:04 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Hi,

Thanks for posting the adopted draft.

I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.

Cheers,
Adrian

===

New section...

6.2.  Experimental Error-Types and Error-Values

   This experiment uses a single Experimental Use error-type 
   [I-D.farrel-pce-experimental-errors] to indicate 'PCEP-LS Error' to
   cover all experimental error cases. The value used needs to be
   consistent between all partners in the experiment, and 
   implementations would ideally make it configurable.

   The following error-values apply to this experimental error-type.

   Error-Value | Meaning
   +
 1 | LS Synchronisation Error: Error in processing the LSRpt
 2 | LS Synchronisation Error: Internal PCC error   
 3 | Mandatory object missing: LS object missing
 4 | Invalid Operation: Attempted LS Report if LS remote
   | capability was not advertised  

---   

New section...

6.3.   Experimental PCEP TLV Types 

   This document uses a number of experimental PCEP TLVs. Values are
   chosen from the Experimental Use range. The values used need to be
   consistent between all partners in the experiment, and 
   implementations would ideally make them configurable.

   For clarity in the document, the TLVs are indicated using the tags
   EXPx for different values of x, as follows.

   Value  | Meaning 
   ---+
EXP5  | LS-CAPABILITY TLV  
EXP7  | ROUTING-UNIVERSE TLV   
EXP8  | Local Node Descriptors TLV 
EXP9  | Remote Node Descriptors TLV
EXP10 | Link Descriptors TLV   
EXP11 | Prefix Descriptors TLV 
EXP12 | Node Attributes TLV
EXP13 | Link Attributes TLV
EXP14 | Prefix Attributes TLV  
EXP15 | ROUTE-DISTINGUISHER TLV

---

Throughout the document, make the following changes

TBD5  --> EXP5 
TBD7  --> EXP7 
TBD8  --> EXP8 
TBD9  --> EXP9 
TBD10 --> EXP10
TBD11 --> EXP11
TBD12 --> EXP12
TBD13 --> EXP13
TBD14 --> EXP14
TBD15 --> EXP15

---

6.2

OLD
   The LS reports sent by PCC MAY carry the remote link-state (and TE)
   information learned via existing means like IGP and BGP-LS only if
   both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
   to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
   reports carry remote link-state (and TE) information, then a PCErr
   with error-type 19 (Invalid Operation) and error-value TBD1
   (Attempted LS Report if LS remote capability was not advertised) and
   it will terminate the PCEP session.
NEW
   The LS reports sent by PCC MAY carry the remote link-state (and TE)
   information learned via existing means like IGP and BGP-LS only if
   both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
   to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
   reports carry remote link-state (and TE) information, then a PCErr
   with the experimental error-type (PCEP-LS Error) and error-value
   (Attempted LS Report if LS remote capability was not advertised) and
   it will terminate the PCEP session.
END

---

6.3

OLD
   If the PCC encou

[Pce] Re: Changes for PCEP-LS IANA Considerations

[Adrian Farrel]

Thanks Dhruv,

 

--> WG: Dhruv and I chatted about this a bit in private. I am not convinced 
that the IESG will be happy with this, so I am asking the AD for an opinion.

 

FWIW, I don’t understand why the registries have Experimental Use ranges if the 
intention is to allow Experimental RFCs to assign code points from the normal 
ranges.

 

We’ll keep you posted about this.

 

Cheers,

Adrian

 

From: Dhruv Dhody  
Sent: 08 May 2024 05:56
To: adr...@olddog.co.uk
Cc: draft-ietf-pce-pcep...@ietf.org; pce@ietf.org
Subject: Re: [Pce] Changes for PCEP-LS IANA Considerations

 

Hi Adrian, 

 

Thanks for providing suggested changes but I would like to keep the IANA 
considerations as it is and allocate from the 'IETF Review' codespace which 
allows any type of RFC including experimental. I found some recent experimental 
RFCs - 9531 and 9268 that follow the same approach. 

 

Thanks!

Dhruv  

 

On Mon, May 6, 2024 at 3:04 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Hi,

Thanks for posting the adopted draft.

I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.

Cheers,
Adrian

===

New section...

6.2.  Experimental Error-Types and Error-Values

   This experiment uses a single Experimental Use error-type 
   [I-D.farrel-pce-experimental-errors] to indicate 'PCEP-LS Error' to
   cover all experimental error cases. The value used needs to be
   consistent between all partners in the experiment, and 
   implementations would ideally make it configurable.

   The following error-values apply to this experimental error-type.

   Error-Value | Meaning
   +
 1 | LS Synchronisation Error: Error in processing the LSRpt
 2 | LS Synchronisation Error: Internal PCC error   
 3 | Mandatory object missing: LS object missing
 4 | Invalid Operation: Attempted LS Report if LS remote
   | capability was not advertised  

---   

New section...

6.3.   Experimental PCEP TLV Types 

   This document uses a number of experimental PCEP TLVs. Values are
   chosen from the Experimental Use range. The values used need to be
   consistent between all partners in the experiment, and 
   implementations would ideally make them configurable.

   For clarity in the document, the TLVs are indicated using the tags
   EXPx for different values of x, as follows.

   Value  | Meaning 
   ---+
EXP5  | LS-CAPABILITY TLV  
EXP7  | ROUTING-UNIVERSE TLV   
EXP8  | Local Node Descriptors TLV 
EXP9  | Remote Node Descriptors TLV
EXP10 | Link Descriptors TLV   
EXP11 | Prefix Descriptors TLV 
EXP12 | Node Attributes TLV
EXP13 | Link Attributes TLV
EXP14 | Prefix Attributes TLV  
EXP15 | ROUTE-DISTINGUISHER TLV

---

Throughout the document, make the following changes

TBD5  --> EXP5 
TBD7  --> EXP7 
TBD8  --> EXP8 
TBD9  --> EXP9 
TBD10 --> EXP10
TBD11 --> EXP11
TBD12 --> EXP12
TBD13 --> EXP13
TBD14 --> EXP14
TBD15 --> EXP15

---

6.2

OLD
   The LS reports sent by PCC MAY carry the remote link-state (and TE)
   information learned via existing means like IGP and BGP-LS only if
   both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
   to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
   reports carry remote link-state (and TE) information, then a PCErr
   with error-type 19 (Invalid Operation) and error-value TBD1
   (Attempted LS Report if LS remote capability was not advertised) and
   it will terminate the PCEP session.
NEW
   The LS reports sent by PCC MAY carry the remote link-state (and TE)
   information learned via existing means like IGP and BGP-LS only if
   both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
   to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
   reports carry remote link-state (and TE) information, then a PCErr
   with the experimental error-type (PCEP-LS Error) and error-value
   (Attempted LS Report if LS remote capability was not advertised) and
   it will terminate the PCEP session.
END

---

6.3

OLD
   If the PCC encounters a problem which prevents it from completing the
   LS synchronization, it MUST send a PCErr message with error-type TBD2
   (LS Synchronization Error) and error-value 2 (indicating an internal
   PCC error) to the PCE and terminate the session.
NEW
   If the PCC encounters a problem which prevents it from completing the
   LS synchronization, it MUST send a PCErr message with the
   experimental error-type (PCEP-LS Error) and error-value 2 (LS
   Synchronization Error: Internal PCC error) to the PCE and terminate 
   the session.
END

---

6.3

OLD
   The PCE does not send positive acknowled

[Pce] Changes for PCEP-LS IANA Considerations

[Adrian Farrel]

Hi,

Thanks for posting the adopted draft.

I think we need to make the following changes so catch all of the IANA
issues associated with being Experimental.

Cheers,
Adrian

===

New section...

6.2.  Experimental Error-Types and Error-Values
   
   This experiment uses a single Experimental Use error-type 
   [I-D.farrel-pce-experimental-errors] to indicate 'PCEP-LS Error' to
   cover all experimental error cases. The value used needs to be
   consistent between all partners in the experiment, and 
   implementations would ideally make it configurable.

   The following error-values apply to this experimental error-type.

   Error-Value | Meaning
   +
 1 | LS Synchronisation Error: Error in processing the LSRpt
 2 | LS Synchronisation Error: Internal PCC error   
 3 | Mandatory object missing: LS object missing
 4 | Invalid Operation: Attempted LS Report if LS remote
   | capability was not advertised  

---   

New section...

6.3.   Experimental PCEP TLV Types 

   This document uses a number of experimental PCEP TLVs. Values are
   chosen from the Experimental Use range. The values used need to be
   consistent between all partners in the experiment, and 
   implementations would ideally make them configurable.

   For clarity in the document, the TLVs are indicated using the tags
   EXPx for different values of x, as follows.

   Value  | Meaning 
   ---+
EXP5  | LS-CAPABILITY TLV  
EXP7  | ROUTING-UNIVERSE TLV   
EXP8  | Local Node Descriptors TLV 
EXP9  | Remote Node Descriptors TLV
EXP10 | Link Descriptors TLV   
EXP11 | Prefix Descriptors TLV 
EXP12 | Node Attributes TLV
EXP13 | Link Attributes TLV
EXP14 | Prefix Attributes TLV  
EXP15 | ROUTE-DISTINGUISHER TLV

---

Throughout the document, make the following changes

TBD5  --> EXP5 
TBD7  --> EXP7 
TBD8  --> EXP8 
TBD9  --> EXP9 
TBD10 --> EXP10
TBD11 --> EXP11
TBD12 --> EXP12
TBD13 --> EXP13
TBD14 --> EXP14
TBD15 --> EXP15

---

6.2

OLD
   The LS reports sent by PCC MAY carry the remote link-state (and TE)
   information learned via existing means like IGP and BGP-LS only if
   both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
   to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
   reports carry remote link-state (and TE) information, then a PCErr
   with error-type 19 (Invalid Operation) and error-value TBD1
   (Attempted LS Report if LS remote capability was not advertised) and
   it will terminate the PCEP session.
NEW
   The LS reports sent by PCC MAY carry the remote link-state (and TE)
   information learned via existing means like IGP and BGP-LS only if
   both PCEP Speakers set the R (remote) Flag in the "LS Capability" TLV
   to 'Remote Allowed (R Flag = 1)'.  If this is not the case and LS
   reports carry remote link-state (and TE) information, then a PCErr
   with the experimental error-type (PCEP-LS Error) and error-value
   (Attempted LS Report if LS remote capability was not advertised) and
   it will terminate the PCEP session.
END

---

6.3

OLD
   If the PCC encounters a problem which prevents it from completing the
   LS synchronization, it MUST send a PCErr message with error-type TBD2
   (LS Synchronization Error) and error-value 2 (indicating an internal
   PCC error) to the PCE and terminate the session.
NEW
   If the PCC encounters a problem which prevents it from completing the
   LS synchronization, it MUST send a PCErr message with the
   experimental error-type (PCEP-LS Error) and error-value 2 (LS
   Synchronization Error: Internal PCC error) to the PCE and terminate 
   the session.
END

---

6.3

OLD
   The PCE does not send positive acknowledgments for properly received
   LS synchronization messages.  It MUST respond with a PCErr message
   with error-type TBD2 (LS Synchronization Error) and error-value 1
   (indicating an error in processing the LSRpt) if it encounters a
   problem with the LS Report it received from the PCC and it MUST
   terminate the session.
NEW
   The PCE does not send positive acknowledgments for properly received
   LS synchronization messages.  It MUST respond with a PCErr message
   with with the experimental error-type (PCEP-LS Error) and error-value
   1 (LS Synchronization Error: Error in processing the LSRpt) if it
   encounters a problem with the LS Report it received from the PCC and
   it MUST terminate the session.
END

---

8.1

OLD
   The Message-Type field of the PCEP common header for the
   LSRpt message is set to [TBD3].
NEW
   The Message-Type field of the PCEP common header for the
   LSRpt message is set to a value from the range of Experimental Use
   message types. The value used needs to be consistent between all
   partners in 

Re: [Pce] Adoption Poll for draft-dhodylee-pce-pcep-ls

[Adrian Farrel]

 
 
  
   Thanks, Julien.
   
  
    
   
  
   Once upon a time, I was quite skeptical about this idea, and unhappy to see it progress. But I have become used to the idea, and two things help me believe we should adopt this:
   
  
    
   
  
   1. As an Experiment, this can be tried out and we can see how well it works. If it is nonsense, no harm done. The authors' willingness to proceed as Experimental is reassuring.
   
  
    
   
  
   2. The applicability to optical networks (separate draft) is convincing because it is easier to believe that optical devices do not want to add BGP-LS to their code stack (even if it is only a couple of thpusand lines of code).
   
  
    
   
  
   So, I support adoption and commit to working with the authors to improve the draft.
   
  
    
   
  
   I think the current description of the Experiment is pretty good, but work will be needed to sort out the IANA stuff. I just posted a draft to help with Experimental Error-Types.
   
  
    
   
  
   Best,
   
  
   Adrian
   
   
   
On 04/04/2024 18:18 CEST julien.meu...@orange.com wrote:

   
 

   
 

   
Hi all,

   
 

   
We have a long history around PCEP-LS. The rough consensus has been to

   
progress it as experimental within the PCE WG, which makes more sense

   
than an independent submission.

   
As a result, do you support draft-dhodylee-pce-pcep-ls-27 [1] to become

   
a PCE WG document? Please share your feedback using the PCE mailing

   
list, including your comments and especially your rationales in case

   
you're opposed.

   
 

   
Thank you,

   
 

   
Julien

   
 

   
---

   
[1] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/

   
 

   
___

   
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] New I-D on Experimental PCEP Error codes

[Adrian Farrel]

Hi PCE,

After some discussions with Dhruv about how and why we wrote RFC 8356,
Haomian and I have posted a new draft to allow Experimental error codes in
PCEP.

In summary, 8356 created space for Experimental PCEP messages, objects,
TLVs.
The assumption (see Appendix A) was that you could do anything experimental
using these three elements, and nothing further was needed.
This was true to some extent, but we have been concerned about the case of
carrying Error-Types and Error-values in experiments.
It could be possible for the experiment to define its own new object (say
the "Experimental-PCEP-Error Object") and use that to carry experimental
errors.
However, we felt that that would make it harder to migrate an experiment to
the standards track in the fullness of time.
So this I-D creates space for Experimental Error-Types to be carried in the
PCEP-Error Object.
Note that it does not create space for Experimental Error-values within the
existing Error-Types - we think that is unnecessary and would make the
registry messy.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-farrel-pce-experimental-errors/ 

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-farrel-pce-experimental-errors-0
0 

Please have a look and tell us if you think this is a good idea or a waste
of time.
FWIW, we believe we would use it in completing the work to move the PCEP-LS
draft to be fully Experimental.

Cheers,
Adrian (and Haomian)


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] 2nd WGLC for draft-ietf-pce-pceps-tls13

[Adrian Farrel]

Hi,

I've read the new version of this draft.

I think it is ready for publication, but you have used smart quotes for
the apostrophes in the Abstract and Introduction.

Thanks for all the work.

Adrian

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: 09 November 2023 17:13
To: pce@ietf.org
Subject: [Pce] 2nd WGLC for draft-ietf-pce-pceps-tls13

Dear PCE WG,

As suggested by Sean during the WG meeting today, this message starts a 
2nd WG last call on draft-ietf-pce-pceps-tls13-02 [1]. Please, express 
any comments you have about the latest revision of this document (diff 
in [2]) using the PCE mailing list..

This WGLC will end on Friday 24th November 2023.

Thanks,

Julien

--
[1] https://datatracker.ietf.org/doc/draft-ietf-pce-pceps-tls13/
[2] 
https://author-tools.ietf.org/iddiff?url1=draft-ietf-pce-pceps-tls13-01
=draft-ietf-pce-pceps-tls13-02=--html



Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
___
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 Adoption of draft-chen-pce-bier-11

[Adrian Farrel]

Thanks Ran,

 

I’ll try to get to that soon.

 

Adrian

 

From: chen@zte.com.cn  
Sent: 01 October 2023 18:42
To: d...@dhruvdhody.com; adr...@olddog.co.uk
Cc: pce@ietf.org; draft-chen-pce-b...@ietf.org
Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11

 

Hi Dhruv，

Thanks for reminding me.

To Adian,

We have just published the new version 
https://datatracker.ietf.org/doc/draft-chen-pce-bier/ based on your comments   
. Please review the updates. Thanks!

 

Best Regards,

Ran

Original

From: DhruvDhody 

To: 陈然00080434;

Cc: adr...@olddog.co.uk ;pce@ietf.org 
;draft-chen-pce-b...@ietf.org ;

Date: 2023年10月01日 22:04

Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11

HI Chen, 

 

If the WG Adoption passes, we can change that name of the draft at the time of 
adoption (i.e. publish  draft-ietf-pce-bier-te-00). There is no need for you to 
create a new draft with a name change while the adoption poll is ongoing! 

 

Thanks! 

Dhruv

 

On Sun, Oct 1, 2023 at 3:19 PM mailto:chen@zte.com.cn> > wrote:

Hi Adian,

Many thanks for your comprehensive and helpful review. 

We have just published the new version draft-chen-pce-bier-te-00，which include 
all your comments. 

Since the name of the draft has been updated based on the opinions of Jeffery 
and Nils, it needs to be reviewed by the chairman before it can be seen on the 
IETF page. Please check back later.

Please, See inline for detailed response...

 

 

Original

From: AdrianFarrel mailto:adr...@olddog.co.uk> >

To: 'Dhruv Dhody' mailto:d...@dhruvdhody.com> 
>;pce@ietf.org   mailto:pce@ietf.org> >;

Cc: draft-chen-pce-b...@ietf.org   
mailto:draft-chen-pce-b...@ietf.org> >;

Date: 2023年09月29日 05:45

Subject: Re: [Pce] WG Adoption of draft-chen-pce-bier-11

___
Pce mailing list
Pce@ietf.org  
https://www.ietf.org/mailman/listinfo/pce

Hi,

 

I have no objection to the working group taking on this draft although

I suspect that the community of interest is quite small, so there is

some concern about proper review and WG consensus. Hopefully this

adoption poll will secure a few promises of future review.

 

A few editorial points, below.

 

Cheers,

Adrian

 

===

 

Can we please get out of the habit of bring drafts up for adoption with

more than five authors on the front page. They will never get as far as

RFCs like that, and it seems unreasonable to ask the working group

chairs to appoint document editors after adoption - the authors should

sort this out for themselves.

 

[Ran]: Sure. We will communicate with the authors. Since China is on National 
Day holiday, so can we deal with it later?

---

 

Please run idnits and clean up the document. It would have been easy to

do this before requesting adoption.

[Ran] Done.

---

 

Please use the correct boilerplate in Section 2.

 [Ran] Done.

---

 

Section 3 has

   BIER-TE computed by a PCE can be represented in the

   following forms:

but then there is only one form shown.

 [Ran] Done. Changed to : BIER-TE computed by a PCE can be represented as:

The previous version defined three forms, but after discussion, only one was 
retained.

---

 

Several of the new TLVs etc. have bit-flag fields with bits defined.

Please consider whether you need to ask IANA to create registries to

track further bit assignments. If you don't need registries, why do

you need whole fields?

[Ran] Done. Already applied for iana allocation for bits.

---

 

6.2

 

You should give some clues about the value of the Length field since you

know what values it might have. Also, I presume that the Length field

could tell you a lot about the BFR prefix.

 

But, also, you say it is one octet, and you show it as 16 bits.

[Ran] Done. Changed to 2 octet. Consistent with the type and length of other 
TLVs of the LSP objet.

---

 

6.2

 

If the tunnel identifier is 11 or 23 octets then the TLV is not a

multiple of 4 (which is usually the case for PCEP TLVs). Is it padded

or what?

[Ran] Done. Added padding field.

---

 

6.3

 

  In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be

  contained in RP/SRP object.

 

Not sure that this document is needed to set up anything with BIER-TE.

It is just something that you can use.

[Ran]: It can easily identify that the path that needs to be established is a 
BIER-TE path. 

Similar to SR, SRv6 defines new PATH-SETUP-TYPE TLV  contained in RP/SRP object.

---

 

6.6

 

Could you abbreviate "ERO Object" as EROO?  ;-)

[Ran] Done.

---

 

6.6.1

 

The definition of "Adjacency BitString" seems to indicate that any

number of bits can be present. But the description of "Length" says that

the TLV length must be a multiple of 4 octets. How is the TLV padded?

[Ran] The TLV is added the "Reserved" field to pad.

 

How does someone reading the TLV know where the bit string stops?

[Ran] Done.  Added some 

Re: [Pce] WG Adoption of draft-chen-pce-bier-11

[Adrian Farrel]

Hi,

 

I have no objection to the working group taking on this draft although

I suspect that the community of interest is quite small, so there is

some concern about proper review and WG consensus. Hopefully this

adoption poll will secure a few promises of future review.

 

A few editorial points, below.

 

Cheers,

Adrian

 

===

 

Can we please get out of the habit of bring drafts up for adoption with

more than five authors on the front page. They will never get as far as

RFCs like that, and it seems unreasonable to ask the working group

chairs to appoint document editors after adoption - the authors should

sort this out for themselves.

 

---

 

Please run idnits and clean up the document. It would have been easy to

do this before requesting adoption.

 

---

 

Please use the correct boilerplate in Section 2.

 

---

 

Section 3 has

   BIER-TE computed by a PCE can be represented in the

   following forms:

but then there is only one form shown.

 

---

 

Several of the new TLVs etc. have bit-flag fields with bits defined.

Please consider whether you need to ask IANA to create registries to

track further bit assignments. If you don't need registries, why do

you need whole fields?

 

---

 

6.2

 

You should give some clues about the value of the Length field since you

know what values it might have. Also, I presume that the Length field

could tell you a lot about the BFR prefix.

 

But, also, you say it is one octet, and you show it as 16 bits.

 

---

 

6.2

 

If the tunnel identifier is 11 or 23 octets then the TLV is not a

multiple of 4 (which is usually the case for PCEP TLVs). Is it padded

or what?

 

---

 

6.3

 

   In order to setup an BIER-TE, a new PATH-SETUP-TYPE TLV MUST be

   contained in RP/SRP object.

 

Not sure that this document is needed to set up anything with BIER-TE.

It is just something that you can use.

 

---

 

6.6

 

Could you abbreviate "ERO Object" as EROO?  ;-)

 

---

 

6.6.1

 

The definition of "Adjacency BitString" seems to indicate that any 

number of bits can be present. But the description of "Length" says that

the TLV length must be a multiple of 4 octets. How is the TLV padded? 

How does someone reading the TLV know where the bit string stops?

 

---

 

Section 6.7 has same issues as 6.6

 

---

 

Is Section 8 correct? It says:

 

   IANA has registered the code points for the protocol elements defined

   in this document.

 

But I don't think those have been registered.

 

From: Pce  On Behalf Of Dhruv Dhody
Sent: 25 September 2023 17:49
To: pce@ietf.org
Cc: draft-chen-pce-b...@ietf.org
Subject: [Pce] WG Adoption of draft-chen-pce-bier-11

 

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-bier-11.

https://datatracker.ietf.org/doc/draft-chen-pce-bier/

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 9th Oct 2023.

Please be more vocal during WG polls!

Thanks!
Dhruv & Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-pcep-extension-native-ip-20

[Adrian Farrel]

 
 
  
   In the past, I would have agreed with Tom on this.
   
  
    
   
  
   But we are routinely seeing a pause of more than 200 days between a WG issuing a Publication Request and the AD starting their review (which leads to updates and discussion before IETF last call). IANA don't do their provisional assignments until IETF last call.
   
  
    
   
  
   If there are implementations of what is presumably a stable draft, I think early assignment is reasonable. It shouldn't take more than 10 minutes of the chairs' and AD'S time.
   
  
    
   
  
   Cheers,
   
  
   Adrian
   
   
   
On 24/05/2023 16:33 BST tom petch  wrote:

   
 

   
 

   
From: Aijun Wang 

   
Sent: 24 May 2023 16:02

   
 

   
As I remember, it is the IANA first allocate the necessary values, then go to the RFCEditor.

   
 

   
Can we ask the IANA to (early) allocate the value now?

   
 

   


   
At this stage in the process, I doubt if it is worth the extra work. Such a request goes via chairs and AD. I see it more when users want to implement and it may be some time before the I-D gets to the stage that this one is now at. And later reviews - Last Call, IESG - may come up with changes to the TBDnnn that then confuse the picture. I prefer the 'normal' process but with perhaps a bit more of a nudge to the RFC Editor to make sure that they pick up all the usages e.g. pointing out to the RFC Editor up front or in the IANA Considerations that there are many TBDnn in the body of the I-D.

   
 

   
Thinking about it, I am a bit hazy on the normal process between IANA and RFC Editor. The e-mails that I see are when things go wrong and either the RFC Editor or IANA (or both) are unclear as to what is intended and need guidance from the WG

   
 

   
Tom Petch

   
 

   
Aijun Wang

   
China Telecom

   
 



 On May 24, 2023, at 17:12, tom petch  wrote:
 

  
 

 From: Aijun Wang 
 

 Sent: 23 May 2023 07:59
 

  
 

 Hi, Tom:
 

  
 

 Thanks for your review.
 

  
 

 I have uploaded the new version to address your comments.
 

  
 

 I am trying to find some more convenient methods to describe the un-allocated "TBDnnn" from the IANA. Do you have any suggestions that can't be "too easy to miss"?
 

  
 

 My purpose is that once the IANA allocates the value to each of these values according to our requests (https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-native-ip-21#section-14)
 

  
 

 , I can replace them easily in the updated version.
 

  
 

 
 

  
 

 Mmm I did look at other I-D for another way but think that this is unusual in the number of TBDnnn in the body of the I-D, not in the IANA Considerations. I did not see a request for early allocation so the values will not be assigned until the I-D is about to leave the RFC Editor Queue so it is the RFC Editor, not you, who has to find all the instances of TBDnnn and replace them. Common practice is to add a
 

 -- Note to the RFC Editor
 

 in each and every place where such action is needed outside the IANA Considerations. There are a lot of them; 44 I think. I think that at least there should be a Note to the RFC Editor in IANA Considerations to the effect that these values appear in many places and need editing.
 

  
 

 I will post separately a concern about BGP session setup.
 

  
 

 Tom Petch
 

  
 

  
 

 For the interaction between BGP and PCEP, we think the paces or procedures described in this document can be controlled by the PCE--Once the PCE sends the command to PCC, it will collect the status of such command. Only when the previous command is executed successfully, then the next command can be issued. Section 6 cover the descriptions of main procedures.
 

  
 

 For your other comments, please see replies inline.
 

  
 

  
 

  
 

 Huaimo also gives us more valuable suggestions to refine the document offline. I have also incorporated them together in the updated version.
 

  
 

  
 

  
 

 Thanks all you together!
 

  
 

  
 

  
 

 Future reviews from other experts can be based on the updated version.
 

  
 

  
 

  
 

  
 

  
 

 Best Regards
 

  
 

Re: [Pce] Adoption Poll for draft-dhody-pce-pceps-tls13-02

[Adrian Farrel]

Hey Julian.

Yes, let's move this little draft forward quickly and ensure PCEP can be as
secure as possible.

A

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: 27 March 2023 10:49
To: pce@ietf.org
Subject: [Pce] Adoption Poll for draft-dhody-pce-pceps-tls13-02

Dear WG,

During the PCE session today, there was clear support behind the PCEPS 
updates I-D. Let's take it to the next level: do you consider that 
draft-dhody-pce-pceps-tls13-02 should be adopted as a PCE WG item?

Please, share your answer and any detailed feedback using the PCE 
mailing list.

Thanks,

Julien



_

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

___
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-ipv6-15

[Adrian Farrel]

> Many thanks for your comments, I have accepted most of the comments 
> from you, and would like to discuss with you about the rest. Please see my
> reply inline.

Great. Thanks, Cheng. Continuing the discussion in line.
Snipped all of the resolved stuff.

> Because we have a lots of comments. It may be good to address them
> by several updates. So we can close completed comments and work on
> the remain ones.

Of course.
I'm sure you can be relied on to keep track of what you still have to
address.

A

===

4.1.1

   If a PCEP speaker includes PST=3 (early allocated by
   IANA) in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it
   MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH-
   SETUP-TYPE-CAPABILITY TLV.

Two questions:

   a. What happens if PST=3 is present but SRv6-PCE-CAPABILITY is
  missing?

   b. What happens if SRv6-PCE-CAPABILITY is present, but PST=3 was not
  included? (You don't say that that is not allowed.)

It's possible that a forward pointer to Section 5 is enough (I didn't
cross-check this).

[CL] It seems like we need to specify the details of error handling.

[AF] Right! 3% of the function, 30% of the text ;-)

---

4.3.1  Flags

A pointer to Section 9.2 would be useful.
[CL] May not need to do so. Too many pointers I think.

[AF] Well, OK. I won't insist.

---

4.3.1

What is the interaction between the L flag in the subobject header and the S
bit in the Flags field?
[CL] L flag is for loose path. S flag is saying that the SID value is
absent. The PCC may allocate a value according to the NAI.

[AF] I see...

   The 'L' Flag: Indicates whether the subobject represents a loose-hop
   (see [RFC3209]).  If this flag is set to zero, a PCC MUST NOT
   overwrite the SID value present in the SRv6-ERO subobject.
   Otherwise, a PCC MAY expand or replace one or more SID values in the
   received SRv6-ERO based on its local policy.

...and...

   *  S: When this bit is set to 1, the SRv6-SID value in the subobject
  body is absent.  In this case, the PCC is responsible for choosing
  the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI
  which, in this case, MUST be present in the subobject.  If the S
  bit is set to 1 then F bit MUST be set to zero.

How can you overwrite the SID value in the SRv6-ERO subobject if it is
absent?

---

4.3.1 / 4.3.1.1

Figure 2 shows the "SID Structure" field as 32 bits, but Figure 3 is pretty
clear that it is 64 bits. I think Figure 2 is broken.

[AF] You didn't comment, but I think it is an easy fix.

---

4.4.1

Is the SRv6-SID field optional in the RRO subobject? The figure implies it
must be present, and that would seem pretty reasonable for an RRO.
But the text says all the fields are exactly as in the ERO, and the S flag
seems to still have meaning.

There is the same problem with the length of the SID structure field.
[Cheng] I think you are right, it must be present. So we will not need
S-flag any more. Let's see how to handle this.

[AF] OK. Awaiting dsicussions.

---


5.1

   If a PCE
   receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then
   it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that
   the sender can impose any length of SRH.

Is that really "MUST assume" or just "may assume"?  That would seem to be
consistent with...

   However, if a PCE learns these via different means, e.g
   routing protocols, as specified in:
   [I-D.ietf-lsr-ospfv3-srv6-extensions];
   [I-D.ietf-lsr-isis-srv6-extensions]; [I-D.ietf-idr-bgpls-srv6-ext],
   then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV.

But there's a hole :-( If we follow the previous paragraph, the PCE may send
an ERO with more SIDs than allowed by the MSD in the Open message (if the
value learned from the IGP is a larger number. But...

   If a PCEP
   session is established with a non-zero SRv6 MSD value, and the PCC
   receives an SRv6 path containing more SIDs than specified in the SRv6
   MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr
   message with Error-Type = 10 (Reception of an invalid object) and
   Error-Value = TBD1 (Unsupported number of SRv6-ERO subobjects).

...says that regardless of the MSD in the IGP, the PCC must reject an ERO
that contains more SIDs that specified in the Open message.

Furthermore, you have...

   If a PCC receives a list of SRv6 segments, and the number of SRv6
   segments exceeds the SRv6 MSD that the PCC can impose on the packet
   (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception
   of an invalid object") and Error-Value = TBD5 ("Unsupported number of
   SRv6-ERO subobjects") as per [RFC8664].

This last paragraph seems to cover all bases, so why not just use it?
[Cheng] em, what do you mean just use it? 

[AF] I mean, rely only on that last paragraph and delete all of the other
text that seems to be confused or contradictory.

---

5.1

There seems to be a contradiction about the MSD 0 case.

You 

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Adrian Farrel]

Hi again, Dhruv.

 

Still not pushing this idea, but still trying to make sure it is correctly 
understood….

 

Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths for other uses they should use a new PCEP ERO
and RRO Object-Type and a new registry of subobjects. In many ways, that
would be so much cleaner, but it would break RFC 8664 implementations.

Dhruv: (also addressing Huaimo), to me this is a bit overkill. We would need to 
update a lot of documents. 

Of course if the situation changes nothing would stop us from moving in this 
direction in future, but I dont think we are there yet!  

[AF] I don’t believe “a lot of documents” would need to be updated.

You wouldn’t be changing the fact that it is an ERO. You’d keep the same Object 
Class value. You’d just be changing the Object Type used in the case of SR. 

So none of the legacy documents that refer to the inclusion of an ERO would 
change.

AFAICS it would be just 8664 that would be changed.

 

Dhruv: I misunderstood then! You were suggesting that the subobjects shared by 
PCEP and RSVP-TE still remain in the old registry and subobjects only used in 
PCEP go into a brand new registry! Hmmm But ERO could have subobjects from 
both registries and that would make it weird. That is why I thought we were 
suggesting a fresh new PCEP registry for all subobjects used in PCEP. 

 

I kinda still feel its overkill :)

 

[AF2] Yes, but going a step further.

The PCEP objects have two identifier fields (just like RSVP): the Object-Class 
and the Object-Type.

The Object-Class identifies the sort of object. Thus, ERO = 7, RRO = 8.

The Object-Type indicates the type of use that the object is put to. There are 
15 values available. 

In general, PCEP objects all use Object-Type = 1.

But some objects (such as END-POINTS and BANDWIDTH) have a small number of 
Object-Types available.

The Object-Type says “I know what sort of object I am handling and what it is 
for, but I need more information to understand the encoding and use case.”

 

So, my suggestion was to use Object-Class=7, Object-Type=1 for G/MPLS LSP EROs 
(signaled or manually provisioned), and Object-Class=7, Object-Type=2 for SR 
paths.

(You could even go Object-Type=2 for SR-MPLS and Object-Type=3 for SRv6. 
Further, since RFC 8664 is already published, we could leave SR-MPLS alone, and 
just go straight to Object-Type=3 for SRv6 in this document.)

The subobjects for Object-Type != 3 are those defined in this document: namely 
SR-ERO. And they could come from a new registry.

This would have no impact on the existing EROs and so no changes to the 
existing registry.

 

Cheers,

Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Adrian Farrel]

Looks like I was somewhat right with “unpopular” 

 

Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths for other uses they should use a new PCEP ERO
and RRO Object-Type and a new registry of subobjects. In many ways, that
would be so much cleaner, but it would break RFC 8664 implementations.

 

Dhruv: (also addressing Huaimo), to me this is a bit overkill. We would need to 
update a lot of documents. 

Of course if the situation changes nothing would stop us from moving in this 
direction in future, but I dont think we are there yet!  

 

[AF] I don’t believe “a lot of documents” would need to be updated.

You wouldn’t be changing the fact that it is an ERO. You’d keep the same Object 
Class value. You’d just be changing the Object Type used in the case of SR. 

So none of the legacy documents that refer to the inclusion of an ERO would 
change.

AFAICS it would be just 8664 that would be changed.

 

[AF] I’m not lobbying for this (despite it being the “right thing to do”), but 
let’s make any decisions based on a balanced view.

 

Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-ipv6-15

[Adrian Farrel]

Hi,

Here is my WG last call review of this document. Thanks to the authors
for all of the work that has gone in.

[A note for the chairs: Was this last call shared with SPRING?]

Cheers,
Adrian

===

Abstract

   The Source Packet Routing in Networking (SPRING) architecture

In fact, although RFCs 7855, 8354, and 8355 talk about "Source Packet
Routing in Networking (SPRING)", the architecture document (RFC 8402)
is the "Segment Routing Architecture."

---

Abstract

   It depends only on "segments"

As it is a new paragraph, you need to clarify what "it" is. Or maybe
move this sentence to the previous paragraph so that para 2 begins "A
Segment Routed Path..."

---

Abstract

s/forwarding plane/forwarding planes/(twice)
s/support for IPv6 data plane in/support for the IPv6 data plane in the/

---

Abstract

OLD
   The PCEP extension and mechanism to support SR-MPLS
   is described in RFC 8664.
NEW
   The PCEP extensions and mechanisms to support SR-MPLS
   are described in RFC 8664.
END

---

Abstract

I think the final sentence is superfluous (or confusing).
Probably this is a repeat of "This document describes the extensions
required for SR support for IPv6 data plane in Path Computation Element
communication Protocol (PCEP)."

---

1.

s/Locater/Locator/
s/The list of segment/The list of segments/

---

1.

   Upon completion of a segment, a pointer in the new
   routing header is incremented and indicates the next segment.

Not so new anymore!
Try...

   Upon completion of a segment, a pointer in the SRH
   is incremented and indicates the next segment.

---

1.

   Segment Routing use cases are described in [RFC7855] and [RFC8354].
   Segment Routing protocol extensions are defined in [RFC8667], and
   [RFC8666].

There is nothing untrue in this paragraph. But what does it add? The use
cases aren't mentioned anywhere in the document, and the protocol
elements aren't used.

I'd just remove the paragraph.

---

1.

   As per [RFC8754], an SRv6 Segment identifier is an 128-bit value.
   "SRv6 SID" or simply "SID" are often used as a shorter reference for
   "SRv6 Segment".  Further details are in an illustration provided in
   [RFC8986].

This duplicates and somewhat modifies where the first paragraph says...

   An ordered list of segments
   is encoded as an ordered list of IPv6 addresses in the routing
   header.

I suggest you try to fold this short paragraph into the first paragraph
and clarify the difference between "an 128-bit value" and "IPv6 address"

---

1.

   The SR is applied to IPV6 forwarding
   plane using Source Routing Header (SRH) [RFC8754].

You've already said this in the first paragraph

---

1.

   A SR path can be
   derived from an IGP Shortest Path Tree (SPT), but SR-TE paths may not
   follow IGP SPT.

a. You have just introduced "SR-TE". You need to expand it as "Segment
   Routing Traffic-Engineering".

b. Is there actually any difference between an SR path and an SR-TE 
   path? If so, you might add it to Section 2 after the definition of
   "SR Path".

c. Notwithstanding RFC 8664, s/may/might/ to avoid confusion with the
   normal English "you may not do it!"

---

1.

s/SR-TE LSP for MPLS data plane/SR-TE LSP for the MPLS data plane/
s/support SR for IPv6 data plane/support SR for the IPv6 data plane/
s/either stateful or a stateless PCE/either a stateful or stateless PCE/

---

2.

s/equivalent to a SRv6 Path/equivalent to an SRv6 Path/

---

3.

s/operations for PCEP speakers is/operations for PCEP speakers are/

---

3.

   SR-capable PCEP speakers should be able to generate and/or process
   such an ERO subobject.

"should be able to" ??

Maybe...

   SR-capable PCEP speakers can generate or process
   such an ERO subobject.

---

3.

   This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in the
   ERO and the RRO respectively to carry the SRv6 SID (IPv6 Address).

Should the previous paragraph have talked about the RRO?

---

3.1

   In SR networks, an ingress node of an SR path appends all outgoing
   packets with an SR header consisting of a list of SIDs (IPv6 Prefix
   in case of SRv6).

a. s/SR header/SRH/

b. The SRH is only used for SRv6, so this text is a bit mixed-up

c. Isn't there technically a case where only one SID is present so the
   SRH is not needed (the SID is put in the DA field of the 
   encapsulating IPv6 header)?

---

3.1

OLD
   For the use of IPv6 in control plane only with MPLS data plane,
   mechanism remains the same as specified in [RFC8664].
NEW
   For the use of an IPv6 control plane but an MPLS data plane, the
   mechanism remains the same as specified in [RFC8664].
END

---

3.1

   This document describes an extension to the SR path for the IPv6 data
   plane.

It does? I thought it was all about PCEP.

---

3.1 seems to have some duplication of content from Section 3.

---

4.1.1

To avoid any risk of stale text persisting into the RFC (and given 
that you have this covered in the IANA section)...

OLD
   *  PST = 3 

[Pce] A small issue with the use of ERO and RRO in RSVP-TE and PCEP

[Adrian Farrel]

Hi,

You may recall that, back in the early days, the plan for PCEP was that it
was used to determine the paths that were to be signalled in MPLS-TE and to
report on those paths.

To that end, the ERO and RRO in PCEP messages follow the same construction
as those used in RSVP-TE. That is, they are made up of an ordered list of
subobjects as specified in the IANA registries for RSVP
(https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp
-parameters-25 and
https://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xhtml#rsvp-
parameters-26)

RFC 5440 says of the PCEP objects that, "PCEP ERO sub-object types
correspond to RSVP-TE ERO sub-object types," and that, "Since the explicit
path is available for immediate signaling by the MPLS or GMPLS control
plane, the meanings of all of the sub-objects and fields in this object are
identical to those defined for the ERO."

We should also consider that the two registries reference RFC 3209, and also
RFC 7571 (for the ERO) to describe the meaning of the registries. Of course,
individual subobjects in the registries also reference the RFCs that define
those subobjects, but there is (I think) an assumption that the registries
list subobjects that can be used in RSVP-TE signaling.

Now (finally) to the point.

PCEP is being used for determining paths in Segment Routing networks. SR (of
course) does not use RSVP-TE signaling, but there is still a desire to
describe paths to be used and that have been used. To achieve that, RFC 8664
(for SR-MPLS) and draft-ietf-pce-segment-routing-ipv6 (for SRv6) have
defined the use of the PCEP ERO and RRO for SR paths. In doing so, they
needed to define new subobjects (to contain SR-MPLS SIDs and SRv6 SIDs)
within the ERO and RRO.

This led to those subobjects being added to the RSVP-TE IANA registries
(using IANA early allocation in the case of
draft-ietf-pce-segment-routing-ipv6).

This leaves me a bit uneasy.

While the entries for draft-ietf-pce-segment-routing-ipv6 (#40 for SRv6)
show "(PCEP-specific)" the entry for RFC 8664 (#36 for SR) don't say
anything extra. Of course, there are references to the defining documents,
but neither document mentions what happens when those subobjects are found
in an RSVP-TE message. Nothing tells an RSVP-TE implementer what to expect
with these subobjects.

This problem propagates to the SERO and SRRO in RSVP-TE since they inherit
subobjects from the ERO and RRO.

Possibly, this is all covered by RFC 3209 section 4.3.4.1 step 1) and should
result in a "Routing Problem" error code with "Bad initial subobject" error
value. In this case, there is not so much for me to worry about and
(perhaps) we just need to:

1. Fix the registries to say "(PCEP only)" for #36. I think an AD action can
do this without the need to write any drafts, etc.
2. Decide it is too late to put any note in RFC 8664 to clarify that the #36
subobjects are not for use in RSVP-TE.
3. Add a note to draft-ietf-segment-routing-ipv6 to say that the #40
subobjects are not for use in RSVP-TE.
4. Consider whether there is a need to document that the registries have
entries that are only for PCEP. A way to do this would be a short draft to
add two columns to the registries and populate them for existing subobjects
to show "may be used in RSVP-TE" and "may be used in PCEP". I'd be willing
to write that up.

Of course an (unpopular) option would be to tell the PCE WG that it is not
acceptable to use the RSVP-TE registries in this way, and let them know that
if they want to specify paths for other uses they should use a new PCEP ERO
and RRO Object-Type and a new registry of subobjects. In many ways, that
would be so much cleaner, but it would break RFC 8664 implementations.

Opinions?

Cheers,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Adoption of draft-dhody-pce-pcep-extension-pce-controller-srv6

[Adrian Farrel]

Hi,

Tl;dr  I support the adoption of this draft.

As a co-author of RFC 8283, I take an interest in this work and the
wider applicability of PCECC. I've also been interested in how SID
allocation is coordinated, and this seems like a reasonable solution.

Given that we have procedures and protocol extensions for PCECC with
SR-MPLS, it seems pragmatic to also have them for SRv6.

Some comments and nits below, none of which needs to be actioned before
adoption.

Best,
Adrian

===

Abstract

Suggest a paragraph break before "This document"

---

Abstract

You nicely introduce PCE and PCECC, but don't introduce SR. There is,
perhaps, a sentence or two in the Introduction you could borrow...


   Segment Routing (SR) technology leverages the source routing and
   tunneling paradigms.  Each path is specified as a set of "segments" 
   encoded in the header of each packet as a list of Segment Identifiers
   (SIDs).

You'd then tidy up the subsequent text since there is no need to 
expand the abbreviations twice.

---

Abstract

s/SDN and/SDN/
s/in the for /in the/

---

1.

Although PCEP is expanded in the Abstract, you need to expand it on
first use in the main body of text.

---

1.

s/introduction to SR/introduction to the SR/
a/[RFC8665] ,/[RFC8665],/

---

1.
OLD
   [RFC8283] introduces the architecture for PCE as a central controller
NEW
   [RFC8283] introduces the architecture for PCE as a central controller
   (PCECC)
END

---

1.

   It relies on a
   series of forwarding instructions being placed in the header of a
   packet.  The list of segments forming the path is called the Segment
   List and is encoded in the packet header.

You say "in the packet header" twice.

---

1.

   PCECC may further use PCEP for SR SID (Segment Identifier) allocation
   and distribution to all the SR nodes with some benefits.  

Hmmm. Not sure PCEP is use for allocation. Maybe it is open for 
interpretation, but possibly...

   The PCECC may perform centralized allocation of SR Segment 
   Identifiers (SIDs) and use PCEP to distribute them to the SR nodes.

---

1.

   [I-D.ietf-pce-pcep-extension-pce-controller-sr] specifies the
   procedures and PCEP extensions when a PCE-based controller is also
   responsible for configuring the forwarding actions on the routers
   (SR-MPLS SID distribution), in addition to computing the paths for
   packet flows in a segment routing network and telling the edge
   routers what instructions to attach to packets as they enter the
   network.  This document extends this to include SRv6 SID distribution
   as well.

Big question first. I know the history that led us to have one I-D for
SR-MPLS and one for SRv6. The question is whether we still need to have
that, or we should adopt this document and them move for a merger so 
that the is just one draft for PCECC-SR. I assume that the philosophy of
the PCEP extensions are the same, and that it is just the encoding of
SIDs that differs. (See also the end of Section 3.)

And then, a rewrite for clarity...

   A PCE-based central controller may be responsible for computing the 
   paths for packet flows in an MPLS Segment Routing (SR-MPLS) network
   and for telling the edge routers what instructions to attach to
   packets as they enter the network.  [I-D.ietf-pce-pcep-extension-pce-
   controller-sr] specifies the procedures and PCEP extensions when a
   PCE-based controller is additionally responsible for configuring the
   forwarding actions on routers in an SR-MPLS network (i.e., for SR-
   MPLS SID distribution).  This document extends those procedures to
   include SRv6 SID distribution as well.

---

2.

s/in the document/in/

---

3.

   An
   ingress node of an SR-TE path appends all outgoing packets with a
   list of MPLS labels (SIDs).

I don't think "append" is quite the right word. It has implications of
"attach to the end of". Perhaps...

   An
   ingress node of an SR-TE path includes a list of MPLS labels (SIDs)
   in all outgoing packets.

---

3.

OLD
   The SR is applied to IPv6 data plane using SRH.
NEW
   SR is applied to the IPv6 data plane using the SRH.
END

---

3.

s/paths may not follow IGP SPT/paths might not follow the IGP SPT/
s/specify the SRv6-ERO/specifies the SRv6-ERO/
s/and assume/and assuming/
s/Further Section 3/Further, Section 3/
s/describe the implications/describes the implications/

---

3.

   The operator needs to evaluate the advantages offered by PCECC
   against the operational and scalability needs of the PCECC.

Maybe add a forward pointer to Section 9.6?

---

3.

OLD
   As per [RFC8283], PCECC can allocate and provision the node/prefix/
   adjacency label (SID) via PCEP.
NEW
   As per [RFC8283], the PCECC can allocate the node/prefix/adjacency 
   label (SID) and provision them via PCEP.
END

---

4.

s/between the PCE to the PCC/between the PCE and the PCC/

---

5.2

The material in this section is all good, but I think the flow is wrong.
Perhaps...

OLD
   This document uses the same 

Re: [Pce] Scoping Items from draft-koldychev-pce-operational

[Adrian Farrel]

As promised, I’m commenting into this thread as well. Picking Dhruv’s email 
from the thread because it best captures my feelings on the work.

 

As I noted in the review I just posted, there seem to be a few (small but 
important) clarifications and changes to the previous specs that need to be 
presented concisely and clearly. And there is quite a lot of text that is 
either discussion, or just observations from experience of what people built 
and tried to make work.

 

I would suggest that a first step might be to rearrange this document to make 
clear to the reader which parts are “updates” of existing RFCs (and group them 
together), and which parts are commentary.

 

As to Tom’s point: yes, we can never be sure that more issues won’t be found 
(although the number of interoperating implementations is growing). Correlation 
is often achieved successfully through the “updates” metadata, but when the 
number of changes gets large, we simply “obsolete” with a cleaned-up version. I 
guess there is a middle option where the “updating” RFC is “obsoleted” to 
reflect a larger collection of “updates”.

 

To Siva’s comment that this document “sheds light on the inter-op issues 
encountered at various multivendor public/private inter-op events”, I think 
that can be a valuable informational piece of work – it might make an interop 
report from the events, or it might result in an Informational RFC, or even a 
section on the PCE WG/community wiki. But formal updates to existing RFCs 
don’t, IMHO, fall into the category Siva describes. Which leads me to Andrew’s 
comment that the document “tweaks” the standards and that “the proposed updates 
to the PCEP standard are not "major" updates” and “The line between updating 
the standard vs clarifying the standard can be blurry in some cases.” If you 
are making a change to the procedures that an implementation follows, you are 
changing the specification and this must not be blurry – a clear and crisp 
statement is needed.

 
Hint: What is the cost of two documents compared to the price of wrangling one 
document that does several things?
 

Ciao,

Adrian

 

From: Pce  On Behalf Of Dhruv Dhody
Sent: 10 November 2022 22:53
To: julien.meu...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] Scoping Items from draft-koldychev-pce-operational

 

Hi, 

 

It is likely I might be rough on this, but wanted to put my thoughts on the 
list as well (I said as much in the last IETF meeting). 

 

My preference (as a WG participant) is for two documents -

(1) A very small standards track I-D that updates RFC 8231 with clear old/new 
text on what is being updated

(2) A larger informational I-D that matches the name "operational 
clarification" on how things works with figures and explanations  

 

For (1) see RFC 8786 as reference! For (2) see RFC 6007 as a clarification 
document for SVEC. 

 

IMHO this separation and clear focused I-D serve the WG well :)

 

We can discuss this during the WG session tomorrow! I have added it to the WG 
chairs slide as a discussion point! 

 

Thanks! 

Dhruv 

 

On Thu, Sep 29, 2022 at 9:37 AM mailto:julien.meu...@orange.com> > wrote:

Dear PCE WG,

Let's follow up on the discussion started during IETF 114 about 
draft-koldychev-pce-operational [1]. The I-D currently tackles different 
issues about PCEP, some of them being informational, some other updating 
existing PCEP specifications. Among the options we discussed to proceed 
with this work, 2 remain:
1. Keep a single draft, but clearly separate the two types of content;
2. Break it up into 2 drafts.

We'd like to hear the WG's opinion whether you prefer:
a- a single standard track I-D, with both content types sharing fate 
until publication?
b- a clarification I-D on informational track + an I-D updating PCEP on 
standard track (possibly progressing at different paces)?

Please share your feedback using the PCE mailing list.

Thanks,

Dhruv & Julien


[1] https://datatracker.ietf.org/doc/draft-koldychev-pce-operational/


___
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] A further review of draft-koldychev-pce-operational

[Adrian Farrel]

Hi,

This is another fly-by review as I just saw the new revision of the 
draft pop up. I think it is important and helpful that implementers of
IETF protocol work get together to document their experiences with the
technology, so thanks to the authors for their work.

However, I am concerned when implementers try to require other 
implementers to not make the same internal design mistakes that their
friends may have made. We do not need to tell people how to write code,
only how to ensure interoperability.

This document seems to be a mixture of changes to the specifications
(not all of which I agree are the right way of doing things), 
observations on how you might implement internal data structures or
stores, and observations on how protocol exchanges work. I wonder how
much of that needs to be in an IETF Standards Track document.

I'm going to respond separately on
https://mailarchive.ietf.org/arch/msg/pce/skstm9VsYiHOpjlQkQVBuBxE1xg/
because there seems to be some overlap with my previous concern and the
discussion there.

More detailed comments below.

Thanks for your work implementing and testing PCE.

Best,
Adrian

== Significant ==

3.1

   LSP-DB contains two types of objects: LSPs and Tunnels.  An LSP is
   identified by the LSP-IDENTIFIERS TLV.  A Tunnel is identified by the
   PLSP-ID in the LSP object and/or the SYMBOLIC-NAME.  See [RFC8231].

While I can appreciate that there is a need to correlate between LSPs
in the LSP-DB to know whether they are associated and to determine the
many different types of association (where sharing PLSP-ID is one such
association), I baulk at the idea that the LSP-DB contains Tunnels. Why
would it contain tunnels?

But more to the point, what is this section actually telling a PCE 
implementation? Is there some requirement that PCEs hold specific format
information?

---

3.2

   Both PCE and PCC maintain their separate copies of the LSP-DB.  The
   PCE LSP-DB is only modified by PCRpt messages, no other PCEP message
   may modify the PCE LSP-DB.  The PCC LSP-DB is built from actual
   forwarding state that PCC has installed.  PCC uses PCRpt messages to
   synchronize its local LSP-DB to the PCE.

Why must the PCC maintain a copy of the LSP-DB? Especially after the 
PCRpt has been sent? I mean, it may do (especially if the PCC is the 
head end of a soft state protocol, or if the PCC is responsible for
imposing the path information on every packet), but why is this a PCE
requirement?

---

3.2

   The PCE MUST always act on the latest state of the PCE LSP DB.

Why "MUST"?
- Is this a quote from somewhere or are you updating a specification?
- Why is the PCE not at liberty to perform "crooked" path computations?
- In what way is this an interop issue?

---

3.2

   The LSP-DB on both the PCC and the PCE only stores the actual state
   in the network, it does not store the desired state.

I agree that the PCE's LSP DB needs to store the actual state in the
network. Why, however, do you mandate that it cannot also store the
desired state? 

In the case of multiple simultaneous transitions of related LSPs it
could be very useful to know both the current and intended states.

And anyway, why is this an interop issue?

---

3.3.1

While I can accept that the change you describe reflects what has been
implemented (and it is very important to document when we have multiple
interoperable implementations), it seems to me that you could equally 
have used "PCReq with delegation" whereby a PCC would ask for a
computation and delegate in one go. This would make the PCRpt always
say what is in the network, and the PCReq always request an explicit
action from the PCE. (I suppose I'm a little grumpy that you have "Hey,
this is what we built, so standardise it" approach to consensus.)

I would note that under previous definitions, a PCE receiving a PCRpt
with delegation is not obliged to actually do anything! It can, of
course, issue an update in a new PCUpd whenever it wants, but it is not
obliged to unless it thinks it is the right time. This, I think, is what
lies behind the text you quote from 8231. You are changing this by 
saying that a PCRpt with no ERO or an empty ERO has an explicit meaning
equivalent to explicitly requesting PCE action.

Before closing on this (and acknowledging that I prefer my proposal :-)
I'd like you to think about whether a PCRpt with an empty ERO might 
sometimes be totally valid in the  of a PCRpt. For 
example, if a PCC (for whatever reason) launched a path into the network
without an ERO (say it's using RSVP-TE) and learns the installed path
from the RRO, then wouldn't the subsequent delegation look like "empty
ERO with full RRO" (i.e., empty  with full
)? In that case, are you actually asking the PCE to 
immediately compute a path and issue PCUpd? Maybe you are. Maybe you 
want the PCE to pin the path that has previously be soft-computed in the
network. But will it pick that one (looking at the RRO) or will it look
at the empty ERO and 

Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13

[Adrian Farrel]

Wfm, thnx

-Original Message-
From: Russ Housley  
Sent: 14 October 2022 14:58
To: Adrian Farrel 
Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
Subject: Re: Thinking about draft-dhody-pce-pceps-tls13

Maybe the phrase should be: PCEP implementations that support TLS 1.3 MUST
...

Russ

> On Oct 14, 2022, at 9:28 AM, Adrian Farrel  wrote:
> 
> Thanks, Rus.
> 
> What I didn't express well (don't write emails when you have been doing
hard
> concentration work for 9.5 hours straight!) is that it is possible to
think
> that this work is telling all PCEP implementations what they must do. I
have
> spoken to one person who was very worried that this was updating what
their
> existing implementation would need to do.
> 
> I'm clear that the intention is to describe what PCEPS implementations
that
> support TLS 1.3 are supposed to do, and that doesn't have any knock-on for
> other work, but, yes, a very simple addition of "of this specification"
> makes all the concerns go away.
> 
> Cheers,
> Adrian
> 
> -Original Message-
> From: Russ Housley  
> Sent: 14 October 2022 13:46
> To: Adrian Farrel 
> Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
> Subject: Re: Thinking about draft-dhody-pce-pceps-tls13
> 
> Adrian:
> 
> TLS 1.2 does not have early data, and the algorithm registries arefor TLS
> 1.2 and TLS 1.3 are separate, o I do not think there is confusion.  That
> said, I do not object to adding the phrase.
> 
> Russ
> 
>> On Oct 13, 2022, at 5:42 PM, Adrian Farrel  wrote:
>> 
>> Hi,
>> 
>> Thanks for kicking off work to get PCEP able to work with TLS1.3.
>> 
>> This is important.
>> 
>> However... :-)
>> 
>> I think it would be helpful to clarify that statements about what
>> implementations must or must not do (etc.) should be scoped as
>> "implementations of this document." That is, you are not constraining
PCEP
>> implementations in general, and I don't even thing you are constraining
>> TLS1.2 PCEP implementations. Well, if it was your intent to do otherwise,
>> you really need to be clear that you are updating the base specs, but I
> hope
>> you're not.
>> 
>> Further, I am worried about the use of draft-ietf-tls-rfc8446bis as a
>> normative reference. I understand that the long term intention is that
> that
>> draft will obsolete RFC 8446, but it seems to be moving slowly (if at all
> -
>> it has expired). I think that implementers wanting to apply TLS1.3 to
> their
>> PCEP code will want to pick up TLS1.3 implementations that are stable
> (i.e.,
>> based on RFCs). Now, by the time this draft gets to completion, it is
> quite
>> possible that 8446bis will have completed, and the draft can be updated
to
>> reference it and pick any additional points it makes. On the other hand,
> if
>> this draft makes it to the RFC Editor queue before 8446bis is complete, I
>> don't think you'd want it to sit around, and a subsequent bis can be made
>> when 8446bis becomes an RFC.
>> 
>> What do you think?
>> 
>> Cheers,
>> Adrian
>> 
>> 
> 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Thinking about draft-dhody-pce-pceps-tls13

[Adrian Farrel]

Thanks, Rus.

What I didn't express well (don't write emails when you have been doing hard
concentration work for 9.5 hours straight!) is that it is possible to think
that this work is telling all PCEP implementations what they must do. I have
spoken to one person who was very worried that this was updating what their
existing implementation would need to do.

I'm clear that the intention is to describe what PCEPS implementations that
support TLS 1.3 are supposed to do, and that doesn't have any knock-on for
other work, but, yes, a very simple addition of "of this specification"
makes all the concerns go away.

Cheers,
Adrian

-Original Message-
From: Russ Housley  
Sent: 14 October 2022 13:46
To: Adrian Farrel 
Cc: draft-dhody-pce-pceps-tl...@ietf.org; pce@ietf.org
Subject: Re: Thinking about draft-dhody-pce-pceps-tls13

Adrian:

TLS 1.2 does not have early data, and the algorithm registries arefor TLS
1.2 and TLS 1.3 are separate, o I do not think there is confusion.  That
said, I do not object to adding the phrase.

Russ

> On Oct 13, 2022, at 5:42 PM, Adrian Farrel  wrote:
> 
> Hi,
> 
> Thanks for kicking off work to get PCEP able to work with TLS1.3.
> 
> This is important.
> 
> However... :-)
> 
> I think it would be helpful to clarify that statements about what
> implementations must or must not do (etc.) should be scoped as
> "implementations of this document." That is, you are not constraining PCEP
> implementations in general, and I don't even thing you are constraining
> TLS1.2 PCEP implementations. Well, if it was your intent to do otherwise,
> you really need to be clear that you are updating the base specs, but I
hope
> you're not.
> 
> Further, I am worried about the use of draft-ietf-tls-rfc8446bis as a
> normative reference. I understand that the long term intention is that
that
> draft will obsolete RFC 8446, but it seems to be moving slowly (if at all
-
> it has expired). I think that implementers wanting to apply TLS1.3 to
their
> PCEP code will want to pick up TLS1.3 implementations that are stable
(i.e.,
> based on RFCs). Now, by the time this draft gets to completion, it is
quite
> possible that 8446bis will have completed, and the draft can be updated to
> reference it and pick any additional points it makes. On the other hand,
if
> this draft makes it to the RFC Editor queue before 8446bis is complete, I
> don't think you'd want it to sit around, and a subsequent bis can be made
> when 8446bis becomes an RFC.
> 
> What do you think?
> 
> Cheers,
> Adrian
> 
> 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Thinking about draft-dhody-pce-pceps-tls13

[Adrian Farrel]

Hi,

Thanks for kicking off work to get PCEP able to work with TLS1.3.

This is important.

However... :-)

I think it would be helpful to clarify that statements about what
implementations must or must not do (etc.) should be scoped as
"implementations of this document." That is, you are not constraining PCEP
implementations in general, and I don't even thing you are constraining
TLS1.2 PCEP implementations. Well, if it was your intent to do otherwise,
you really need to be clear that you are updating the base specs, but I hope
you're not.

Further, I am worried about the use of draft-ietf-tls-rfc8446bis as a
normative reference. I understand that the long term intention is that that
draft will obsolete RFC 8446, but it seems to be moving slowly (if at all -
it has expired). I think that implementers wanting to apply TLS1.3 to their
PCEP code will want to pick up TLS1.3 implementations that are stable (i.e.,
based on RFCs). Now, by the time this draft gets to completion, it is quite
possible that 8446bis will have completed, and the draft can be updated to
reference it and pick any additional points it makes. On the other hand, if
this draft makes it to the RFC Editor queue before 8446bis is complete, I
don't think you'd want it to sit around, and a subsequent bis can be made
when 8446bis becomes an RFC.

What do you think?

Cheers,
Adrian


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

Yeah, I like that suggestion.
A

-Original Message-
From: Les Ginsberg (ginsberg)  
Sent: 04 October 2022 20:43
To: John Scudder 
Cc: Acee Lindem (acee) ; Lars Eggert ; The 
IESG ; draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; 
lsr-cha...@ietf.org; lsr ; pce@ietf.org; Hannes Gredler 
; JP Vasseur (jvasseur) ; 
meral.shirazip...@polymtl.ca; Adrian Farrel 
Subject: RE: [Lsr] Lars Eggert's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

John -

So you are suggesting that Section 4 of the draft be modified to say:

"This introduction of additional sub-TLVs should be viewed as an exception to 
the [RFC5088][RFC5089] policy, justified by the requirement to discover the 
PCEP security support prior to establishing a PCEP session. The restrictions 
defined in [RFC5089][RFC5089] should still be considered to be in place.
If in the future new advertisements are required, alternative mechanisms such 
as using [RFC6823] or 
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-transport-instance/ should 
be considered."

(or similar...)

I am fine with that.

   Les


> -Original Message-
> From: John Scudder 
> Sent: Tuesday, October 4, 2022 12:31 PM
> To: Les Ginsberg (ginsberg) 
> Cc: Acee Lindem (acee) ; Lars Eggert ;
> The IESG ; draft-ietf-lsr-pce-discovery-security-
> supp...@ietf.org; lsr-cha...@ietf.org; lsr ; pce@ietf.org;
> Hannes Gredler ; JP Vasseur (jvasseur)
> ; meral.shirazip...@polymtl.ca; Adrian Farrel
> 
> Subject: Re: [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-
> security-support-11: (with DISCUSS and COMMENT)
> 
> Hi Les,
> 
> Thanks, that’s helpful. One comment, regarding
> 
> > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to
> GENINFO/OSPF-GT even if such an addition might be relevant.
> 
> what I was actually suggesting was that the paragraph in draft-ietf-lsr-pce-
> discovery-security-support could be updated to add the pointer. Since draft-
> ietf-lsr-pce-discovery-security-support formally updates RFCs 5088/5089,
> that would establish at least some mechanism less unreliable than trolling
> through old mailing lists, to help a new implementor find this old history,
> while still not requiring us to do the heavy lift of bis’ing 5088/5089 (which 
> I
> agree would be crazy to do just for this).
> 
> —John
> 
> > On Oct 4, 2022, at 3:24 PM, Les Ginsberg (ginsberg) 
> wrote:
> >
> > John -
> >
> > Thanx for finding the old email thread.
> > Folks also might want to look at this thread:
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/lsr/Nhe
> zQqKwIvHK_9dDUmW0iuhyjDA/__;!!NEt6yMaO-gk!BsexV0igrfCC6797R-
> 5WEj654ycPt6DwvDJJ9cKMToAWSjm6GzCfKem3ylr0c4DezgdzY3N-mB2epg$
> >
> > In summary, I raised these points when the draft was adopted - but
> eventually agreed to allow the draft to go forward.
> >
> > The intent of the restrictions in RFC5088/5089 is to discourage carrying
> additional "non-routing" information in the IGPs.
> > The practical matter in this case is that trying to advertise the additional
> information using some other mechanism is quite costly and awkward. The
> fact that the additional information are sub-sub-TLVs of the PCED sub-TLV
> speaks to the coupling of the new information with the existing information.
> >
> > I think we want to keep restrictions in place so as to discourage new
> advertisements, but recognize that we compromise when it seems practical.
> This isn’t ideal - and I understand why Lars would want to discuss this - but 
> I
> don't have a cleaner solution.
> > The fact that we introduced PCE advertisements into the IGPs in the first
> place makes it difficult to adhere to the restrictions for PCE related
> advertisements.
> >
> > Section 4 of the draft states:
> >
> > "This introduction of additional sub-TLVs should be viewed as an exception
> to the [RFC5088][RFC5089] policy, justified by the requirement to discover
> the PCEP security support prior to establishing a PCEP session. The
> restrictions defined in [RFC5089][RFC5089] should still be considered to be in
> place."
> >
> > which is an accurate summary.
> >
> > Hard for me to justify modifying RFC 5088/5089 simply to add a pointer to
> GENINFO/OSPF-GT even if such an addition might be relevant.
> >
> >   Les
> >
> >> -Original Message-
> >> From: John Scudder 
> >> Sent: Tuesday, October 4, 2022 11:16 AM
> >> To: Acee Lindem (acee) 
> >> Cc: Lars Eggert ; The IESG ; draft-ietf-
> lsr-
> >> pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; lsr
> >> ; pce@ie

Re: [Pce] [Lsr] Lars Eggert's Discuss on draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

[Adrian Farrel]

Hi all,

I'm going to say what I can remember before I read the thread. I was PCE 
co-chair as this work went through.

There was a feeling that using the IGPs for carrying "stuff" was not a wise 
idea. It was one thing to exchange information that all participants in the 
protocol needed to perform the functions of the IGP, another to use the IGP for 
information that most of the routers would need to know, and not great to use 
the IGP for sharing information only some of the routers need to know.

The PCE capabilities exchange in the IGP was always a bit of a stretch. 
Learning of the existence of a PCE in a network of routers that all use the PCE 
function might be valuable thing (although there are many other ways to 
discover servers). And it may be helpful, when there are many PCEs available, 
to provide enough information to allow selection between servers. But that 
became a heavy load as more and more optional PCE features were added and the 
amount of information carried by the IGP was set to keep growing. The main 
worry was, of course, not the definition of a few additional bits, but the 
inclusion of additional TLVs.

Since PCEP has a mechanism for PCEs to advertise and negotiate their 
capabilities, and since the main discovery issues were already covered by the 
IGP work, it seemed reasonable to draw a line. We could have asked to take the 
new capabilities one by one, but it seemed like everyone's favourite capability 
was going to be argued as a special case, so we drew a very solid line and said 
"no new sub-TLVs". This rule allowed new flags (since there were plenty of 
unused flags available) and you can see how this has been used in the registry 
with another 8 flags defined by 5 RFCs).

Now, the question with this I-D is about whether the issues of protocol 
security are sufficiently special case to warrant allowing new TLVs in the IGP. 
And, in particular, if the capabilities exchange for security is left to the 
PCEP initialisation steps, are those steps secure enough to prevent downgrade 
attacks.

Cheers,
Adrian

-Original Message-
From: John Scudder  
Sent: 04 October 2022 18:29
To: Lars Eggert 
Cc: The IESG ; 
draft-ietf-lsr-pce-discovery-security-supp...@ietf.org; lsr-cha...@ietf.org; 
lsr ; Acee Lindem ; pce@ietf.org; Hannes Gredler 
; Les Ginsberg (ginsberg) ; 
jvass...@cisco.com; meral.shirazip...@polymtl.ca; Adrian Farrel 

Subject: Re: [Lsr] Lars Eggert's Discuss on 
draft-ietf-lsr-pce-discovery-security-support-11: (with DISCUSS and COMMENT)

Hi Everyone,

+Adrian since he appears to have been the shepherd for RFC 5088, which is the 
root of Lars’ DISCUSS.
+Hannes, Les, JP, Meral as people who may have more context on the question

Since I haven’t seen any replies to this DISCUSS yet I did a little digging. 
The text in question:

   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.

Was introduced in draft-ietf-pce-disco-proto-ospf-07, September 2007. Checking 
in the archives, I see one relevant mail thread: 
https://mailarchive.ietf.org/arch/msg/pce/UERk8vF5e7cFQoblkDAVA74Ojh0/ is the 
beginning, but then it seems to have been indexed wrong so you should continue 
from here: 
https://mailarchive.ietf.org/arch/msg/isis-wg/BpUVKsjr46ha9kbF3jwgKyymEBo/ to 
pick up Les’s reply as well. There are four relevant messages in total, from 
Meral Shirazipour, JP Vasseur, Hannes Gredler, and Les Ginsberg.

Rather than try to summarize I’m going to ask people to go look at the short 
mail thread for themselves. Perhaps this will jog people’s memories enough to 
allow a discussion on why we’re opening a registry for new code points that was 
explicitly defined as being closed.

Thanks,

—John

> On Sep 30, 2022, at 8:27 AM, Lars Eggert via Datatracker  
> wrote:
> 
> 
> Lars Eggert has entered the following ballot position for
> draft-ietf-lsr-pce-discovery-security-support-11: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt8J-BPa3$
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-lsr-pce-discovery-security-support/__;!!NEt6yMaO-gk!BEvEYiZR6x7lTVrU9AA55g6M1-32P6xLCiZ537k4RWeOwmTjkSrRmf0k6fDyFPdPOpbjt2I779yk$
> 
> 
&g

Re: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06

[Adrian Farrel]

Hi,

 

I read through this draft as part of the adoption poll.

 

I found it quite hard to work out from the Abstract what the purpose of

the document is. The Introduction is a little more informative, but also

quite hard work.

 

It turns out, when you read the document, that two things are being

defined:

1. A set of attributes to allow a PCE to instruct a PCC as to which IFIT

   behaviours it should enable on a path.

2. A capabilities flags so that a PCC can indicate which IFIT functions

   it supports.

 

I think the Abstract might usefully read as follows.

 

   In-situ Flow Information Telemetry (IFIT) refers to network OAM data

   plane on-path telemetry techniques, in particular In-situ OAM (IOAM)

   and Alternate Marking.

 

   This document defines PCEP extensions to allow a Path Computation 

   Client (PCC) to indicate which IFIT features it supports, and a Path 

   Computation Element (PCE) to configure IFIT behavior at a PCC for a

   specific path in the stateful PCE model.

 

   The PCEP extensions described in this document are defined for use

   with Segment Routing (SR). They could be generalized for all path 

   types, but that is out of scope of this document.

 

The Introduction might also usefully change in that way.

 

---

 

While I appreciate that the authors are primarily concerned with SR, I

think the WG should carefully consider taking the authors at their word

and pursuing the generalisation to all path types. That can't be much

additional work, and it would surely make sense to get the solution to

be generic from day one.

 

---

 

Please move the requirements language from the front-matter to its own

section (probably 1.1).

 

---

 

With the clarification of the intent of the document, I would support 

the working group working on this document, and it could be adopted.

 

Regards,

Adrian

 

From: Pce  On Behalf Of Dhruv Dhody
Sent: 24 June 2022 09:59
To: pce@ietf.org
Cc: draft-chen-pce-pcep-i...@ietf.org
Subject: [Pce] WG Adoption of draft-chen-pce-pcep-ifit-06

 

Hi WG,

This email begins the WG adoption poll for draft-chen-pce-pcep-ifit-06.

 

https://datatracker.ietf.org/doc/draft-chen-pce-pcep-ifit/

 

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

Please respond by Monday 11th July 2022.

 

Please be more vocal during WG polls! 

Thanks!
Dhruv & Julien

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Draft -06 available with most WG LC comments addressed//was: WGLC for draft-ietf-pce-vn-association-05

[Adrian Farrel]

Thanks Haomian,

 

Looking good.

 

Cut down to just a few open points.

 

Best,

Adrian

 

4. (for VIRTUAL-NETWORK-TLV)

 

   Length: Variable Length

 

Length of what and in what units?

Just the Virtual Network Name or the whole TLV?

Probably in octets.

What is the maximum allowed value? Surely not 2^16.

[Haomian]  propose as follow: 

 

OLD: 

Length: Variable Length

 

NEW:

Length: Variable Length, which covers all the Virtual Network Identifiers.

 

END

 

Was hoping for (if I have it right)…

Length: The length in octets of the Virtual Network Identifier, not including 
the Type or Length field.

 

BTW, is it a MUST to have a maximum value?

 

No, there is no such requirement. However, without setting one, you allow the 
Virtual Network Identifier to by 2^16 bytes long which would, I think, probably 
break the PCEP message.

 

Often, fields like this are limited to 255 bytes or something like that. But it 
can be let completely open so that the implementation can trade this field off 
against other message fields.

 

---

 

4.

 

How does internationalization work for the Virtual Network Name?

Why is ASCII acceptable?

[Haomian] not changed, looking for future advice. My personal taking is ‘all 
ASCII should find the same processing rule for internationalization’. 

 

OK. You could send a message to the internationalisation directorate ( 
 i18n...@ietf.org) to ask for advice, or you could 
leave this as it is and see whether the ADs have any concerns.

 

---

 

4.

 

Does the Virtual Network Name need to be unique across all VNAGs? I

suspect that it doesn't because its use is basically out of scope of

this work.

[Haomian]  propose as follow: 

OLD: 

Virtual Network Name (variable): an unique symbolic name for the VN.

NEW:

Virtual Network Identifier (variable): an symbolic name for the VN that is 
unique in this TLV.

END

 

OK, that is clear.

s/an/a/

 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] ASCII in PCEP (WAS - Re: WGLC for draft-ietf-pce-vn-association-05)

[Adrian Farrel]

Hi Dhruv,

 

I agree: this is a wider issue than just this draft. And I think it was 
discussed way back for some early part of the PCEP work, but I really can’t 
recall how or what the conclusions were.

 

The IETF has a Directorate for Internationalisation 
(https://datatracker.ietf.org/group/i18ndir/about/) and they should be able to 
help. Once upon a time I would have said, “Let’s meet up with a couple of them 
over coffee at the IETF and see if we can understand the problem space and 
scope. But we have a new normal, so probably the thing to do is ask the 
Directorate if they could supply one or two people to work with us on this and 
then set up a call after the IETF and after we have all got over the zoom-lag. 

 

At the moment I don’t even know what questions we should be asking each other!

 

A first step might be to collect all of the free-form text strings currently in 
PCEP and list out how they are used. Then we can have a starting point for a 
conversation.

 

Cheers,

Adrian

 

From: Dhruv Dhody  
Sent: 17 March 2022 05:20
To: Adrian Farrel 
Cc: pce@ietf.org; draft-ietf-pce-vn-associat...@ietf.org; pce-chairs 

Subject: ASCII in PCEP (WAS - Re: [Pce] WGLC for 
draft-ietf-pce-vn-association-05)

 

Hi Adrian, WG,

 

Just one point and starting a new thread -> 

 

 

4.

 

How does internationalization work for the Virtual Network Name?

Why is ASCII acceptable?

 

---

 

 

In the past, we had limited to ASCII, see SYMBOLIC-PATH-NAME TLV (RFC 8231). 

 

I see a recent discussion (but not sure if it is resolved yet) for the spring 
SR policy draft related to the same topic -  
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/ballot/
 (search for ASCII)

 

I think it is wise for PCE WG to think more about this -

- Do we continue to use ASCII only 

- Do we define strings as UTF-8 from now on and leave the old ones as ASCII 

- Do we make sure older names can be encoded in UTF-8 by defining a new TLV or 
some other technique? 

 

Thoughts? 

 

Thanks! 

Dhruv

 

 

 

From: Pce mailto:pce-boun...@ietf.org> > On Behalf Of 
Dhruv Dhody
Sent: 22 February 2022 12:18
To: pce@ietf.org <mailto:pce@ietf.org> 
Cc: draft-ietf-pce-vn-associat...@ietf.org 
<mailto:draft-ietf-pce-vn-associat...@ietf.org> ; pce-chairs 
mailto:pce-cha...@ietf.org> >
Subject: [Pce] WGLC for draft-ietf-pce-vn-association-05

 

Hi WG,

This email starts a 3-weeks working group last call for 
draft-ietf-pce-vn-association-05 [1 
<https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/> ] to 
accommodate the upcoming draft submission deadline.  

Please indicate your support or concern for this draft. If you are opposed to 
the progression of the draft to RFC, please articulate your concern. If you 
support it, please indicate that you have read the latest version and it is 
ready for publication in your opinion. As always, review comments and nits are 
most welcome. 

The WG LC will end on Tuesday 15th March 2022.

A general reminder to the WG to be more vocal during the last-call/adoption and 
help us unclog our queues :)  

Thanks,
Dhruv & Julien

[1] https://datatracker.ietf.org/doc/draft-ietf-pce-vn-association/

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WGLC for draft-ietf-pce-vn-association-05

[Adrian Farrel]

Hi,

 

Here is my review of draft-ietf-pce-vn-association-05 as part of the WG

last call.

 

I think the document is technically ready to proceed, but it needs quite

a bit of work to polish the text. After the number of edits I am 

proposing I feel like I have rewritten the document!

 

My comments are below.

 

Thanks,

Adrian

 

==Minor==

 

3.

 

   In order to set up the end-to-end tunnel, multiple segments need to

   be stitched, by the border nodes in each domain who receives the

   instruction from their child PCE (PNC).

 

What end-to-end tunnel? This has not been mentioned before and I can't 

see one in the figure.

 

---

 

3.

 

   Local polices on the PCE MAY define the computational and

   optimization behavior for the LSPs in the VN.

 

Why is this "MAY"? Isn't it good enough to write:

 

   Local polices on the PCE define the computational and

   optimization behavior for the LSPs in the VN.

 

---

 

3.

 

   If an implementation encounters more than one

   VNAG, it MUST consider the first occurrence and ignore the others.

 

I think...

 

   If an implementation encounters more than one

   VNAG object in a PCEP message, it MUST process the first occurrence 

   and it MUST ignore the others.

 

---

 

3.

 

   Operator-configured Association Range MUST NOT be set for this

   association-type and MUST be ignored.

 

I know what you are trying to say, but you have crossed the line into

describing implementations.

 

Perhaps

OLD

   This Association-Type is dynamic in nature and created by the Parent

   PCE (MDSC) for the LSPs belonging to the same VN or customer.  These

   associations are conveyed via PCEP messages to the PCEP peer.

   Operator-configured Association Range MUST NOT be set for this

   association-type and MUST be ignored.

NEW

   The Association IDs (VNAG IDs) for this Association Type are dynamic

   in nature and created by the Parent PCE (MDSC) for the LSPs belonging

   to the same VN or customer.  Operator configuration of VNAG IDs is 

   not supported so there is no need for an Operator-configured 

   Association Range to be set.  Thus, the VN Association Type (TBD1)

   MUST NOT be present in the Operator-Configured Association Range TLV

   if that TLV is present in the OPEN object.  If an implementation

   encounters the VN Association Type in an Operator-Configured

   Association Range TLV, it MUST ignore the associated Start-Assoc-ID

   and Range values.

END

 

---

 

4.

 

   o  VIRTUAL-NETWORK-TLV: Used to communicate the VN Identifier.

 

It is confusing that you say VN Identifier (which sounds like VNAG

identifier), but then the text and figure shows "VN name" or "Virtual

Network Name". You need to:

- select Identifier or Name

- select VN or Virtual Network

 

---

 

4. (for VIRTUAL-NETWORK-TLV)

 

   Length: Variable Length

 

Length of what and in what units?

Just the Virtual Network Name or the whole TLV?

Probably in octets.

What is the maximum allowed value? Surely not 2^16.

 

---

 

4.

 

How does internationalization work for the Virtual Network Name?

Why is ASCII acceptable?

 

---

 

4.

 

Does the Virtual Network Name need to be unique across all VNAGs? I

suspect that it doesn't because its use is basically out of scope of

this work.

 

---

 

Does section 5 add anything to the document? There has already been

discussion of parent and child PCEs and a lot of the material in this

section is a direct quote from elsewhere in the document.

 

I would suggest a very hard look to see whether anything needs to be

retained or the whole section can be removed.

 

---

 

9.6

 

I think the whole point of this document is to change network operations

 

---

 

==Nits==

 

LSP is going to need to be expanded on first use in each of:

- the document title

- the abstract

- section 1

 

---

 

Abstract

 

s/extend/extend the/

 

s/virtual network control/control of virtual networks/

 

s/using PCE/using the PCE/

 

---

 

1. para 1

 

Should include a reference to RFC 5440

 

 

OLD

   computations in response to Path Computation Clients' (PCCs)

   requests.

NEW

   computations in response to requests from Path Computation Clients

   (PCCs).

END

 

---

 

1.

 

OLD

   A stateful PCE has access to not only the information

   carried by the network's Interior Gateway Protocol (IGP), but also

   the set of active paths and their reserved resources for its

   computations.

NEW

   For its computations, a stateful PCE has access to not only the

   information carried by the network's Interior Gateway Protocol (IGP),

   but also the set of active paths and their reserved resources.

END

 

---

 

1.

 

s/to define association/to define associations/

 

---

 

ACTN needs to be expanded on first use.

 

---

 

1.

 

The last three paragraphs seem to introduce material in the wrong order.

I think you need four paragraphs:

 

- 8453, introduce ACTN and VN. 

Re: [Pce] I-D Action: draft-koldychev-pce-operational-05.txt

[Adrian Farrel]

Hi authors,

I really appreciate the work done through interop to better understand protocol 
specs and revise the protocol. I hope that you are not all talking yourselves 
into an interop mode that changes the specs because that seems to interoperate, 
rather than fixing implementations to conform to the current specs (which were 
thought about quite a bit ;-)

In the end, of course, we should document what is implemented and interoperates 
(provided it works!).

I did a very light skim of the document and I found a number of issues that 
concern me.

Best,
Adrian

---

In section 3 you have:
   We introduce the concept of the LSP-DB, as a database of actual LSP
   state in the network

I don't think you do 

You might start with RFC 7399 and RFC 8051.

Possibly you are introducing the concept of the PCC LSP-DB.

---

In section 3 you say

   The structure and format
   of the LSP-DB MUST be common among all dataplane types (i.e., RSVP-
   TE/SR-TE/SRv6), all instantiation methods (i.e., PCC-initiated/PCE-
   initiated), all destination types (i.e., point-to-point/point-to-
   multipoint).

This should be self-evidently wrong. The LSP-DB is internal to the PCE 
implementation, so while it is true that the PCE needs to be able to derive 
certain information from the LSP-DB, how it stores that information is 
completely its own business. Now, you may want an abstract representation in 
order to define your state machines, and that is fine, but please don't tell 
implementations how to implement.

---

In 3.2 you have

   The PCC adds/removes entries to/from its LSP-DB based on what LSPs it
   creates/destroys in the network.  There can be many trigger types for
   updating the PCC LSP-DB, some examples include PCUpd messages, local
   computation on the PCC, local configuration on the PCC, etc.  The
   trigger type does not affect the content of the PCC LSP-DB, i.e., the
   content of the PCC LSP-DB is updated identically regardless of the
   trigger type.

But surely a PCUpd message does not immediately affect the state of the LSP in 
the network. Depending on the signaling process and the processing at the PCC, 
that may take some time. So, you need to be careful when you include PCUpd as a 
trigger and then say that all trigger types are to be treated equally.

Later (in 3.2) you say:
   The LSP-DB on both the PCC and the PCE only stores the actual state
   in the network, it does not store the desired state.
Which seems to say that PCUpd is not a trigger.

In fact, the PCE and PCC need to store both the "currently believed current 
state" and the "state that is being attempted". How this state is stored is a 
very moot point because the LSP-DB is a logical concept. [In previous work] it 
expresses the information stored by the PCE about the active LSPs, but there is 
no such limit placed on what information about the active LSPs may be stored. 
Why not store the shoe size of the network operator's mother, if the 
implementation chooses to do so?

I suspect that all PCCs have always stored the current/desired states (plural) 
because that is how head end devices work. That is why there was never any 
mention of PCC LSP-DBs in the previous literature: they were implicit in "this 
is what you do when you build a router." The LSP-DB was only introduced for the 
stateful work because of the (new) desire to know what the PCC already knew and 
to synchronise PCC-PCE and PCE-PCE.

It seems to me that you are trying to describe how to implement a PCE and a 
PCC: something that may be a fun task, but which surely belongs outside the 
IETF.

---

3.2

   Whenever a PCC modifies an entry in its PCC LSP-DB, it MUST send a
   PCRpt message to the PCE (or multiple PCEs), to synchronize this
   change.

This implies that this update must be sent "at once". Why? The network may have 
taken some time to reach this state - why, then, must the update be instant?

Indeed, you may want to smooth flaps in the PCC, and also avoid swamping the 
PCE.

---

3.2

   Ensuring this synchronization is always in place allows one
   to define behavior as a function of LSP-DB state, instead of defining
   behavior as a function of what PCEP messages were sent or received.

Cough?
The message sets the state (you have just said), so the state is exactly a 
function of what messages were sent or received.

---

3.2

   When the PCC acts on message, it would update its own PCC
   LSP DB and immediately send PCRpt to the PCE to synchronize the
   change.

As before:
- why immediately?
- and why not wait until the change is present in the network?

---

Section 1 has

   The current document serves to optimize the original procedure in
   [RFC8231] to drop the PCReq and PCReply exchange, which greatly
   simplifies implementation and optimizes the protocol.

But 3.3 says

   In this document, we would like to make
   it clear that sending PCReq is optional.

So, I think Section 1 should s/drop/optionally drop/

---

3.3 has

   In reality, 

Re: [Pce] WGLC for draft-ietf-pce-pcep-stateful-pce-gmpls-16

[Adrian Farrel]

Hi,

 

It's been a journey for this draft! July 2012 :-)

Glad that we are finally in a place to last call it, and excellent to

know there is an implementation.

 

Here is my review in support of the last call. You'll see that my minor

points are essentially editorial (i.e., not asking to change the

functional behaviour described in the document). There are also some

nits. With these issues fixed, I think the document is ready to 

proceed.

 

Best,

Adrian

 

===

 

== Minor ==

 

6.

 

You need text in this section as...

 

   This section uses Routing Backus-Naur Form (RBNF) [RFC5511] to 

   describe message formats.

 

But note that the comments below might do away with the RBNF!

 

---

 

6.1

   

It is really hard to tell what this document has changed over RFC 8231.

I don't think you should repeat what is already defined, and, as far as

I can tell, nothing in the RBNF has changed.

 

That means the section should read...

 

   The format of the PCRpt message is unchanged from Section 6.1 of

   [RFC8231].  However, some of the objects are extended for use with

   this document as follows:

 

Then, I think you list and describe:

 

 

 

 

 

 SRP

 

But not:

 

 

 

 

 

However, note that you have 

  is the attribute-list defined in  

   Section 6.5 of [RFC5440] and extended by PCEP extensions. 

...which is meaningless! 

 

---

 

Similarly in 6.2

 

   The format of the PCUpd message is unchanged from Section 6.2 of

   [RFC8231].  However, some of the objects are extended for use with

   this document as follows:

 

Then, I think you list and describe:

 

   

 

But not:

 

  

 

However, note that you have 

  is the attribute-list defined in  

   Section 6.5 of [RFC5440] and extended by PCEP extensions. 

...which is meaningless! 

 

I wonder why there is no pointer to SRP in 7.2.3 from this section.

 

---

 

The same applies in 6.3, but the text about what has changed is 

more complicated.

 

I think...

 

   The format of the PCInitiate message is unchanged from Section 5.1 of

   [RFC8281].  However, note the following:

 

   o  The END-POINTS object was been extended by [RFC8779] to include a

  new object type called "Generalized Endpoint".  A PCInitiate 

  message used to trigger a GMPLS LSP instantiation MUST use that 

  extension.

  

   o  A PCInitiate message sent by a PCE to a PCC to trigger a GMPLS LSP

  instantiation MUST include the END-POINTS with Generalized Endpoint

  object type (even though it is marked as optional in the message

  definition.

 

   o  The END-POINTS object MUST contain a "label request" TLV per 

  [RFC8779].  The label request TLV is used to specify the switching

  type, encoding type and G-PID of the LSP being instantiated by the

  PCE. 

 

   o  If unnumbered endpoint addresses are used for the LSP being

  instantiated by the PCE, the unnumbered endpoint TLV [RFC8779] 

  MUST be use to specify the unnumbered endpoint addresses.

   

   o  The END-POINTS MAY contain other TLVs defined in [RFC8779]. 

 

---

 

There is a discrepancy between 5.1, 7.2.1, and 10.1.  In 10.1, you

correctly ask IANA to allocate TBD1 and TBD2.  In 5.1 you refer to

the new bits as TBD1 and TBD2, but in 7.2.1 you:

- Do not refer to TBD1 or TBD2

- Use a figure to specifically imply values for TBD1 and TBD2

 

I suggest that you:

- remove the figure

- mention TBD1 and TBD2 in the text

 

---

 

7.2.2

 

Will you ask IANA to maintain a registry for the Flags field?

 

---

 

7.2.2

 

You have 

 

   This sub-object is OPTIONAL in the exclude route object (XRO) and 

   can be present multiple times.  When a stateful PCE receives a PCReq 

   message carrying this sub-object, it SHOULD search for the 

   identified LSP in its LSP-DB and then exclude from the new path 

   computation all resources used by the identified LSP.   

 

Your use of "SHOULD" here implies that an implementation has a choice to

do something different. You need to say:

- what different thing MAY a PCE do?

- why might it make that choice?

 

(Or make this "MUST")

 

---

 

7.2.3 refers to TBD6, but 10.3 has TBD4

 

---

 

In 8.1 and 8.2 you have that the PCE SHOULD do things without specifying

what else it might do and why.  You also have some cases of lower case

"should" which don't seem right.

 

---

 

8.3 has

 

   If the PCC does not support the END-POINTS Object of type 

   Generalized Endpoint, the PCC MUST send a PCErr message with Error-

   type = 3(Unknown Object), Error-value = 2(unknown object type). 

 

I think this is not new behaviour so you need to point to the spec that

defines this with "...per [RFC5440]..."

 

 

== Nits ==

 

Throughout

 

Please be careful with "sub-object" and "subobject"

 

---

 

1.

 

s/and does not cover the GMPLS/and 

Re: [Pce] IPR Poll for draft-li-pce-pcep-l2-flowspec

[Adrian Farrel]

Hi Hari,

 

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
 
Cheers,
Adrian

 

From: Hariharan Ananthakrishnan  
Sent: 16 December 2021 18:24
To: Farrel Adrian ; Dhruv Dhody ; 
lizhen...@huawei.com
Cc: pce@ietf.org
Subject: IPR Poll for draft-li-pce-pcep-l2-flowspec

 

Hi Authors,
In preparation for WG adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
Please respond (copying the mailing list) to say one of:
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
 
I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.
 
I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.
 
Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!

[Adrian Farrel]

-22 captures it. Thanks,

Adrian

 

From: Gyan Mishra  
Sent: 27 August 2021 06:52
To: adr...@olddog.co.uk
Cc: Dhruv Dhody ; draft-dhodylee-pce-pcep...@ietf.org; 
pce@ietf.org; pce-chairs 
Subject: Re: draft-dhodylee-pce-pcep-ls next steps!

 

 

Hi Adrian 

 

Agreed.  We will make it more clear.

 

Many Thanks!

 

Gyan

 

On Wed, Aug 25, 2021 at 10:30 AM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Yes, thanks, Gyan.

 

I think you have captured it all, although some of the behaviours are “hidden” 
in assumptions in the text.

 

That is:

 

*   A PCEP speaker that offers this feature to its peer that does not 
support or does not wish to support the feature will not receive indication of 
support in the Open message, and so is expected to not use the feature.

 

*   A PCEP speaker that receives any of the objects that are part of the 
feature when use of the feature has not been agreed, will  as 
described in .

 

Of course, this is “business as usual” but the reviewer of the text will not 
necessarily know this.

 

Cheers,

Adrian

 

From: Gyan Mishra mailto:hayabusa...@gmail.com> > 
Sent: 25 August 2021 05:44
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> 
Cc: Dhruv Dhody mailto:d...@dhruvdhody.com> >; 
draft-dhodylee-pce-pcep...@ietf.org 
<mailto:draft-dhodylee-pce-pcep...@ietf.org> ; pce@ietf.org 
<mailto:pce@ietf.org> ; pce-chairs mailto:pce-cha...@ietf.org> >
Subject: Re: draft-dhodylee-pce-pcep-ls next steps!

 

Hi Adrian 

 

 

See section 1.1 should have answers to your questions related to the 
experimental draft.

 

 
<https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1>
 https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1 

 

Kind Regards 

 

Gyan

On Sun, Jul 18, 2021 at 2:40 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Hi Gyan,

 

I am very much in favour of positioning this work as Experimental. 

 

It is important (as with all IETF Experiments) to capture:

-  What stops this extension “escaping" in the Internet?

-  What stops this experiment clashing with other work or harming 
deployed equipment? 

-  How will you judge the success or failure of the experiment, and 
when? 

-  What follow-up to the experiment do you propose?

 

Best,

Adrian

 

From: Gyan Mishra mailto:hayabusa...@gmail.com> > 
Sent: 05 July 2021 07:43
To: Adrian Farrel mailto:adr...@olddog.co.uk> >; Dhruv 
Dhody mailto:d...@dhruvdhody.com> >; 
draft-dhodylee-pce-pcep...@ietf.org 
<mailto:draft-dhodylee-pce-pcep...@ietf.org> ; pce-chairs mailto:pce-cha...@ietf.org> >; pce@ietf.org <mailto:pce@ietf.org> 
Subject: draft-dhodylee-pce-pcep-ls next steps!

 

 

Dear PCE WG,

 

We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap and a 
summary of past discussions. Some new scenarios such as PCECC, H-PCE were 
highlighted where the PCEP session could be reused. 

 

This is an experimental I-D with the aim to progress research and development 
efforts. This work is not a replacement for any of the existing mechanisms. 
There are specific scenarios highlighted where the reuse of PCEP sessions for 
this information is deemed useful. To make progress, it may not be useful to 
rehash the beauty context between everyone's favorite protocol :). What would 
be useful would be - finding out if there is still interest in this 
experimental work by some in the WG; are there strong technical objections for 
the experiment in its limited scope etc... 

 

As a next step, it would be good to define the scope of the experiments and 
expected output especially targeting the scalability concerns as well as impact 
in other protocols and the network, etc.   

 

>From the last query on this draft March 18th we received positive feedback 
>from Aijun Wang with China Telecom mentioned that as a telco are interest in 
>deploying in their network PCEP-LS once the Huawei implementation is ready.  
>Aijun pointed out in the thread that using this draft simplifies the 
>implementation of SDN controller.  One question asked by Aijun was related to 
>section 9.2.1 LS Capability TLV R=1 remote allowed meaning hybrid mode to 
>provide flexibility for operators not yet using SDN (SDN-like) SBI.  For any 
>operators already using PCEP as SDN (SDN-like) SBI, a direct PCEP session 
>already exist between all the nodes in the network and the PCE which would be 
>the PCECV SDN scenario in which case the R flag in the open message is set to 
>0.  

 

We also received positive feedback from Peter Park with telco KT regarding 
interest in PCEP-LS.

 

We also had feedback from Bin as they have implemented PCEP and have interest 
in this experimental implementation of this work.

 

I would like to poll the WG again for interest in progressing research and 
develo

Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!

[Adrian Farrel]

Yes, thanks, Gyan.

 

I think you have captured it all, although some of the behaviours are “hidden” 
in assumptions in the text.

 

That is:

 

*   A PCEP speaker that offers this feature to its peer that does not 
support or does not wish to support the feature will not receive indication of 
support in the Open message, and so is expected to not use the feature.

 

*   A PCEP speaker that receives any of the objects that are part of the 
feature when use of the feature has not been agreed, will  as 
described in .

 

Of course, this is “business as usual” but the reviewer of the text will not 
necessarily know this.

 

Cheers,

Adrian

 

From: Gyan Mishra  
Sent: 25 August 2021 05:44
To: adr...@olddog.co.uk
Cc: Dhruv Dhody ; draft-dhodylee-pce-pcep...@ietf.org; 
pce@ietf.org; pce-chairs 
Subject: Re: draft-dhodylee-pce-pcep-ls next steps!

 

Hi Adrian 

 

 

See section 1.1 should have answers to your questions related to the 
experimental draft.

 

 
<https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1>
 https://www.ietf.org/archive/id/draft-dhodylee-pce-pcep-ls-21.html#section-1.1 

 

Kind Regards 

 

Gyan

On Sun, Jul 18, 2021 at 2:40 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Hi Gyan,

 

I am very much in favour of positioning this work as Experimental. 

 

It is important (as with all IETF Experiments) to capture:

-  What stops this extension “escaping" in the Internet?

-  What stops this experiment clashing with other work or harming 
deployed equipment? 

-  How will you judge the success or failure of the experiment, and 
when? 

-  What follow-up to the experiment do you propose?

 

Best,

Adrian

 

From: Gyan Mishra mailto:hayabusa...@gmail.com> > 
Sent: 05 July 2021 07:43
To: Adrian Farrel mailto:adr...@olddog.co.uk> >; Dhruv 
Dhody mailto:d...@dhruvdhody.com> >; 
draft-dhodylee-pce-pcep...@ietf.org 
<mailto:draft-dhodylee-pce-pcep...@ietf.org> ; pce-chairs mailto:pce-cha...@ietf.org> >; pce@ietf.org <mailto:pce@ietf.org> 
Subject: draft-dhodylee-pce-pcep-ls next steps!

 

 

Dear PCE WG,

 

We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap and a 
summary of past discussions. Some new scenarios such as PCECC, H-PCE were 
highlighted where the PCEP session could be reused. 

 

This is an experimental I-D with the aim to progress research and development 
efforts. This work is not a replacement for any of the existing mechanisms. 
There are specific scenarios highlighted where the reuse of PCEP sessions for 
this information is deemed useful. To make progress, it may not be useful to 
rehash the beauty context between everyone's favorite protocol :). What would 
be useful would be - finding out if there is still interest in this 
experimental work by some in the WG; are there strong technical objections for 
the experiment in its limited scope etc... 

 

As a next step, it would be good to define the scope of the experiments and 
expected output especially targeting the scalability concerns as well as impact 
in other protocols and the network, etc.   

 

>From the last query on this draft March 18th we received positive feedback 
>from Aijun Wang with China Telecom mentioned that as a telco are interest in 
>deploying in their network PCEP-LS once the Huawei implementation is ready.  
>Aijun pointed out in the thread that using this draft simplifies the 
>implementation of SDN controller.  One question asked by Aijun was related to 
>section 9.2.1 LS Capability TLV R=1 remote allowed meaning hybrid mode to 
>provide flexibility for operators not yet using SDN (SDN-like) SBI.  For any 
>operators already using PCEP as SDN (SDN-like) SBI, a direct PCEP session 
>already exist between all the nodes in the network and the PCE which would be 
>the PCECV SDN scenario in which case the R flag in the open message is set to 
>0.  

 

We also received positive feedback from Peter Park with telco KT regarding 
interest in PCEP-LS.

 

We also had feedback from Bin as they have implemented PCEP and have interest 
in this experimental implementation of this work.

 

I would like to poll the WG again for interest in progressing research and 
development efforts of this draft as experimental.  

 

As stated in the last WG poll, I would like get feedback from the WG on scope 
of experiments especially related to scalability concerns and impact to other 
protocols on the network.

 

Thanks! 

Gyan (on behalf of co-authors)

 

[1] 
https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf

[2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/

==

 

 <http://www.verizon.com/> 

Gyan Mishra

Network Solutions Architect 

Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com> 

M 301 502-1347

 

-- 

 <http://www.verizon.com/> 

Gyan

Re: [Pce] draft-dhodylee-pce-pcep-ls next steps!

[Adrian Farrel]

Hi Gyan,

 

I am very much in favour of positioning this work as Experimental. 

 

It is important (as with all IETF Experiments) to capture:

-  What stops this extension “escaping" in the Internet?

-  What stops this experiment clashing with other work or harming 
deployed equipment? 

-  How will you judge the success or failure of the experiment, and 
when? 

-  What follow-up to the experiment do you propose?

 

Best,

Adrian

 

From: Gyan Mishra  
Sent: 05 July 2021 07:43
To: Adrian Farrel ; Dhruv Dhody ; 
draft-dhodylee-pce-pcep...@ietf.org; pce-chairs ; 
pce@ietf.org
Subject: draft-dhodylee-pce-pcep-ls next steps!

 

 

Dear PCE WG,

 

We presented the PCEP-LS [1] I-D [2] in the IETF 110 with a quick recap and a 
summary of past discussions. Some new scenarios such as PCECC, H-PCE were 
highlighted where the PCEP session could be reused. 

 

This is an experimental I-D with the aim to progress research and development 
efforts. This work is not a replacement for any of the existing mechanisms. 
There are specific scenarios highlighted where the reuse of PCEP sessions for 
this information is deemed useful. To make progress, it may not be useful to 
rehash the beauty context between everyone's favorite protocol :). What would 
be useful would be - finding out if there is still interest in this 
experimental work by some in the WG; are there strong technical objections for 
the experiment in its limited scope etc... 

 

As a next step, it would be good to define the scope of the experiments and 
expected output especially targeting the scalability concerns as well as impact 
in other protocols and the network, etc.   

 

>From the last query on this draft March 18th we received positive feedback 
>from Aijun Wang with China Telecom mentioned that as a telco are interest in 
>deploying in their network PCEP-LS once the Huawei implementation is ready.  
>Aijun pointed out in the thread that using this draft simplifies the 
>implementation of SDN controller.  One question asked by Aijun was related to 
>section 9.2.1 LS Capability TLV R=1 remote allowed meaning hybrid mode to 
>provide flexibility for operators not yet using SDN (SDN-like) SBI.  For any 
>operators already using PCEP as SDN (SDN-like) SBI, a direct PCEP session 
>already exist between all the nodes in the network and the PCE which would be 
>the PCECV SDN scenario in which case the R flag in the open message is set to 
>0.  

 

We also received positive feedback from Peter Park with telco KT regarding 
interest in PCEP-LS.

 

We also had feedback from Bin as they have implemented PCEP and have interest 
in this experimental implementation of this work.

 

I would like to poll the WG again for interest in progressing research and 
development efforts of this draft as experimental.  

 

As stated in the last WG poll, I would like get feedback from the WG on scope 
of experiments especially related to scalability concerns and impact to other 
protocols on the network.

 

Thanks! 

Gyan (on behalf of co-authors)

 

[1] 
https://datatracker.ietf.org/meeting/110/materials/slides-110-pce-42-pcep-ls-00.pdf

[2] https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/

==

 

 <http://www.verizon.com/> 

Gyan Mishra

Network Solutions Architect 

Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com> 

M 301 502-1347

 

-- 

 <http://www.verizon.com/> 

Gyan Mishra

Network Solutions Architect 

Email gyan.s.mis...@verizon.com <mailto:gyan.s.mis...@verizon.com> 

M 301 502-1347

 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[Adrian Farrel]

Hi Cheng!

This is good progress, thanks.

I have cut down to the points that are still open.

Nothing we need to fight about 

Best,
Adrian

>> == Questions / Issues ==
>>
>> 3.
>>
>>   o  BT = 0: The binding value is an MPLS label carried in the format
>>  specified in [RFC5462] where only the label value is valid, and
>>  other fields MUST be considered invalid.  The Length MUST be set
>>  to 7.
>>
>> I don't think that RFC 5462 is the right reference. That document simply
>> renames a field in the MPLS label stack entry.
>>
>> So, are you carrying an MPLS label or an MPLS label stack entry? Either
>> is possible, although since you're only interested in the label, it might be
>> more normal to carry just the label value in the least significant 20 bits
>> of the binding value field. That would be consistent with a Length of 7.
>>
>> But, if you want to carry the full label stack entry (with the other fields
>> ignored) then perhaps...
>>   o  BT = 0: The binding value is an MPLS label carried in an MPLS 
>>  label stack entry format as specified in [RFC3032] where only the
>>  label value is valid, and other fields MUST be ignored.  The
>>  Length MUST be set to 8.
>>
>> This would be more consistent with:
>>   o  BT = 1: Similar to the case where BT is 0 except that all the
>>  fields on the MPLS label entry are set on transmission.  However,
>>  the receiver MAY choose to override TC, S, and TTL values
>>  according its local policy.  The Length MUST be set to 8.
>> But here you may want a little more clarity as:
>>   o  BT = 1: Similar to the case where BT is 0 except that all the
>>  fields of the MPLS label stack entry are set on transmission of
>>  the PCEP message containing the TLV.  A PCC receiver of this TLV 
>>  in a PCEP message MAY choose to override TC, S, and TTL values 
>>  according its local policy.  The Length MUST be set to 8.
>>
>> But, at the bottom of the section...
>>   For the BT as 0, the 20 bits represent the MPLS
>>   label.  For the BT as 1, the 32-bits represent the label stack entry
>>   as per [RFC5462].
>> Which is going back on itself (and using the wrong reference).
>>
>> Just make a decision on the meaning of BT=0 and make the text clean.
>
> [Cheng] How about this - 
>
>   o  BT = 0: The binding value is a 20-bit MPLS label value.  The TLV
>  is padded to 4-bytes alignment.  The Length MUST be set to 7 and
>  first 20 bits are used to encode the MPLS label value.
>
>   o  BT = 1: The binding value is a 32-bit MPLS label stack entry as
>  per [RFC3032] with Label, TC [RFC5462], S, and TTL values encoded.
>  Note that the receiver MAY choose to override TC, S, and TTL
>  values according to its local policy.  The Length MUST be set to 8.

OK. This is clear. I think you just need to look through the other mentions of 
BT=0 and BT=1 to make sure they match with this.

>> 3.
>>
>> I'm a bit puzzled as to why this document defines two flags for the Path 
>> Binding TLV 
>> Flags field, when this document clearly doesn't use or depend on them.
>>
>> In order to not make [I-D.ietf-spring-segment-routing-policy] a normative 
>> reference, perhaps
>> you should not mention the specific bits, create the registry (in 11.1.1) as 
>> empty, and simply
>> not that [I-D.ietf-spring-segment-routing-policy] defines some flags.
>>
>> (Obviously, [I-D.ietf-spring-segment-routing-policy] will need to make 
>> assignments from 
>> the registry.)
>
> [Cheng] The idea was to make it consistent with IDR WG I-D 
> [draft-ietf-idr-segment-routing-
> te-policy]. 
> One option could be to move this to the SR-policy-related PCE WG I-D 
> [draft-ietf-pce-segment-
> routing-policy-cp]. 
> I have kept this open for now for further discussion.

To be clear, I was suggesting:
- this document creates and defines the registry
- the documents that need codepoints are responsible for requesting allocation 
of codepoints

>> 4.
>>
>>   Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
>>   LSP object.  This signifies the presence of multiple binding SIDs for
>>   the given LSP.
>>
>> If one of these contains a bad value, and a PCErr is sent according to the 
>> previous
>> paragraph, what happens to all the other Binding Values?
>> Are they used or discarded?
>
> [Cheng] They should not be impacted. I have added this - 
>
>   In case of multiple TE-PATH-BINDING TLVs, all
>   instances of TE-PATH-BINDING TLVs MUST always be included in the LSP
>   object.  In case of an error, a PCErr message MAY include the
>   offending TE-PATH-BINDING TLV in the PCEP-ERROR object.

I think maybe I wasn't clear.
Suppose the LSP object contains three TE-PATH-BINDING TLVs (TLV1, TLV2, and 
TLV3)
Suppose that TLV3 contains a bad value.
That means a PCErr will be sent with PCEP-ERROR and that MAY contain the 
offending TLV3.
OK so far.
Now, what happens to TLV1 and TLV2?
Are they processed and used by the receiver?
  Or

Re: [Pce] WG Last Call for draft-ietf-pce-binding-label-sid-07 (and Code Point Allocation)

[Adrian Farrel]

Hi Julien, WG, authors.

Code point allocation: Is the request for all of the code points in the
document? What about the not-yet-allocated code point from
[I-D.ietf-pce-pcep-extension-for-pce-controller]. This spec can't be
implemented without it.

WG last call: I have a few questions/issues/nits below.

Best,
Adrian

== Questions / Issues ==

Abstract

What is the difference between "a Binding Segment Identifier (BSID)" and
a "binding Segment-ID (SID)"?

---

Abstract

"Such a binding label/SID"
This is the first use of "label". You need some context.

---

Abstract

   This document proposes
   an approach for reporting binding label/SID to Path Computation
   Element (PCE) for supporting PCE-based Traffic Engineering policies.

Who does the reporting?
Same in Section 1 top of page 4.

---

3.

   o  BT = 0: The binding value is an MPLS label carried in the format
  specified in [RFC5462] where only the label value is valid, and
  other fields MUST be considered invalid.  The Length MUST be set
  to 7.

I don't think that RFC 5462 is the right reference. That document simply
renames a field in the MPLS label stack entry.

So, are you carrying an MPLS label or an MPLS label stack entry? Either
is possible, although since you're only interested in the label, it
might be more normal to carry just the label value in the least
significant 20 bits of the binding value field. That would be consistent
with a Length of 7.

But, if you want to carry the full label stack entry (with the other
fields  ignored) then perhaps...
   o  BT = 0: The binding value is an MPLS label carried in an MPLS 
  label stack entry format as specified in [RFC3032] where only the
  label value is valid, and other fields MUST be ignored.  The
  Length MUST be set to 8.

This would be more consistent with:
   o  BT = 1: Similar to the case where BT is 0 except that all the
  fields on the MPLS label entry are set on transmission.  However,
  the receiver MAY choose to override TC, S, and TTL values
  according its local policy.  The Length MUST be set to 8.
But here you may want a little more clarity as:
   o  BT = 1: Similar to the case where BT is 0 except that all the
  fields of the MPLS label stack entry are set on transmission of
  the PCEP message containing the TLV.  A PCC receiver of this TLV 
  in a PCEP message MAY choose to override TC, S, and TTL values 
  according its local policy.  The Length MUST be set to 8.

But, at the bottom of the section...
   For the BT as 0, the 20 bits represent the MPLS
   label.  For the BT as 1, the 32-bits represent the label stack entry
   as per [RFC5462].
Which is going back on itself (and using the wrong reference).

Just make a decision on the meaning of BT=0 and make the text clean.

---

3.

I'm a bit puzzled as to why this document defines two flags for the 
Path Binding TLV Flags field, when this document clearly doesn't use or
depend on them.

In order to not make [I-D.ietf-spring-segment-routing-policy] a 
normative reference, perhaps you should not mention the specific bits,
create the registry (in 11.1.1) as empty, and simply not that 
[I-D.ietf-spring-segment-routing-policy] defines some flags.

(Obviously, [I-D.ietf-spring-segment-routing-policy] will need to make
assignments from the registry.)

---

4.

   Multiple TE-PATH-BINDING TLVs are allowed to be present in the same
   LSP object.  This signifies the presence of multiple binding SIDs for
   the given LSP.

If one of these contains a bad value, and a PCErr is sent according to 
the previous paragraph, what happens to all the other Binding Values?
Are they used or discarded?

---

4.

   For SRv6 BSIDs, it is RECOMMENDED to always explicitly specify the
   SRv6 Endpoint Behavior and SID Structure in the TE-PATH-BINDING TLV
   by setting the BT (Binding Type) to 3, instead of 2.  The choice of
   interpreting SRv6 Endpoint Behavior and SID Structure when none is
   explicitly specified is left up to the implementation.

I puzzled about the alternative to "RECOMMENDED".  I wondered if the
second sentence was meant to offer that guidance, but perhaps it is
intended to only to cover the case when no Path Binding TLV is present.
Two concepts in one paragraph?

---

4.

   If a PCC wishes to withdraw or modify a previously reported binding
   value, it MUST send a PCRpt message without any TE-PATH-BINDING TLV
   or with the TE-PATH-BINDING TLV containing the new binding value
   respectively.

   If a PCE wishes to modify a previously requested binding value, it
   MUST send a PCUpd message with TE-PATH-BINDING TLV containing the new
   binding value.  The absence of TE-PATH-BINDING TLV in PCUpd message
   means that the PCE does not specify a binding value in which case the
   binding value allocation is governed by the PCC's local policy.

How does this work if multiple binding values have been assigned by 
using multiple TE-PATH-BINDING TLVs? Suppose, having done that, 

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[Adrian Farrel]

Ah, that's useful. Thanks Julien.

Makes this work more pressing.

Informative references to those two drafts would help focus the reviewer's mind 
and might be handy when this draft overtakes those other two documents and goes 
to the IESG.

Cheers,
Adrian

-Original Message-
From: julien.meu...@orange.com  
Sent: 19 February 2021 14:38
To: adr...@olddog.co.uk
Cc: pce@ietf.org
Subject: Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi Adrian,

Thank you for your feedback.

If evidence is needed, how about binding label?
https://tools.ietf.org/html/draft-ietf-pce-binding-label-sid-06#section-11.2
Note it's also reused in
https://tools.ietf.org/html/draft-ietf-pce-sr-path-segment-03#section-4.2

Have a nice week-end,

Julien


On 18/02/2021 16:57, Adrian Farrel wrote:
> Thanks to the authors for cleaning this up a lot since last time.
>
> I don't object to adoption. Would be nice to have evidence of someone
> needing a bit now, but by the time this becomes an RFC it is reasonably
> possible.
>
> Adrian
>
> -Original Message-
> From: Pce  On Behalf Of Dhruv Dhody
> Sent: 01 February 2021 17:48
>
> Hi WG,
>
> This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.
>
> https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03
>
> This is a small draft that extends the flags in the LSP Objects by
> defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
> sub-registry "LSP Object Flag Field" is almost fully assigned.
>
> https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field
>
> Should this draft be adopted by the PCE WG? Please state your reasons
> - Why / Why not? What needs to be fixed before or after adoption? Are
> you willing to work on this draft? Review comments should be posted to
> the list.
>
> Please respond by Monday 15th Feb.
>
> Thanks!
> Dhruv & Julien
>
> ___
> 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
>


_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

[Adrian Farrel]

Thanks to the authors for cleaning this up a lot since last time.

I don't object to adoption. Would be nice to have evidence of someone
needing a bit now, but by the time this becomes an RFC it is reasonably
possible.

Adrian

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: 01 February 2021 17:48
To: pce@ietf.org
Subject: [Pce] Adoption of draft-xiong-pce-lsp-flag-03

Hi WG,

This email begins the WG adoption poll for draft-xiong-pce-lsp-flag-03.

https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag-03

This is a small draft that extends the flags in the LSP Objects by
defining a new LSP-EXTENDED-FLAG TLV. Note that the existing
sub-registry "LSP Object Flag Field" is almost fully assigned.

https://www.iana.org/assignments/pcep/pcep.xhtml#lsp-object-flag-field

Should this draft be adopted by the PCE WG? Please state your reasons
- Why / Why not? What needs to be fixed before or after adoption? Are
you willing to work on this draft? Review comments should be posted to
the list.

Please respond by Monday 15th Feb.

Thanks!
Dhruv & Julien

___
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 adoption poll for draft-dugeon-pce-stateful-interdomain-04

[Adrian Farrel]

Hi,

I've reviewed this draft and I think it is ready for adoption because
the functionality (i.e., stitching segments without inter-domain
signaling which means that path-key cannot be used) is valuable.

There are a number of editorial comments below. I think they do not 
need to be addressed before adoption, but I hope the authors will factor
them into a new revision after adoption.

Thanks,
Adrian

===

Need to update Young Lee's coordinates

---

Abstract

I think that BRPC or H-PCE are methods to achieve inter-domain paths
not methods to be combined with inter-domain paths. How about...
OLD
   This document specifies how to combine a Backward Recursive or
   Hierarchical method with inter-domain paths in the context of
   stateful Path Computation Element (PCE).
NEW
   This document specifies how to use a Backward Recursive or
   Hierarchical method to derive inter-domain paths in the context of
   stateful Path Computation Element (PCE).
END

---

Abstract

"It relies on..." comes in the sentence immediately after "This
document..."  I think you need to be more precise. Probably

s/It relies on/The mechanism relies on/

---

Abstract

s/enables to operate them/enables them to be operated/

---

Abstract

   A new Stitching Label is defined, new Path
   Setup Types, a new Association Type and a new PCEP communication
   Protocol (PCEP) Capability are considered for that purpose.

I can't parse this. Possibly...

   For this purpose, this document defines a new Stitching Label, new
   Path Setup Types, new Association Type, and a new PCEP communication
   Protocol (PCEP) Capability.

---

The requirement language should be moved into section 1.2

---

Introduction

There is a *lot* of text in the Introduction. I wonder whether we need
so much. Does every PCE document have to start with the whole history of
PCE?

I tried to boil down what this document is really about:

- PCE is used to compute paths from MPLS-TE, GMPLS, and SR
- Various mechanisms can be used to enable PCEs to cooperate to compute
  inter-domain paths including BRPC and H-PCE
- MPLS-TE and GMPLS depend on signaling using RSVP-TE to set up paths,
  but it is not common to allow signaling across administrative domain
  borders.
- SR depends on a stack of segment identifiers, but in an inter-domain
  path, this stack may become large, and detailed control of a path
  within one domain by packets originating in another domain might not 
  be supported.
- This document describes a mechanism whereby the paths across each 
  domain remain under the control of those domains, and the paths are
  stitched together at domain boundaries to form a single end-to-end
  path.
- The mechanism relies on cooperating PCEs to determine the end-to-end
  path with each PCE responsible for computing and initiating the paths
  within its domain. The PCEs are assumed to be stateful active PCEs so
  that they can instruct their networks to set up the paths. 
- Signaling (for MPLS-TE and GMPLS) is used only within individual
  domains.
- Specific labels/SIDs are used to indicate which path segments should
  be stitched together.
- To enable this mechanism, this document defines a new Stitching
  Label, new Path Setup Types, new Association Type, and a new PCEP
  communication Protocol (PCEP) Capability.

I think that can be converted into text that is a little easier to read
than the current Introduction.

---

1.1

s/end-o-end/end-to-end/

---

I think it would be helpful to have a figure that shows the solution 
architecture in more detail than that currently in section 1.1.  Nothing
wrong with that figure, but we also need to see the LSPs/SR-paths and
where the signaling stops and how the label/SID on the inter-domain link
is used. Also, how the PCEs talk to the various nodes.
 
Something like the figure below would allow the descriptive text that
follows.

--   --   --
   |Domain-A  | |Domain-B  | |Domain-C  |
   |  | |  | |  |
   | PCE--+--PCEP---+---PCE+--PCEP---+---PCE|
   |/ | |  /   | |  /   |
   |   /  | | /| | /|
   | Src=BNA---BNB1===BNB2--BNC=Dst |
   |  |  Inter- |  |  Inter- |  |
--   Domain  --   Domain  --
 Link Link


   1. The PCEs in Domain-A, Domain-B, and Domain-C communicate using
  PCEP either directly, as shown, using BRPC or with a parent PCE
  if using BRPC.
   2. The PCE in Domain-A selects an end-to-end domain path. It tells
  the PCE in Domain-B that the path will be used, and that PCE
  passes the information on to the PCE in Domain-C.
   3. Each of the PCEs use PCEP to instruct the 

Re: [Pce] IPR Poll on draft-zhao-pce-pcep-extension-pce-controller-sr-09

[Adrian Farrel]

Hi,

 

As a contributor, I am not aware of any IPR applicable to this draft that 
should be disclosed in accordance with IETF IPR rules.
 
Thanks,
Adrian

 

 

From: Pce  On Behalf Of Hariharan Ananthakrishnan
Sent: 26 November 2020 22:58
To: lizhen...@huawei.com; pengshup...@huawei.com; Mahend Negi 
; qz...@ethericnetworks.com; chaozhou...@yahoo.com
Cc: pce@ietf.org
Subject: [Pce] IPR Poll on draft-zhao-pce-pcep-extension-pce-controller-sr-09

 

Hi Authors,
 
In preparation for WG adoption on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
Please respond (copying the mailing list) to say one of:
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
 
I am aware of the IPR applicable to this draft, and it has already been
disclosed to the IETF.
 
I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.
 
Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

[Adrian Farrel]

Hello all,

I was a contributor to some of the earlier versions of this document and am 
listed as such (although I don't think I work for Juniper any more).

I think the document is in a good enough state for adoption.

Post-adoption there are some things that could benefit from work...

- I worry about having draft-dhodylee-pce-pcep-ls referenced by section 5.4
  This use is normative, but draft-dhodylee-pce-pcep-ls is only included as an
  informative reference. It is worrying because it is unclear at this stage 
whether
  the WG will choose to adopt that work.
- The document feels too long for a relatively small extension. However, a
  quick scan doesn't immediately identify sections to prune.
- A reference to RFC 5511 is needed to explain section 6.1

Best,
Adrian

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: 26 November 2020 15:35
To: pce@ietf.org
Subject: [Pce] Adoption of draft-zhao-pce-pcep-extension-pce-controller-sr-09?

Hi all,

PCECC extensions are progressing towards the IESG. It is time to share
your thoughts about draft-zhao-pce-pcep-extension-pce-controller-sr-09.
Do you believe the I-D is a right foundation for a PCE WG item? Please
use the PCE mailing list to express your comments, support or
disagreement, including applicable rationale, especially for the latter.

Thanks,

Dhruv & Julien



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Adrian Farrel]

Hi again Gyan,

 

I think we’re narrowing down and getting somewhat esoteric for the mailing 
lists we’re spamming.

> Similarly other use cases such as with TEAS TS-Transport slice and being able
> to provision TS and capturing the TS Enhanced VPN RT & resource information
> and leveraging BGP-LS to do the same data gathering & ZTP like controller 
> style
> provisioning. 

Is there a fundamental difference between ZTP & Day N provisioning and path 
computation for traffic engineering provisioning? It’s all determining how to 
configure the network to best carry traffic. 

Gyan> In my mind the fundamental difference would be TE - control plane TEDs and
forwarding plane routing action path computation and instantiation of path 
action
as compare to a NMS type Netconf/Yang configuration snippet push function not
routing or TE related.

 

[Adrian] I think it depends. The protocols are just tools. You could have a 
centralised TE system with a PCE to preform computations, but you can use any 
combinations of protocols to extract information from the network (IGPs, 
BGP-LS, PCEP-LS, Netconf, …) and any combination of protocols to program the 
network devices to install TE paths, reserve resources, and configure traffic 
forwarding rules (PCEP, RSVP-TE, Netconf, …).

 

Cheers,

Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] [Bier] PCE Controller & SDN Controller & Netconf/Yang NMS Controller - lines blurred and can the names be used ubiquitously meaning the same

[Adrian Farrel]

Hi Gyan,

 

Sorry, I missed this (got caught on a filter cos it was a bit spammed to a lot 
of lists :-).

 

> I have noticed that after reviewing many drafts across many WGs it seems in 
> the

> industry that the lines seem to be blurred between a PCE controller, ODL or

> Openflow SDN Controller and a Netconf/Yang NMS Controller ZTP & Day X

> provisioning.

 

Yes, blurriness our speciality.

 

You my find RFC 7491 useful in this respect, although it is a little dated. 
And, of course, RFC 8283 is a good starting point.

 

> As this is a software sitting on a server you can have a swiss army knife 
> server that

> does everything from PCE path computation to  Netconf/Yang ZTP & Day N 

> provisioning as well as any SDN Controller ODL or Openflow controller type

> functions as well.

 

Yes, and this is one of the risks of PCE as a shiny thing: that it be converted 
from a useful toolkit into some form of god-box. I pontificated on this way 
back in 2014 at http://www.olddog.co.uk/PCEPandOnwards.pdf

 

> How this comes into play and realization of the lines being blurred is the 
> use of

> BGP-LS in building the IGP topological graph of the network which was designed

> for PCEP and PCE & PCC active & passive off line path computation for both

> RSVP-TE or SR-TE path instantiation.  

 

In some senses, BGP-LS didn’t add anything because a PCE could have snooped on 
the IGP. But BGP-LS provides an export mechanism and importantly adds to that 
some policy filters to determine what is exported thus giving the network some 
control over what is exported.

 

FWIW, https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/ proposes 
using PCEP for the same function. The argument in favor is that a PCE has to 
implement PCEP anyway, so why not include the LS export as well. The argument 
against is that BGP-LS has wider applicability and that it will typically be 
exported from an ASBR which already supports BGP.

 

> However now BGP-LS can also be used for other functions now such as usage as

> I am a Shepherd reviewing a draft for BGP-LS usage for BIER to use BGP-LS to

> gather the elements internals within BIER using the same BGP-LS data 
> structures

> to populate with BIER specific information to graph the BIER topology.  So 
> here

> we are not doing any path computations as we are using in this use case  for

> NMS type function to gather data for ZTP & Day N provisioning.

> 

> Similarly other use cases such as with TEAS TS-Transport slice and being able

> to provision TS and capturing the TS Enhanced VPN RT & resource information

> and leveraging BGP-LS to do the same data gathering & ZTP like controller 
> style

> provisioning. 

 

Is there a fundamental difference between ZTP & Day N provisioning and path 
computation for traffic engineering provisioning? It’s all determining how to 
configure the network to best carry traffic.

 

> It does seem as though BGP-LS as its a means of "data gathering" "dump truck"

> of anything with the kitchen sink included to build any type of topological 
> graph

> of literally anything under the sun.

 

Remembering Yakov Rekhter saying you could use BGP to transport Shakespeare. 

This is a tension with any protocol BGP-LS, PCEP, etc., etc. Stuff gets added, 
further use gets made.

 

BGP-LS was intended to export routing information “northbound” from the network.

 

> I see that is a nice to leverage but it does in fact blur the lines of NMS 
> Netconf/Yang

> Controller based functionality and  PCE path computation functionality and SDN

> controller based ZTP functionality into a single ubiquitous server that can 
> do all of

> the above and use BGP-LS to accomplish the "kitchen sink" tasks.  It does 
> however

> transform BGP to be an NMS tool but a "tool" and not just the original 
> function

> which it was intended NLRI network reachability.

 

Not sure that BGP-LS is BGP. But I agree that BGP-LS is “an NMS tool”.

I might argue that BGP distributing policies from installation on PEs is an NMS 
protocol.

 

> Am I off base and please let me know as its BGP-LS is being way over 
> leveraged. 

> There are pros & cons to everything but I thought I would bring up to the WG 
> as

> an important discussion point.

 

Who are we to argue with real implementations? Assuming that there is a push 
for implementation and deployment, then the thing to look for is “harm”. Does 
this use of BGP-LS cause harm, sow confusion, risk destabilising the network? 
Should it use a different code point to be distinguishable?

 

I think the argument that “there is already another protocol for doing this” is 
worth examining. But we have to be careful that it doesn’t get us stuck, or 
force everyone to do something they don’t want to do. After all, we could carry 
any protocol message using Netconf/YANG, but we don’t do “RSVP-TE over Netconf”.

 

Best,

Adrian

 

___
Pce mailing list
Pce@ietf.org

[Pce] FW: I-D Action: draft-ietf-pce-pcep-flowspec-11.txt

[Adrian Farrel]

Alvaro and Ben,

Very sorry for delaying this progress so much and possibly causing your
cache not only to be flushed, but the archive tapes sent to the fire-vault
in Utah.

The last issue you had remaining was that 5575bis has removed the
possibility of multiple Flow Specification components of the same type being
present in one flow specification. We have aligned with this with two
changes:
- Added text to Section 7 saying:
   As described in [I-D.ietf-idr-rfc5575bis]
   where it says "A given component type MAY (exactly once) be present
   in the Flow Specification," a Flow Filter TLV MUST NOT contain more
   than one Flow Specification TLV of the same type: an implementation
   that receives a PCEP message with a Flow Filter TLV that contains more
   than one Flow Specification TLV of the same type MUST respond with a
   PCErr message with error-type TBD8 (FlowSpec Error), error-value 2
   (Malformed FlowSpec) and MUST NOT install the Flow Specification.
- Section 8.4 has been rewritten to mainly say "use separate Flow 
  Specification Objects for separate flow specifications"

This -11 revision picks up all other outstanding comments and nits.

Best,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 05 October 2020 15:27
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: I-D Action: draft-ietf-pce-pcep-flowspec-11.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 Extension for Flow Specification
Authors : Dhruv Dhody
          Adrian Farrel
  Zhenbin Li
Filename: draft-ietf-pce-pcep-flowspec-11.txt
Pages   : 37
Date: 2020-10-05

Abstract:
   The Path Computation Element (PCE) is a functional component capable
   of selecting paths through a traffic engineering network.  These
   paths may be supplied in response to requests for computation, or may
   be unsolicited requests issued by the PCE to network elements.  Both
   approaches use the PCE Communication Protocol (PCEP) to convey the
   details of the computed path.

   Traffic flows may be categorized and described using "Flow
   Specifications".  RFC  defines the Flow Specification and
   describes how Flow Specification Components are used to describe
   traffic flows.  RFC  also defines how Flow Specifications may be
   distributed in BGP to allow specific traffic flows to be associated
   with routes.

   This document specifies a set of extensions to PCEP to support
   dissemination of Flow Specifications.  This allows a PCE to indicate
   what traffic should be placed on each path that it is aware of.

   The extensions defined in this document include the creation, update,
   and withdrawal of Flow Specifications via PCEP, and can be applied to
   tunnels initiated by the PCE or to tunnels where control is delegated
   to the PCE by the PCC.  Furthermore, a PCC requesting a new path can
   include Flow Specifications in the request to indicate the purpose of
   the tunnel allowing the PCE to factor this into the path computation.

   RFC Editor Note: Please replace  in the Abstract with the RFC
   number assigned to draft-ietf-idr-rfc5575bis when it is published.
   Please remove this note.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-11
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-11


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/


___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-pcep-extension-for-pce-controller-07.txt

[Adrian Farrel]

Just to repeat what I said when Shuping proposed the changes...
This revision addresses all the points in my review.
Cheers,
Adrian

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: 02 September 2020 03:37
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action:
draft-ietf-pce-pcep-extension-for-pce-controller-07.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 Procedures and Protocol Extensions for Using
PCE as a Central Controller (PCECC) of LSPs
Authors : Zhenbin Li
  Shuping Peng
  Mahendra Singh Negi
  Quintin Zhao
  Chao Zhou
Filename:
draft-ietf-pce-pcep-extension-for-pce-controller-07.txt
Pages   : 35
Date: 2020-09-01

Abstract:
   The Path Computation Element (PCE) is a core component of Software-
   Defined Networking (SDN) systems.  It can compute optimal paths for
   traffic across a network and can also update the paths to reflect
   changes in the network or traffic demands.

   PCE was developed to derive paths for MPLS Label Switched Paths
   (LSPs), which are supplied to the head end of the LSP using the Path
   Computation Element Communication Protocol (PCEP).  But SDN has a
   broader applicability than signaled MPLS and GMPLS traffic-engineered
   (TE) networks, and the PCE may be used to determine paths in a range
   of use cases.  PCEP has been proposed as a control protocol for use
   in these environments to allow the PCE to be fully enabled as a
   central controller.

   A PCE-based central controller (PCECC) can simplify the processing of
   a distributed control plane by blending it with elements of SDN and
   without necessarily completely replacing it.  Thus, the LSP can be
   calculated/setup/initiated and the label forwarding entries can also
   be downloaded through a centralized PCE server to each network
   devices along the path while leveraging the existing PCE technologies
   as much as possible.

   This document specifies the procedures and PCEP extensions for using
   the PCE as the central controller.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-extension-for-pce-contr
oller/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-extension-for-pce-controller
-07
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-extension-for-pce-
controller-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-extension-for-pce-cont
roller-07


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

Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS)

[Adrian Farrel]

Hi Alvaro,

Thanks for iterating on this.

I think it is not a 'potential downside' that the BGP FlowSpecs may be 
propagated further than the PCEP ones. I think it is highly functional. The 
PCEP FlowSpec is intended to apply only at the head end of the LSP. It is not 
about network planning, but out processing on a single node that is the head 
end of the LSP.

Looked at another way: why was the LSP set up? Presumably the operator saw the 
need to tunnel traffic from one point in the network to another. That assumes 
that the traffic is arriving at that head end (because otherwise, the LSP is a 
bit of a waste of time). All this document does is tell the head end what 
traffic to put on the LSP, and (by omission) what traffic to continue to route 
using other means. If changes to the routing system (whether through BGP with 
or without FlowSpecs, or through IGPs) mean that the traffic never reaches the 
head end of the LSP, that is perfectly OK as far as this work is concerned. Of 
course, the operator might be annoyed that they set up an unused LSP, but they 
are also in control of the routing system, so they should work it out.

I think there are three points we can work on to add to the document:
1. PCEP-installed FlowSpecs MUST NOT be redistributed to other routers using 
BGP.
2. PCEP-installed FlowSpecs are intended to be installed only at the head-end 
of the LSP to which they direct traffic. It is acceptable (and potentially 
desirable) that other routers have FlowSpecs that match the same traffic but 
direct it onto different routes or to different LSPs.
3. Note that changes to the wider routing system (such as the distribution and 
installation of BGP FlowSpecs, or fluctuations in the IGP link state database) 
might mean that traffic matching the PCEP FlowSpec never reaches the head end 
of the LSP at which the PCEP FlowSpec is installed. This may or may not be 
desirable according to the operator's traffic engineering and routing policies, 
but it is not an effect that this document seeks to address.

BTW - a second issue arises from various discussions which had escaped us 
before. 5575bis makes a change from 5575 such that only one instance of any 
type of flow specification component can now be present in a FlowSpec. This 
makes our life a lot easier and we can tidy the document accordingly.

Best,
Adrian

-Original Message-
From: Alvaro Retana  
Sent: 26 August 2020 23:20
To: adr...@olddog.co.uk; The IESG 
Cc: pce-cha...@ietf.org; pce@ietf.org; Julien Meuric 
; draft-ietf-pce-pcep-flows...@ietf.org
Subject: RE: Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with 
DISCUSS)

On August 26, 2020 at 5:25:20 PM, Adrian Farrel wrote:


Adrian:

Hi!



> > The concern I have is that in BGP's distribution model FlowSpecs are
> > forwarded to other BGP speakers...which may not also be PCCs. If PCEP
> > takes precedence, and the actions are different, then there might be
> > nodes that take the BGP-defined action when not intended to...potentially
> > resulting in unexpected forwarding or rate-limiting of the traffic.
> >
> > Clearly, this issue is related to the different distribution models for
> > the information. If the operator took care of using BGP to distribute
> > FlowSpecs to only the PCCs, then this issue wouldn't exist. I would like
> > to see some text that provides guidance when using both distribution
> > mechanisms.
>
> This is a worthy Discuss!
>
> My understanding of the way that BGP FlowSpecs work is that it is not
> required that they be identical at different BGP routers. Indeed, part of
> the point is that different flows are treated differently at different
> routers.

Right.  That is not my concern; I wasn't clear enough.


As you know, there are multiple ways of setting up distribution of
FlowSpec in BGP.  One way is to have point-to-point BGP sessions from
a central box to specific routers where the actions are to be applied
-- limiting the distribution to just those BGP speakers.  In this
case, the FlowSpecs/Actions will likely be different (as you
describe).

I'm not concerned about that case.


Let me try again.  rfc5575bis says this:

   From an operational perspective, the utilization of BGP as the
   carrier for this information allows a network service provider to
   reuse both internal route distribution infrastructure (e.g., route
   reflector or confederation design) and existing external
   relationships (e.g., inter-domain BGP sessions to a customer
   network).

By reusing the "internal route distribution infrastructure", the
FlowSpecs are advertised, for example, from the originator to a route
reflector to its clients -- and maybe even further (consider a
hierarchical RR deployment).  Note that this type of distribution is
"normal" BGP, not specific to FlowSpec.

In this case, the FlowSpecs are the same everywhere -- there may n

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

> Responding to just the Discuss portion due to time constraints before the
> telechat...

Understood

Top posting:

This really feels like a problem for 5575bis. I'm beginning to think we
overstepped by even mentioning it in this document. I wanted to draw out the
risks and confusions (almost to say "don't do that") without trampling on
existing practice or messing with BGP. This is (clearly?) not the document
to tell people how to manage their BGP FlowSpecs, yet we wanted to inherit
as much as possible from BGP, yet we don't want people to damage themselves,
yet the scissors are sharp and they enjoy running.

You paragraph of suggestions of pointers of how/when to do AND and OR is a
reasonable starting point. But surely it is something that belongs in
5575bis?

Cheers,
Adrian

On Wed, Aug 26, 2020 at 09:51:52PM +0100, Adrian Farrel wrote:
> Hi Ben,
> 
> Thanks for the review.
> A lot of very helpful comments and discussions.
> All answers in line.
> I have a working copy with the edits (hint to co-authors: *I* have the
working copy :-)
> 
> Best,
> Adrian
> 
> > DISCUSS:
> >
> > As with the others, I also found this document to be quite easy to
> > read and well-structured; thank you! 
> 
> Kind of you to say so.
> 
> > This is a Discuss because I want to have a discussion, not because I'm
> > confident in the correctness of my position.  But it seems like the
> > ambiguity about when multiple flow specifications in single FLOWSPEC
> > object are treated as logical AND to narrow a single flow specification
> > versus treated as separate flow specifications per Section 8.4 could
> > lead to confusion, and it would be simpler and have less risk to stick
> > to the "one flow specification per FLOWSPEC object" model as discussed
> > in the rest of the document.  If the ability to define multiple flows
> > within a single FLOWSPEC object is retained, I think we need more
> > specific procedures for identifying when that is the case, quite
> > possibly with a specific enumeration of cases.
> 
> The specification of a flow can be complex. For example,
> Destination address = 64.6.64.0/24
> Destination port number = 53
> Packet length > 1600 bytes
> 
> These elements are each encoded in a separate Flow Specification TLV.
Combined (using AND), they describe the Flow Specification.
> 
> All of the elements of a Flow Specification (all of the Flow Specification
TLVs) are included in a single Flow Filter TLV thus providing a grouping.
Thus a Flow Filter TLV describes the Flow Specification.
> 
> A Flowspec Object can contain zero or one Flow Filter TLV. Thus the object
(when it contains a Flow Filter TLV) describes the Flow Specification.
> 
> A PCEP message can contain multiple Flowspec Objects thus applying the
function of the message to multiple Flow Specifications.
> 
> So far, so good.

Yup.

> A little confusingly, we might want to describe a Flow Specification as:
> Destination address = 64.6.64.0/24 or 64.6.65/24
> Destination port number = 53
> Packet length > 1600 bytes
> 
> This could be done by defining two separate specifications. But there is a
tendency to want to provide one Flow Filter TLV with four Flow Specification
TLVs indicating
> Destination address = 64.6.64.0/24
> Destination address = 64.6.65/24
> Destination port number = 53
> Packet length > 1600 bytes

I understand that this is the sort of thing that is done, and that it is an
attrative convenience...

> The parser is expected to know when to apply AND and when to apply OR to
construct the Flow Specification. I can't say I think this is hygienic, but
it is 'common' practice in the BGP world, and it is basically functional. So
we allow it as well (after all, it is probably the same code processing and
installing the Flow Specifications).

I'm mostly just worried about the latent risk of leaving it up to the
parser to just "know", since my parser may disagree with your parser.  It
may well be that this is a topic that should be handled in common for PCEP
and BGP (I don't have the BGP details at hand right now) and thus punted to
IDR, but I would feel a lot more comfortable if there was some specific
list of things that get OR treatment when appearing multiple times.  (Or is
the rule that if a single sub-TLV appears multiple times it's always OR,
and the AND is for sub-TLV types?  That's actually a pretty easy rule to
enforce...)  Src/dst IP address and port seem like prety obvious ORs, but
is there anything else?  What about the case of a packet length range, only
packets between 500 and 1500 bytes on this path, with smaller ones and
bigger ones getting their own paths?

> However, 8.4 points out the risks and confusions associated, and indicates
how those issues are resolved.

Inde

Re: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel]

Lovely, thanks.

I have this captured in the working copy.

Best,
Adrian

-Original Message-
From: Roman Danyliw  
Sent: 26 August 2020 22:14
To: adr...@olddog.co.uk; 'The IESG' 
Cc: draft-ietf-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; 
'Julien Meuric' 
Subject: RE: Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10: 
(with COMMENT)

Hi Adrian!

> -Original Message-
> From: Adrian Farrel 
> Sent: Wednesday, August 26, 2020 5:09 PM
> To: Roman Danyliw ; 'The IESG' 
> Cc: draft-ietf-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org; pce@ietf.org;
> 'Julien Meuric' 
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10:
> (with COMMENT)
> 
> Hi Roman,
> 
> > COMMENT:
> >
> > ** Section 12.  To refine what Ben Kaduk noted about the applicability
> > of [RFC6952], Section 2.5 seems to apply for me.
> 
> Yes, that it the relevant section, and I've added an explicit section pointer.
> 
> > ** Section 12.  Per “Therefore, implementations or deployments
> > concerned with protecting privacy MUST apply the mechanisms described
> > in the documents referenced above.”, it might be helpful to explicitly
> > call out the specific guidance to follow.  I believe that it’s to use
> > either IPSec per Section 10.4 –
> > 6 of RFC5440 or TLS per RFC8523 to provide transport security
> > properties.  The legacy references to TCP-AO and TCP MD5 in those
> documents don’t help here.
> 
> You're right about the advice and we can make it clear.
> MD5 obviously doesn't buy you much privacy and we can say that, too.
> Understanding that TCP-AO is "not widely implemented" if it is truly legacy, I
> wish someone would toggle the status to Historic or write some guidance on its
> non-use.

Right.  I concur on the implementation status of TCP-AO.  I was a too flip with 
the use of the word legacy.  To re-state my point, TCP-AO and MD5 don't get us 
anything for this privacy issue.  Let's just point to IPSec and TLS guidance 
(from the references already cited).

> > ** Section 12.  Per “Although this is not directly a security issue
> > per se, the confusion and unexpected forwarding behavior may be
> > engineered or exploited by an attacker.  Therefore, implementers and
> > operators SHOULD pay careful attention to the Manageability
> > Considerations described in Section 13.”, I completely agree.  I would
> > say it a bit more strongly that this complexity could be a security
> > issue.  I’m envisioning a situation where the complex forwarding
> > behaviors might create gaps in the monitoring and inspection of particular
> traffic or provide a path that avoids expected mitigations.
> 
> Right. So, to be clear, the threat here is "user error caused by confusion
> resulting from complexity." Yes, I can clarify that.

Exactly, and my prose was just showing an example of if circumstance where an 
attacker might exploit that.  

Roman

> Thanks again,
> Best,
> Adrian


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS)

[Adrian Farrel]

Hi Alvaro,

Responding to your Discuss separately from your Comment to get you an answer 
before the telechat.

> DISCUSS:
>
> §8.7: "it is possible that Flow Specifications will be distributed by BGP as
> well as by PCEP as described in this document...implementations MAY provide a
> configuration control to allow one protocol to take precedence over the other
> as this may be particularly useful if the Flow Specification make identical
> matches on traffic but have different actions."
>
> I understand the need to allow one protocol to take precedence over the other.
>
> The concern I have is that in BGP's distribution model FlowSpecs are forwarded
> to other BGP speakers...which may not also be PCCs.  If PCEP takes precedence,
> and the actions are different, then there might be nodes that take the
> BGP-defined action when not intended to...potentially resulting in unexpected
> forwarding or rate-limiting of the traffic.
>
> Clearly, this issue is related to the different distribution models for the
> information.  If the operator took care of using BGP to distribute FlowSpecs 
> to
> only the PCCs, then this issue wouldn't exist.  I would like to see some text
> that provides guidance when using both distribution mechanisms.

This is a worthy Discuss!

My understanding of the way that BGP FlowSpecs work is that it is not required 
that they be identical at different BGP routers. Indeed, part of the point is 
that different flows are treated differently at different routers.

Furthermore, before even considering PCEP, we need to recall that FlowSpecs can 
be installed by BGP or by direct user configuration at individual routers.

Now, when we look at PCEP installing FlowSpecs, they apply only on individual 
routers. They are used to classify traffic into LSPs at the head end of those 
LSPs (these are TE LSPs and not LDP LSPs). The FlowSpecs only have meaning at 
the head end of the LSPs and to consider distributing them to other nodes would 
be chaotic and wrong.

Whether the behaviour of the whole network is "unexpected" when different 
FlowSpecs are installed by different mechanisms is dependent on how carefully 
one is managing the system. If, for example, you have a mixed IP/MPLS network 
that used MPLS-TE, then you might consider that the TE-LSPs cause traffic to 
diverge from the shortest paths and that that fact could have unexpected 
consequences for how traffic is balanced in the network. Furthermore, if the 
TE-LSP doesn't go all the way to the destination, you can get tromboning and 
all sorts of undesirable effects. Yet, carefully managed TE is highly popular.

What this spec does (and all that this spec does) is provide a mechanism for 
the head end of LSPs to know what traffic to put on those LSPs. Currently this 
is done using any number of proprietary configuration tools. This offers a 
standardised approach that melds with the mechanism used to configure the LSPs.

FWIW, over the years we have been working on this document, I have repeatedly 
thought that we made a mistake to mention the term FlowSpec. The problem with 
the term is it makes people think "BGP" too readily. In the end, however, the 
mechanism for implementing packet filters for BGP and for directing traffic to 
LSPs is all in one place in all the implementations, so the common use of the 
term is practical.

Best,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel]

Hi Roman,

> COMMENT:
>
> ** Section 12.  To refine what Ben Kaduk noted about the applicability of
> [RFC6952], Section 2.5 seems to apply for me.

Yes, that it the relevant section, and I've added an explicit section pointer.

> ** Section 12.  Per “Therefore, implementations or deployments concerned with
> protecting privacy MUST apply the mechanisms described in the documents
> referenced above.”, it might be helpful to explicitly call out the specific
> guidance to follow.  I believe that it’s to use either IPSec per Section 10.4 
> –
> 6 of RFC5440 or TLS per RFC8523 to provide transport security properties.  The
> legacy references to TCP-AO and TCP MD5 in those documents don’t help here.

You're right about the advice and we can make it clear.
MD5 obviously doesn't buy you much privacy and we can say that, too.
Understanding that TCP-AO is "not widely implemented" if it is truly legacy, I 
wish someone would toggle the status to Historic or write some guidance on its 
non-use.

> ** Section 12.  Per “Although this is not directly a security issue per se, 
> the
> confusion and unexpected forwarding behavior may be engineered or exploited by
> an attacker.  Therefore, implementers and operators SHOULD pay careful
> attention to the Manageability Considerations described in Section 13.”, I
> completely agree.  I would say it a bit more strongly that this complexity
> could be a security issue.  I’m envisioning a situation where the complex
> forwarding behaviors might create gaps in the monitoring and inspection of
> particular traffic or provide a path that avoids expected mitigations.

Right. So, to be clear, the threat here is "user error caused by confusion 
resulting from complexity." Yes, I can clarify that.

Thanks again,
Best,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Benjamin Kaduk's Discuss on draft-ietf-pce-pcep-flowspec-10: (with DISCUSS and COMMENT)

[Adrian Farrel]

Hi Ben,

Thanks for the review.
A lot of very helpful comments and discussions.
All answers in line.
I have a working copy with the edits (hint to co-authors: *I* have the working 
copy :-)

Best,
Adrian

> DISCUSS:
>
> As with the others, I also found this document to be quite easy to
> read and well-structured; thank you! 

Kind of you to say so.

> This is a Discuss because I want to have a discussion, not because I'm
> confident in the correctness of my position.  But it seems like the
> ambiguity about when multiple flow specifications in single FLOWSPEC
> object are treated as logical AND to narrow a single flow specification
> versus treated as separate flow specifications per Section 8.4 could
> lead to confusion, and it would be simpler and have less risk to stick
> to the "one flow specification per FLOWSPEC object" model as discussed
> in the rest of the document.  If the ability to define multiple flows
> within a single FLOWSPEC object is retained, I think we need more
> specific procedures for identifying when that is the case, quite
> possibly with a specific enumeration of cases.

The specification of a flow can be complex. For example,
Destination address = 64.6.64.0/24
Destination port number = 53
Packet length > 1600 bytes

These elements are each encoded in a separate Flow Specification TLV. Combined 
(using AND), they describe the Flow Specification.

All of the elements of a Flow Specification (all of the Flow Specification 
TLVs) are included in a single Flow Filter TLV thus providing a grouping. Thus 
a Flow Filter TLV describes the Flow Specification.

A Flowspec Object can contain zero or one Flow Filter TLV. Thus the object 
(when it contains a Flow Filter TLV) describes the Flow Specification.

A PCEP message can contain multiple Flowspec Objects thus applying the function 
of the message to multiple Flow Specifications.

So far, so good.

A little confusingly, we might want to describe a Flow Specification as:
Destination address = 64.6.64.0/24 or 64.6.65/24
Destination port number = 53
Packet length > 1600 bytes

This could be done by defining two separate specifications. But there is a 
tendency to want to provide one Flow Filter TLV with four Flow Specification 
TLVs indicating
Destination address = 64.6.64.0/24
Destination address = 64.6.65/24
Destination port number = 53
Packet length > 1600 bytes

The parser is expected to know when to apply AND and when to apply OR to 
construct the Flow Specification. I can't say I think this is hygienic, but it 
is 'common' practice in the BGP world, and it is basically functional. So we 
allow it as well (after all, it is probably the same code processing and 
installing the Flow Specifications).

However, 8.4 points out the risks and confusions associated, and indicates how 
those issues are resolved.

> I also mention in the per-section comments several places where (IIUC)
> there seems to be a need to match the Speaker Entity Identifier TLV as
> well as the FS-ID value.  It might even be an exhaustive list, but
> please do a pass to check.

Handled in line in the Comments with cross-check to the whole document.

> COMMENT:
>
> 5575bis's validation procedures (§6) include things like "originator of
> the flow spec matches originator of best-match unicast route for the
> destination prefix in the flowspec".  This doesn't seem to apply to
> PCEP, so presumably we are supposed to ignore such requirements.  Is
> there a concrete list of which parts of the procedures are affected in
> this way?




> I agree with the TSV-ART reviewer that the Abstract and Introduction
> could likely be improved by a restructuring.

Oh ☹
I admit that I tend to write lengthy Abstracts, and that my style tends towards 
wordy.

However, looking back at this document it seems to me that both sections 
attempt to describe the background before saying what the document does. We 
could flip that, but I think it would cause confusion by using terms and 
concepts that haven't been established in the text.

Joe suggested adding paragraph 7 from the Introduction to the Abstract, so I 
will do that.

For the Introduction, Joe suggests splitting the Introduction to create a new 
Background section. This seems like personal style to me: I dislike terse 
Introduction sections that simply repeat the Abstract; I prefer to follow the 
sequence of the Abstract, but add more substance along the way.

Joe's other comment on the Introduction is as follows. It flows nicely into 
your next Comment so I'll handle the two together.

| It also seems odd that this paragraph (#6 of the intro) undermines
| the terminology of the document that this supplements (as cited
| in the abstract). These documents as a pair should have consistent
| use of terminology, coining new terms as needed rather than
| redefining a key term as different in the two.

> In some places we call out that our usage of "Flow Specification"
> diverges from that of 5575bis, since we do not have an "action", 

Re: [Pce] Erik Kline's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel]

Thanks again Erik,

Processing the details now...

> [ section 2 ]
>
> * "a flag is provided to indicate that the sender of a PCEP message
>  that includes a Flow Specification is intended to be installed as
>  a Longest Prefix Match route, or..."
>
>  This didn't scan too well for me.  It seems the subject is the sender
>  as written, but perhaps the message itself is the thing that
>  "is intended to be installed..."?
>
>  Oh, perhaps this is what's meant:
>
>  "a flag is provided to indicate that the sender of a PCEP message
>  that includes a Flow Specification intends it to be installed as a
>  Longest Prefix Match route or as a Flow Specification policy."

Yes, modulo s/that the/whether the/

> [ section 5 ]
>
> * Is it well-known whether multibyte numeric fields are network
>endian or not?

I think so. I think all PCEP integers are transmitted MSB first. Calling this 
one out for "clarification" would cause the reader to wonder whether it was in 
some way special (which it isn't).

> [ section 6 ]
>
> * "The TLVs follows" -> "The TLVs follow", I think

Well, maybe "The TLV follows" 

> [ section 7 ]
>
> * "carries one or more ... TLV" -> "...TLVs."

Well, you caused an 'argument' between me and my copy-editor wife ☹

I think this one is right. 
Warriner says "the verb agrees with the nearest subject."
Thus, "There is one or more cat," and "One or more dogs are in the box."

But for consistency with other places in the document, which has otherwise been 
entirely inconsistent, (and to save my marriage even though I know I'm right) 
I've added the 's'.

> * "defines following new types" -> "defines the following new types"

Ack

> * Purely out of curiosity, if either S=1 or G=1 can/should it be specified 
> that
>  the source/group addresses simply not be included (i.e. the bits indicate
>  not only that the field is not examined but that it's not included)?

Interesting, but I think that what happens then is you have to specify how to 
handle what happens if the addresses are included. That processing would either 
be to throw an error or to ignore the addresses. Furthermore, since the format 
of the structure is fixed, the address fields always exist and it is moot 
whether an address has been included and set to zero (e.g., 0.0.0.0) or whether 
it has been not included. Since processing can continue correctly by ignoring 
the addresses, it is better to go down that path.

> [ section 7.1 ]
>
> * "carries one or more ... TLV" -> "...TLVs."

There being no section 7.1, I think this is per the previous comment.

> [ section 8.4 ]
>
> * "will be place on a single tunnel" -> "will be placed into a single tunnel"
>perhaps?

Ack

> [ section 8.7 ]
>
> * Recommend splitting up the long sentence with ", however" ->
>  ".  However, ..."

Yes. Good.

> * "if the Flow Specification make" -> "if the Flow Specifications make"?

Ack

> * Maybe I've lost too much mental state between readings, but the final
>  paragraph, as written, makes me wonder how a FlowSpec gets installed in
>  the first place.  I assume I'm missing something in my naive reading.  =)

Flow Specifications can (sadly or happily, depending on your outlook on life) 
be installed in a number of ways including the CLI and BGP. This is just 
another way of doing stuff (mainly for a different purpose).

Best,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Martin Duke's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel]

Thanks, Martin.

> Sec 5. Specify the error if more than 1 TLV of any type is present.

Yes. Both TLVs earn the text...
  If
  more than one instance of this TLV is present, the first MUST be
  processed and subsequence instances MUST be ignored.

> Sec 7. The text is incomplete for the (*, G) case.

Ooops, yes.
Should read...

(*, G) - S bit = 1, G bit = 0, the Group multicast Address prefix is used to 
define the
 multicast flow, but the Source Address prefix is ignored.

Cheers,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Erik Kline's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel]

Nice collection of nits, Erik. Thanks.

Will attend to them when the next version comes out.

Best,
Adrian

-Original Message-
From: Erik Kline via Datatracker  
Sent: 23 August 2020 02:28
To: The IESG 
Cc: draft-ietf-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; 
Julien Meuric ; julien.meu...@orange.com
Subject: Erik Kline's No Objection on draft-ietf-pce-pcep-flowspec-10: (with 
COMMENT)

Erik Kline has entered the following ballot position for
draft-ietf-pce-pcep-flowspec-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/



--
COMMENT:
--

[ section 2 ]

* "a flag is provided to indicate that the sender of a PCEP message
  that includes a Flow Specification is intended to be installed as
  a Longest Prefix Match route, or..."

  This didn't scan too well for me.  It seems the subject is the sender
  as written, but perhaps the message itself is the thing that
  "is intended to be installed..."?

  Oh, perhaps this is what's meant:

  "a flag is provided to indicate that the sender of a PCEP message
  that includes a Flow Specification intends it to be installed as a
  Longest Prefix Match route or as a Flow Specification policy."

[ section 5 ]

* Is it well-known whether multibyte numeric fields are network
  endian or not?

[ section 6 ]

* "The TLVs follows" -> "The TLVs follow", I think

[ section 7 ]

* "carries one or more ... TLV" -> "...TLVs."

* "defines following new types" -> "defines the following new types"

* Purely out of curiosity, if either S=1 or G=1 can/should it be specified that
  the source/group addresses simply not be included (i.e. the bits indicate
  not only that the field is not examined but that it's not inclued)?

[ section 7.1 ]

* "carries one or more ... TLV" -> "...TLVs."

[ section 8.4 ]

* "will be place on a single tunnel" -> "will be placed into a single tunnel"
   perhaps?

[ section 8.7 ]

* Recommend splitting up the long sentence with ", however" ->
  ".  However, ..."

* "if the Flow Specification make" -> "if the Flow Specifications make"?

* Maybe I've lost too much mental state between readings, but the final
  paragraph, as written, makes me wonder how a FlowSpec gets installed in
  the first place.  I assume I'm missing something in my naive reading.  =)



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Éric Vyncke's No Objection on draft-ietf-pce-pcep-flowspec-10: (with COMMENT)

[Adrian Farrel]

Thanks Eric,

Yes, that's a good catch. Embarrassed that is sneaked through.

I now have 
  The Value field MUST be set to 0 and MUST be ignored on receipt.
in my working copy.

Best,
Adrian

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: 18 August 2020 11:14
To: The IESG 
Cc: draft-ietf-pce-pcep-flows...@ietf.org; pce-cha...@ietf.org; pce@ietf.org; 
Julien Meuric ; julien.meu...@orange.com
Subject: Éric Vyncke's No Objection on draft-ietf-pce-pcep-flowspec-10: (with 
COMMENT)

Éric Vyncke has entered the following ballot position for
draft-ietf-pce-pcep-flowspec-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/



--
COMMENT:
--

Thank you for the work put into this document. I found the text easy to read
albeit sometimes it could be shortened (section 1 for example). But, I prefer
clarity and ease of read to concise text.

I have only one non-blocking comment in section 4: documenting what is the
expected behavior when receiving a "Value" != 0 could be helpful (probably the
usual 'ignored').

I hope that this helps to improve the document,

Regards,

-éric



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Additional point: PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

[Adrian Farrel]

Looks like you need to update Chao Zhou's email address in the draft.

Adrian

-Original Message-
From: Pce  On Behalf Of Adrian Farrel
Sent: 16 August 2020 17:15
To: julien.meu...@orange.com; pce@ietf.org
Cc: draft-ietf-pce-pcep-extension-for-pce-control...@ietf.org
Subject: Re: [Pce] PCE WG LC for
draft-ietf-pce-pcep-extension-for-pce-controller

Hi Julien, WG, authors,

I'm listed as one of the eight Contributors to this document, although
my affiliation should read "Old Dog Consulting".

I was a co-author of RFC 8283, so I am generally glad to see protocol
work addressing this space.

This document is almost ready to progress, but there are quite a few
nits that we should take care of before asking to advance the document.
After that's done, I support this document being published as an RFC.

Thanks,
Adrian

===

Figures

If you make the table in Section 5.2 into "Figure 1" then you will not 
need to renumber Figure 2.

All figures should have a caption such as you have for Figure 2.

All figures should be mentioned explicitly in the text. Thus, instead of
saying "as shown below" you should say "as shown in Figure 2".  This is
important because:
- it helps the RFC Editor check that you are using all of the figures
- it protects the text from edits that might move it around in relation
  to the figure.

---

Abstract

s/(G)MPLS/MPLS and GMPLS/
s/PCEP protocol extensions/PCEP extensions/

---

Introduction

s/draft specify/document specifies/

---

Introduction

   The extension for PCECC in Segment Routing (SR) is specified in a
   separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr].

This paragraph is, of course, completely true. But it is absolutely
unclear what it is doing here. There has been no previous discussion of
SR in the document, and the only other mention of SR is in 5.5.9. I
think we can probably do without this paragraph.

---

2.

OLD
   Terminologies used in this document is same as described in the draft
   [RFC8283].
NEW
   Terminology used in this document is that same as that described in 
   [RFC8283].
END

---

3.

OLD
   it is assumed that label range to be used
NEW
   it is assumed that the label range to be used
END

OLD
   A future extension could add this capability
NEW
   A future extension could add the capability
END

OLD
   This document also allow a case where the label space is maintained
   by PCC itself
NEW
   This document also allows a case where the label space is maintained
   by the PCC itself
END

---

4.

OLD
   Following key requirements associated PCECC should be considered when
   designing the PCECC based solution:
NEW
   The following key requirements should be considered when
   designing the PCECC based solution:
END

---

5.3
s/This document specify/This document specifies/
s//new CCI object-type/new CCI object-types/

---

5.4
s/During PCEP Initialization Phase/During the PCEP Initialization Phase/
s/Path is setup/Path is set up/
s/sub-TLV in PCC's/sub-TLV in a PCC's/
s/PCE's OPEN message/a PCE's OPEN message/

---

5.4

   If the PCEP
   Speakers support the extensions of this draft but did not advertise
   this capability attempts a PCECC operation then a PCErr message with
   Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted
   PCECC operations when PCECC capability was not advertised) will be
   generated and the PCEP session will be terminated.

This is good. But you also need to include what happens if an
implementation that does not understand these extensions receives one.
I suspect you can do this with a reference to another document.

---

There are a couple of cases of s/a LSP/an LSP/

---

5.5.1

s/based on PCECC mechanism/based on the PCECC mechanism/
s/LSP-IDENTIFIER TLV MUST/An LSP-IDENTIFIER TLV MUST/
s/with D flags/with D flag/
s/and set up the/and sets up the/
s/include the central/includes the central/
s/The CC-ID is uniquely identify/The CC-ID uniquely identifies/
s/two CCI object/two CCI objects/
s/PCECC LSP is same as/PCECC LSP is the same as/
s/receives PCRpt message/receives a PCRpt message/   (twice)
s/The PCECC LSP are/The PCECC LSPs are/
s/In case where/In the case where/
s/label allocation are/label allocations are/
s/Similarly C bit/Similarly the C bit/

---

5.5.1

You have:
   This PCUpd message is as per [RFC8231] SHOULD include the path
   information as calculated by the PCE.

I think that you are not defining anything new here. You are just
describing what 8231 already says. So how about...

   Per [RFC8231], this PCUpd message should include the path
   information calculated by the PCE.

---

5.5.1

   The Ingress MAY further choose to deploy a
   data plane check mechanism and report the status back to the PCE via
   PCRpt message.

This is fine, but you should probably add some explanation of why an
Ingress might choose to do this.

---

5.5.1

   It should be noted that in this example, the request is made to the
   egress node with

Re: [Pce] PCE WG LC for draft-ietf-pce-pcep-extension-for-pce-controller

[Adrian Farrel]

Hi Julien, WG, authors,

I'm listed as one of the eight Contributors to this document, although
my affiliation should read "Old Dog Consulting".

I was a co-author of RFC 8283, so I am generally glad to see protocol
work addressing this space.

This document is almost ready to progress, but there are quite a few
nits that we should take care of before asking to advance the document.
After that's done, I support this document being published as an RFC.

Thanks,
Adrian

===

Figures

If you make the table in Section 5.2 into "Figure 1" then you will not 
need to renumber Figure 2.

All figures should have a caption such as you have for Figure 2.

All figures should be mentioned explicitly in the text. Thus, instead of
saying "as shown below" you should say "as shown in Figure 2".  This is
important because:
- it helps the RFC Editor check that you are using all of the figures
- it protects the text from edits that might move it around in relation
  to the figure.

---

Abstract

s/(G)MPLS/MPLS and GMPLS/
s/PCEP protocol extensions/PCEP extensions/

---

Introduction

s/draft specify/document specifies/

---

Introduction

   The extension for PCECC in Segment Routing (SR) is specified in a
   separate draft [I-D.zhao-pce-pcep-extension-pce-controller-sr].

This paragraph is, of course, completely true. But it is absolutely
unclear what it is doing here. There has been no previous discussion of
SR in the document, and the only other mention of SR is in 5.5.9. I
think we can probably do without this paragraph.

---

2.

OLD
   Terminologies used in this document is same as described in the draft
   [RFC8283].
NEW
   Terminology used in this document is that same as that described in 
   [RFC8283].
END

---

3.

OLD
   it is assumed that label range to be used
NEW
   it is assumed that the label range to be used
END

OLD
   A future extension could add this capability
NEW
   A future extension could add the capability
END

OLD
   This document also allow a case where the label space is maintained
   by PCC itself
NEW
   This document also allows a case where the label space is maintained
   by the PCC itself
END

---

4.

OLD
   Following key requirements associated PCECC should be considered when
   designing the PCECC based solution:
NEW
   The following key requirements should be considered when
   designing the PCECC based solution:
END

---

5.3
s/This document specify/This document specifies/
s//new CCI object-type/new CCI object-types/

---

5.4
s/During PCEP Initialization Phase/During the PCEP Initialization Phase/
s/Path is setup/Path is set up/
s/sub-TLV in PCC's/sub-TLV in a PCC's/
s/PCE's OPEN message/a PCE's OPEN message/

---

5.4

   If the PCEP
   Speakers support the extensions of this draft but did not advertise
   this capability attempts a PCECC operation then a PCErr message with
   Error-Type=19(Invalid Operation) and Error-Value=TBD3 (Attempted
   PCECC operations when PCECC capability was not advertised) will be
   generated and the PCEP session will be terminated.

This is good. But you also need to include what happens if an
implementation that does not understand these extensions receives one.
I suspect you can do this with a reference to another document.

---

There are a couple of cases of s/a LSP/an LSP/

---

5.5.1

s/based on PCECC mechanism/based on the PCECC mechanism/
s/LSP-IDENTIFIER TLV MUST/An LSP-IDENTIFIER TLV MUST/
s/with D flags/with D flag/
s/and set up the/and sets up the/
s/include the central/includes the central/
s/The CC-ID is uniquely identify/The CC-ID uniquely identifies/
s/two CCI object/two CCI objects/
s/PCECC LSP is same as/PCECC LSP is the same as/
s/receives PCRpt message/receives a PCRpt message/   (twice)
s/The PCECC LSP are/The PCECC LSPs are/
s/In case where/In the case where/
s/label allocation are/label allocations are/
s/Similarly C bit/Similarly the C bit/

---

5.5.1

You have:
   This PCUpd message is as per [RFC8231] SHOULD include the path
   information as calculated by the PCE.

I think that you are not defining anything new here. You are just
describing what 8231 already says. So how about...

   Per [RFC8231], this PCUpd message should include the path
   information calculated by the PCE.

---

5.5.1

   The Ingress MAY further choose to deploy a
   data plane check mechanism and report the status back to the PCE via
   PCRpt message.

This is fine, but you should probably add some explanation of why an
Ingress might choose to do this.

---

5.5.1

   It should be noted that in this example, the request is made to the
   egress node with C bit set in the CCI object to indicate that the
   label allocation needs to be done by the egress and it responds with
   the allocated label to the PCE.

This is a little ambiguous. "...it responds" - what is it?
Perhaps you should have:
"...done by the egress, and the egress responds..."

---

5.5.2.1

s/to setup an LSP based/to set up an LSP based/
s/included in LSP object/included in the LSP 

Re: [Pce] Genart last call review of draft-ietf-pce-pcep-flowspec-09

[Adrian Farrel]

Thanks for taking time to so the review, Roni.

Best,
Adrian
-Original Message-
From: Roni Even via Datatracker  
Sent: 03 July 2020 08:08
To: gen-...@ietf.org
Cc: pce@ietf.org; last-c...@ietf.org; draft-ietf-pce-pcep-flowspec@ietf.org
Subject: Genart last call review of draft-ietf-pce-pcep-flowspec-09

Reviewer: Roni Even
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-pce-pcep-flowspec-??
Reviewer: Roni Even
Review Date: 2020-07-03
IETF LC End Date: 2020-07-06
IESG Telechat date: Not scheduled for a telechat

Summary:
The document is ready for publication as standard track RFC

Major issues:

Minor issues:

Nits/editorial comments:



___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

[Adrian Farrel]

Thanks Rakesh,

 

It seems to me that associating an SR path in one direction with an RSVP-TE 
path in the other direction is *possible* but seems unlikely in the extreme. I 
would not want to take an action that made it impossible to add this feature 
should someone come up with a pressing desire, but it looks like an odd thing 
to specifically engineer into the solution at this stage.

 

Of course, a way to test this would be to send an email to SPRING and TEAS to 
ask this specific question. After all, the purpose of PCE is to serve as a tool 
to facilitate what the people in those two WGs are trying to do.

 

The two questions raised in the earlier threads are related to this, but do not 
quite cancel each other out.

1.  Do we need two different association types, one for RSVP-TE and one for 
SR?
2.  Is it an error if there is an attempt to associate an LSP with an SR 
path?

 

Best,

Adrian

 

From: Rakesh Gandhi  
Sent: 01 February 2020 16:46
To: Stone, Andrew (Nokia - CA/Ottawa) 
Cc: Dhruv Dhody ; pce@ietf.org; Farrel Adrian 

Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

 

Thanks Andrew.

Adding Adrian who had a similar comment in a different thread.

 

Hi Dhruv, Cheng,

 

For all other association types (VN, Policy, diversity, etc.), we do not have 
different types defined for RSVP and SR. If we use the same association type 
and limit the LSPs to be the same type (PST) in the bidirectional LSP, then may 
be implementation can handle the logic for the PST type accordingly? As IANA 
allocation has not been done, current implementation can be adjusted?

 

Thanks,

Rakesh

 

On Thu, Jan 23, 2020 at 9:40 PM Stone, Andrew (Nokia - CA/Ottawa) 
mailto:andrew.st...@nokia.com> > wrote:

Hi Rakesh,

 

Thanks for the reply and input. I initially had the same thought as well: "just 
migrate both sides at the same time". Only concern is of course some migration 
strategies choose to migrate regionally or node-by-node, rather than tunnel 
pairs. In this case, definitely will have to do both sides at the same time. It 
may not actually be that troublesome, since I'm not an operator just going by 
what I've heard from colleagues and theorizing the situation.

 

Cheers

Andrew

 

  _  

From: Rakesh Gandhi mailto:rgandhi.i...@gmail.com> >
Sent: Thursday, January 23, 2020 11:12 AM
To: Stone, Andrew (Nokia - CA/Ottawa) mailto:andrew.st...@nokia.com> >
Cc: Dhruv Dhody mailto:dhruv.i...@gmail.com> >; 
pce@ietf.org   mailto:pce@ietf.org> >
Subject: Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06? 

 

Hi Andrew,

 

Many thanks for your review comments. Please see below with ..

 

On Wed, Jan 22, 2020 at 10:57 PM Stone, Andrew (Nokia - CA/Ottawa) 
mailto:andrew.st...@nokia.com> > wrote:

Hi Dhruv,

Thanks again for the speedy reply. Comments below under 

Cheers
Andrew

On 2020-01-22, 8:01 AM, "Dhruv Dhody" mailto:dhruv.i...@gmail.com> > wrote:

Hi Andrew,

On Wed, Jan 22, 2020 at 12:06 AM Stone, Andrew (Nokia - CA/Ottawa)
mailto:andrew.st...@nokia.com> > wrote:
>
> Hi Dhruv,
>
> Thanks for the reply and feedback.
>
> Could an implementation of PCE not simply just return error during that 
situation? In diversity if too many LSPs grouped together and PCE 
computationally can't support it, it returns a PCERR. So I would reason that if 
bidirectionally associated and notify PCCs is necessary, but was configured 
between SR and RSVP, that's also an error due to the (current) unsupported 
feature set. I see this as trying to protect against day-0 misconfig by 
changing the wire encoding within the protocol (which I'm not necessarily 
against..). While I have doubt if it's a valid use case or requirement in a 
production deployment, and it may have been acknowledged before, but this 
essentially blocks associating SR LSP with RSVP LSP bidirectionally for PCE to 
compute.
>
> Since the overall workflow doesn't change by this new type def, and if 
SR<->RSVP associated is not reasonable requirement, and If consensus has 
already been reached on this, and implementation already exist, I'm okay with 
parking this topic.
>

The SR draft does expect all LSPs to be SR for the new association
type and thus easier to handle. If you use a common association type,
the behavior would be dependent on the PST for the first LSP that is
added to the association. We could end up in a situation where Peer 1
would add LSP 1 (SR) first and reject LSP 2 (RSVP-TE) and peer 2 would
add LSP 2 (RSVP-TE) first and reject LSP 1 (SR). Also there might be a
use for this mixed cases in future, which would require different
processing to be defined.


 

I will ponder on this some more. I'm undecided yet if the reasons to protect 
config/behaviour mismatch, outweigh just having one type encoding and defining 
the individual behaviours separately, which could also be up to the local 
policy defined by the 

Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-01.txt

[Adrian Farrel]

Hey WG!

Changes here are to address comments (and a Discuss) from the IESG.

The best thing to do (if you care) is to look at the diffs in the
datatracker. 

Questions and comments are (of course) welcome.

Best,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 23 January 2020 17:34
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: I-D Action: draft-ietf-pce-stateful-flags-01.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   : Updated Rules for Processing Stateful PCE Request
Parameters Flags
Author  : Adrian Farrel
Filename: draft-ietf-pce-stateful-flags-01.txt
Pages   : 7
Date: 2020-01-23

Abstract:
   Extensions to the Path Computation Element Communication Protocol
   (PCEP) to support stateful Path Computation Elements (PCEs) are
   defined in RFC 8231.  One of the extensions is the Stateful PCE
   Request Parameters (SRP) object.  That object includes a Flags field
   that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
   for tracking assigned flags.  However, RFC 8231 does not explain how
   an implementation should set unassigned flags in transmitted
   messages, nor how an implementation should process unassigned,
   unknown, or unsupported flags in received messages.

   This document updates RFC 8231 by defining the correct behaviors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-stateful-flags-01
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-flags-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-flags-01


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT)

[Adrian Farrel]

>> Every review comment deserves a response.
>
> You're too kind!

Never knowingly 

> Both proposed changes look good to me :)

Great, thanks. They are in the buffer.

A

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Alvaro Retana's Comments on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)

[Adrian Farrel]

Hi again Alvaro

A separate thread for your Comments (since your Discuss was so juicy!)

> (1) Compatibility
>
> The compatibility issue described at the end of §4 could result in all types 
> of
> unforeseen errors or more serious issues; even considering just the one flag
> defined in rfc8281: the R flag = LSP REMOVE.  One of the incompatibility
> results could be for an rfc8231-only implementation to set the R flag (it has
> unknown functionality to the sender), and then for an rfc8281 implementation 
> to
> receive the object and remove the LSP.  Not only could this result in
> operational issues by removing an LSP that shouldn't have been removed, but
> this action could also be considered a denial of service.
>
> This is not a new issue created by this document, but given that the latent
> compatibility issues are presented, then a more robust discussion is needed --
> I would like to see it in the Security Considerations, but using the
> Compatibility Considerations section works for me too.
>
> To be clear on my expectation.  The current text sounds tentative and even
> alarming: (paraphrasing) there's an issue that cannot be solved unless we 
> start
> over!   It would be nice to then add some text that talks about the potential
> effects: taking an unintended action, opening the door for an attacker, etc.

You are right to summarise this as "there is an issue that can't be solved 
unless we start over". But this has to be caveated by "examination of existing 
implementations, ad understanding of how people normally implement around this 
type of issue means it is probably not a problem".

You are right that there is an existing security issue, and that by not 
publishing this document we perpetuate that issue. As the current Security 
section says " by defining the expected behavior of implementations, this 
document may improve the stability of networks and thus reduce the attack 
surface."

We could expand that text to explain the ways in which the stability might be 
improved and the attack surface reduced. I.e., we could talk more about how 
networks might be unstable without this "fix" and we could outline the current 
attack surfaces. Is that what you're looking for?

>  (2) Going back to the specification:
>
>   Flags (32 bits): This document does not define any flags.
>  Unassigned flags MUST be set to zero on transmission and MUST be
>  ignored on receipt.  Implementations that do not understand any
>  particular flag MUST ignore the flag.
>
> Aren't the two Normative sentences redundant?  The most likely reason for a
> receiver to not understand a flag is for it to not have it implemented, which
> is the same as it considering it not assigned.  Are there cases that I'm
> missing which require both statements?  Perhaps s/Unassigned/Unknown and 
> remove
> the second sentence.

Well, I may be a pedant here, but whether a flag is assigned or not is a matter 
of IANA fact. Whether an implementation "considers a flag to be not assigned" 
(I paraphrase) is a matter for an implementation. It is possible that an 
implementation is aware of the IANA registration but does not support or has no 
awareness of the meaning of a flag.

That said, even if the statements are redundant, is it actively harmful to 
include both? Does it cause confusion or possibly result in broken 
implementations?

Best,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-stateful-flags-00: (with DISCUSS and COMMENT)

[Adrian Farrel]

Hello Alvaro,

Thanks for this Discuss. I think you found a hole in 
draft-ietf-pce-lsp-control-request. It doesn't look like a big hole because if 
you tried to apply both the C and the R flag, presumably the R flag would get 
executed making the C flag irrelevant. But I agree that the clarity of how to 
handle "conflicting" flags is missing.

Now we have to work out how to handle it.

The options seem to be:
1. Set a rule, as you suggest, that documents that define new flags MUST define 
how to handle the case when the new flags contradict or clash with existing 
flags. Fix draft-ietf-pce-lsp-control-request according to that rule.
2. Fix draft-ietf-pce-lsp-control-request to clarify how the C flag interacts 
with other existing flags (specifically the R flag)
3. Define the processing of messages with "conflicting" flags

1.requires a specification and a modification to 
draft-ietf-pce-lsp-control-request
2. requires a modification to draft-ietf-pce-lsp-control-request
3. requires a specification (that updates 8231)

I agree that this document could be the home for the specification in 1 or 3. 
But it could also be argued (especially for 3) that a new document with some 
thought and WG consensus on this new point is required. While the title of this 
document certainly puts that work in scope, I don't see that we necessarily 
have to hold back the simple clarification in this document in order to work on 
the other (perfectly valid) point.

I would also say that documents that apply 2119 language to future documents 
are not necessarily successful. That is, constraining the authors of future 
documents is notoriously (but not impossibly) hard. 

That makes me think that options 2 or 3 are best. Option 2 does not require a 
modification to this document, but does require pulling 
draft-ietf-pce-lsp-control-request back to fix it. Option 3 does not 
necessarily require a change to this document *if* a new document is written, 
and does not require pulling draft-ietf-pce-lsp-control-request back.

This is a worthy Discuss! But I don't know how to resolve it as a document 
author.

Thanks,
Adrian

--
DISCUSS:
--

The acknowledgement to the authors of I-D.ietf-pce-lsp-control-request prompted
me to go take a look at that document and refresh my mind on the fact that it
defines a new flag called LSP-Control Request Flag (C).  I find it hard to
resolve in my mind when it would make sense for the R (LSP REMOVE from rfc8281)
and C flags to be set at the same time.

I couldn't find in rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request or this
document any discussion about the ability (or not) to set more than one Flag at
a time.

In line with it's title, I would like to see this document include rules about
processing of multiple flags.  I know that it is not possible to set out rules
for the interaction of yet-to-be-defined flags, but at least adding text to the
effect of "documents defining additional flags MUST discuss how they interact
with existing flags" would go a long way.

I am balloting DISCUSS because even though this document is not introducing new
issues, the combination of what is defined in
rfc8231/rfc8281/I-D.ietf-pce-lsp-control-request does...and a document titled
"Updated Rules for Processing Stateful PCE Request Parameters Flags" is then
the optimal place to address them.

[Aside: If this DISCUSS is resolved as suggested above, then
I-D.ietf-pce-lsp-control-request, which is on the RFC EDitor's queue, will have
to be updated.]

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-stateful-flags-00: (with COMMENT)

[Adrian Farrel]

> Thanks for this clear and well-written document!  I just have a couple
> of editorial comments that probably don't even need a response.

Thanks for reading, Ben.

Every review comment deserves a response.

> Section 4
>
>  There will remain an issue with compatibility between implementations
>  of RFC 8231 that might set any of the unassigned flags, and current
> (such as [RFC8281]) and future (such as
>  [I-D.ietf-pce-lsp-control-request]) specifications.  That problem
>  cannot be fixed in old implementations by any amount of
>  documentation, and can only be handled for future specifications by
>  obsoleting the Flags field and using a new technique.  Fortunately,
>  however, most implementations will have been constructed to set
>  unused flags to zero which is consistent with the behavior described
>  in this document.
>
> I had a little bit of trouble reading this, as I keep expecting the
> first sentence to be saying that there is a legitimately-allocated flag
> value that is set with intent to change behavior, but it doesn't really
> say anything specifically about a flag value getting allocated (or
> used).

How about this becomes...

  There will remain an issue with compatibility between implementations
  of RFC 8231 that might set any of the unassigned flags, and current
 (such as [RFC8281]) and future (such as
  [I-D.ietf-pce-lsp-control-request]) specifications that assign specific
  meanings to flags if set.

> W.r.t. obsoleting Flags vs. relying on "most implementations" to be
> consistent with this document's recommendations, is it worth being more
> clear about the conclusion that this document is drawing, namely that
> the risk of bad interactions is sufficiently small that there is no
> desire to incur the cost of obsoleting/replacing the Flags field?

How about
OLD
   Fortunately,
   however, most implementations will have been constructed to set
   unused flags to zero which is consistent with the behavior described
   in this document.
NEW
   Fortunately,
   however, most implementations will have been constructed to set
   unused flags to zero which is consistent with the behavior described
   in this document and so the risk of bad interactions is sufficiently
   small that there is no need to obsolete the existing Flags field.
END

Thanks,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Adoption of draft-li-pce-sr-bidir-path-06?

[Adrian Farrel]

Hey Julien, WG,

I have reviewed draft-li-pce-sr-bidir-path as part of the adoption poll
and I have a few comments below.

Overall, this seems like a simple combination of two existing functions:
- associated bidirectional
- SR
So it should be straightforward and the function is clearly needed, and
the working group should adopt it if there is enough support.

Thanks,
Adrian

===

Please (please, please) could author teams sort out their front page
author list before requesting WG adoption. If the authors don't reduce
themselves to a maximum of five, the chairs will have to do it, and I
don't think anyone wants that!

---

Abstract

   This document defines PCEP extensions for grouping two reverse
   unidirectional SR Paths into an Associated Bidirectional SR Path when
   using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as
   well as when using a Stateless PCE.

I don't think it is "two reverse unidirectional SR paths". One of them
is normal and the other is reverse. So how about...

   This document defines PCEP extensions for grouping two unidirectional
   SR Paths (one in each direction in the network) into a single
   Associated Bidirectional SR Path.  The mechanisms defined in this
   document can also be applied using a Stateful PCE for both PCE-
   Initiated and PCC-Initiated LSPs, as well as when using a Stateless
   PCE.

---

Section 1

s/SR supports to steer packets/SR supports steering packets/

---

Section 1

   Currently, SR networks only support unidirectional paths.  However,
   bidirectional SR Paths are required in some networks, for example, in
   mobile backhaul transport networks.  The requirement of bidirectional
   SR Path is specified in [I-D.ietf-spring-mpls-path-segment].

I suggest...

   SR is specified for unidirectional paths.  However, some applications
   require bidirectional paths in SR networks, for example, in mobile
   backhaul transport networks.  The requirement for bidirectional
   SR Paths is specified in [I-D.ietf-spring-mpls-path-segment].

---

Section 1

OLD
   [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping
   two reverse unidirectional MPLS TE LSPs into an Associated
   Bidirectional LSP when using a Stateful PCE for both PCE-Initiated
   and PCC-Initiated LSPs as well as when using a Stateless PCE.
NEW
   [I-D.ietf-pce-association-bidir] defines PCEP extensions for grouping
   two unidirectional MPLS TE LSPs into an Associated Bidirectional LSP 
   when using a Stateful PCE for both PCE-Initiated and PCC-Initiated
   LSPs as well as when using a Stateless PCE.
END

---

3.1 and 7.1

Why do you need a new Association Type? 
If draft-ietf-pce-association-bidir was changes as:
OLD
   Value NameReference
   -
   TBD1 Single-sided Bidirectional LSP Association Group [This document]
   TBD2 Double-sided Bidirectional LSP Association Group [This document]
NEW
   Value NameReference
   -
   TBD1 Single-sided Bidirectional Association Group [This document]
   TBD2 Double-sided Bidirectional Association Group [This document]
END
then you could use the second of these for your use case. The type of
path being associated would/should be the same for both paths in the
association (but maybe there would be a future case with an LSP in one
direction and an SR path in the other direction? but see section 5.3)
and the type of path known from the PCEP message.

---

Section 5

   The PCE SHOULD inform the reverse SR Paths to
   the ingress PCCs and vice versa.

Under what circumstance MAY the PCE choose to not do this?

---

5.3 and 7.2

Depending on how you handle the point for 3.1, you may need to fine tune
this error code.  One way approach might be to make a change to 
draft-ietf-pce-association-bidir as:
OLD 
   Error Type  Description  Reference
   ---
29 Association Error

   Error value: TBD2This document
   Bidirectional LSP Association -
   Path Setup Type Mismatch
NEW
   Error Type  Description  Reference
   ---
29 Association Error

   Error value: TBD2This document
   Bidirectional Association -
   Path Setup Type Mismatch
END

---

Having made the suggestions for 3.1 and 5.3, I wonder how much is 
different from draft-ietf-pce-association-bidir. Is this just a small
explanation of the use of that draft in the SR network

---

You should explicitly reference the figures (by name) from the text.

---

Thanks for Section 6. I find it really helpful.

---

-Original 

Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Thanks Pavan,

It’s good to have this documented clearly.

 

Personally, I am amused/confused that *how* packets are intercepted for 
classification (via a routing entry or via a data plane filter) is important to 
the specification of this protocol. That is, the protocol says “packets that 
match this flowspec MUST be placed on this LSP/path”. How an implementation 
chooses to achieve that is, IMHO, not material to the on-the-wire behaviour. 
That is, the packets will come in and will be placed on the path, and the 
protocol instructions to achieve it do not need to tell anyone how to achieve 
it.

 

This is probably closest to your option 1. That is, an implementation may 
choose to implement this however it wants.

 

It would be wrong, also IMHO, to imply that an implementation must install a 
data plane filter to handle PCEP flowspecs. That depends (of course) on how you 
define a data plane filter.

 

As to draft-ietf-pce-binding-label-sid, I fear I detect mission creep. What was 
originally a simple association of a binding SID to a PCEP message now also has 
an element of flowspec built in. I wonder whether that document shouldn’t refer 
to draft-ietf-pce-flowspec if it wants to describe what traffic to associate 
with a path.

 

Like you, I would like to hear more from the working group.

 

Cheers,

Adrian

 

From: Vishnu Pavan Beeram  
Sent: 10 January 2020 05:45
To: Adrian Farrel 
Cc: pce@ietf.org; draft-ietf-pce-pcep-flows...@ietf.org
Subject: Re: [Pce] A discussion point for draft-ietf-pce-pcep-flowspec

 

Adrian, Hi!

 

Much Thanks for starting this thread! There are multiple implementations that 
support user-triggered installation/uninstallation of destination-IPv4/IPv6 
prefixes bound to a TE Path (installation of routes subject to longest prefix 
match based forwarding) and it is important to have this behavior covered in 
PCEP.

 

I’m listing 3 options that were considered for addressing this item:

1.  Add a new sub-section to Section 8 of  
stating that an implementation receiving a FLOWSPEC object that carries only 
destination IPv4/IPv6 TLVs may choose to not install any data-plane filters and 
instead install routes that are subject to longest prefix match (LPM) based 
forwarding. With this option, the controller has no say in how the network 
element processes these destination IPV4/IPv6 TLVs.
2.  Introduce a new flag in the FLOWSPEC object to explicitly indicate that 
routes subject to LPM based forwarding MUST be installed. When this flag is 
set, the FLOWSPEC object MUST carry only destination IPv4/IPv6 TLVs.
3.  Do not use the FLOWSPEC object at all for this; Use the TE-PATH-BINDING 
TLV (introduced by draft-ietf-pce-binding-label-sid) instead. This requires the 
addition of a couple of new Binding Types (BT) to indicate destination-IPV4 and 
destination-IPv6 bindings. This also requires us to add the ability to encode 
multiple Path Bindings (list) in the same message and the ability to remove 
specific Path Bindings in a given message. 

 

Based on some offline conversations with interested parties, there is a strong 
need to have an explicit indication for this type of behavior (avoid ambiguity 
with respect to filtering) -- so that makes Option 1 undesirable. There is also 
a requirement to carry a mix of install and uninstall destination prefixes 
associated with a path in the same message. The way the FLOWSPEC object is 
currently defined (the R flag is specified per FLOWSPEC object and not per TLV; 
parity with BGP), you would need one object to carry the install prefixes and 
one more to carry the uninstall prefixes. Given all this, there is some 
consensus among interested parties to implement this behavior using the 
TE-PATH-BINDING TLV. Note that this also means that 
draft-ietf-pce-pcep-flowspec can proceed as is.

 

@WG -- Any thoughts?

 

Regards,

-Pavan

 

On Sun, Jan 5, 2020 at 4:14 PM Adrian Farrel mailto:adr...@olddog.co.uk> > wrote:

Hi WG,

I received a couple of private emails about draft-ietf-pce-pcep-flowspec.

Since they were private, I will try to be circumspect about who they were
from.

The sender asked to have a flag attached to a flow specification that
indicates that it can be installed as a static route and thus not subject to
a firewall rule so the longest prefix matching can be performed to
manipulate route resolution for an LSP.

The request also said that traditionally flow-specifications result in
firewall rules and those rules operate on packets before longest prefix
match. We want to install static routes, the equivalent of installing a
prefix for an LSP and if we treat a flowspec as a static route we can mess
things up like rule ordering and so on.

The sender suggested that there are currently some draft(s) regarding this
behavior for BGP flowspec as well, but was not able to point me at them.

I asked for some clarifications and got back:

"What BGP-FS does is install data-plane filters.

Re: [Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Hi Julien,

Long ago you sent your review. Comments in line.

At the same time, we see that IDR has basically completed work on 
draft-ietf-idr-rfc5575bis and we think we should update this document to use 
that as a reference instead of RFC 5575 and RFC 7674.

Finally, someone contacted us privately to ask that we add a flag to a PCEP 
flowspec to indicate that it should not be installed as a data plane filter, 
but should be installed as a 'normal route' with longest prefix matching. That 
is a simple change, but nevertheless a change of technical substance. I'll send 
a separate email to the list to see whether anyone else is interested and 
determine whether we can craft some text.

I'll do a new revision and then start the thread for the additional point noted 
above.

Best wishes for the New Year,
Adrian

===

> I still have one pending question, related to section 8.7. (Priorities
> and Overlapping Flow Specifications). I understand this section as
> "priorities within PCEP-installed flow specs follow the same ordering
> rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at a
> device supporting both protocols to install flow specs:
> - Is there an implicit scope associated to each set of flow specs making
>   them mutually exclusive?
> - If both sets can overlap, can we assume that priority rules do not
>   care about the protocol used to install the flow specs?
> Adding a couple of sentences may be enough to clarify that.

You raise a very good point. I am not certain how often this is going to arise, 
but it seems almost certain that were we to decide it could never arise, it 
would immediately become a requirement from the field. So we should address it.

Now, draft-ietf-idr-rfc5575bis-18.txt talks only about BGP, but section 5.1 
gives a description of how flow specifications are ordered for traffic matching 
regardless of what order they arrive in BGP. I think we should assume that all 
traffic is open to all flowspecs whether installed by BGP for firewalls or 
routing, or installed by PCEP for classification onto traffic paths (LSPs or SR 
paths). I believe that similar work is being looked at for classification of 
traffic onto service function chains, and I imagine that those flowspecs might 
also coincide with BGP and PCEP flowspecs.

I think that all we need do is:
- call out that both protocols might be simultaneously present and distributing 
flowspecs for installation
- make the observation that the rules defined in section 5.1 of 
draft-ietf-idr-rfc5575bis apply regardless of which protocol distributed the 
flowspec.

That brings me to the text in 8.7:
OLD
   Flow specifications can overlap.  For example, two different flow
   specifications may be identical except for the length of the prefix
   in the destination address.  In these cases the PCC must determine
   how to prioritize the flow specifications so as to know to which path
   to assign packets that match both flow specifications.  That is, the
   PCC must assign a precedence to the flow specifications so that it
   checks each incoming packet for a match in a predictable order.

   The processing of BGP Flow Specifications is described in [RFC5575].
   Section 5.1 of that document explains the order of traffic filtering
   rules to be executed by an implementation of that specification.

   PCCs MUST apply the same ordering rules as defined in [RFC5575].
NEW
   Flow specifications can overlap.  For example, two different flow
   specifications may be identical except for the length of the prefix
   in the destination address.  In these cases the PCC must determine
   how to prioritize the flow specifications so as to know to which path
   to assign packets that match both flow specifications.  That is, the
   PCC must assign a precedence to the flow specifications so that it
   checks each incoming packet for a match in a predictable order.

   The processing of BGP Flow Specifications is described in 
   [I-D.ietf-idr-rfc5575bis].  Section 5.1 of that document explains the
   order of traffic filtering rules to be executed by an implementation
   of that specification.

   PCCs MUST apply the same ordering rules as defined in 
   [I-D.ietf-idr-rfc5575bis].

   Furthermore, it is possible that Flow Specifications will be distributed
   by BGP as well as by PCEP as described in this document.  In such 
   cases implementations supporting both approaches MUST apply the
   prioritization and ordering rules as set out in [I-D.ietf-idr-rfc5575bis]
   regardless of which protocol distributed the Flow Specifications,
   however implementations MAY provide a configuration control to 
   allow one protocol to take precedence over the other as this may be
   particularly useful if the Flow Specification make identical matches
   on traffic but have different actions.  It is RECOMMENDED that when
   two Flow Specifications distributed by different protocols overlap,
   and especially when one acts to replace another, 

[Pce] Shepherd review of draft-ietf-pce-stateful-pce-lsp-scheduling

[Adrian Farrel]

Hi authors,

Just doing the shepherd write-up after working group last call and I have a
nit in section 10.3

You ask for a new registry of bits, but you don't tell IANA the size of the
registry.

I think, to be consistent with (e.g.)
https://www.iana.org/assignments/pcep/pcep.xhtml#stateful-pce-capability-tlv
-flag-field you should have:

OLD
   The following values are defined in this document:

   BitDescriptionReference
   0  R-bit  This document
   1  C-bit  This document
   2  A-bit  This document
NEW
   IANA is requested to populate this registry as follows:

   BitDescriptionReference
   0  R-bit  This document
   1  C-bit  This document
   2  A-bit  This document
   3-7  Unassigned
END

However, please also consider that other TLV bit registries have started
assigning bits from the largest number (sometimes 31, sometimes 15) counting
downwards. This is not important, just "interesting".

Afraid we need a new revision before we can advance the document. While
you're at it, can you fix the references noted by idnits.

Thanks,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-gmpls-pcep-extensions-15: (with COMMENT)

[Adrian Farrel]

Hi Ben,

In the absence of a response from the authors this last month, I'm jumping
in because I want to see this published.

Authors/shepherd/chairs/AD: attached is an xml file that makes these
changes. I can't post it cos I'm not an author.

Cheers,
Adrian

===

> Thank you for addressing my Discuss points!

Thanks for clearing.

> I do have some additional comments on the -15.

Perfect. I'm trying to answer them below.

> Section 2.3
>
> I'm still a bit concerned that the references linked from Table 4 may not
> provide a clear description of what count as Traffic Parameters for our
> purposes (and how they are encoded), but not in a way that I can express
> more concretely.  Perhaps this is made clear by some RSVP-TE documents
> with which I am not familiar.

Agree that it is pretty convoluted. But I just checked all of the references
and they are clear how to encode the traffic parameters for each of the
different technology types in RSVP-TE. And since the PCEP objects are direct
copies of the RSVP-TE ones, and since they are describing the same things, I
think we are safe.

It's true that it's a lot of reading, but the PCE that supports one of these
bandwidth types must understand the technology as well as an RSVP-TE
implementation that signals one.

I think we're OK on this point.

> Section 2.5.1
>
>   root and other endpoints TLVs are the leaves.  The root endpoint MUST
>   be the same for all END-POINTS objects.  If the root endpoint is not
>
> I'm not sure how broadly scoped this restriction is -- it is, e.g.,
per-LSP?

This is all in the scope of a single PCEP request message for a path. So,
yes, per LSP, but multiple END-POINT objects can be present on one request.
 
So...
OLD
   The root endpoint MUST be the same for all END-POINTS objects.
NEW
   The root endpoint MUST be the same for all END-POINTS objects
   carried in a single PCEP request message.
END

> Section 2.5.2.5
>
>   with L bit cleared.  At most 2 LABEL_SET TLVs MAY be present with the
>   O bit set, with at most one of these having the U bit set and at most
>   one of these having the U bit cleared.  For a given U bit value, if
>
> This went MUST->MAY in this rev, though I think it might be fine to just
use
> a lowercase "may", since the requirements language doesn't map terribly
well
> to the restriction we're making.

I would prefer to make this definitive. I think the language is all mixed
around. How about we do:

OLD
   At most 2 LABEL_SET TLVs MAY be present with the
   O bit set, with at most one of these having the U bit set and at most
   one of these having the U bit cleared.
NEW
   There MUST NOT be more than two LABEL_SET TLVs present with the
   O bit set. If there are two LABEL_SET TLVs present, there MUST NOT
   be more than one with the U bit set, and there MUST NOT be more 
   than one with the U bit cleared.
END
















]>


  

PCEP extensions for GMPLS

  Juniper
  
cmarga...@juniper.net

  


  Telefonica Investigacion y Desarrollo
  

  C/ Ronda de la Comunicacion
  Madrid
  
  28050
  Spain

+34 91 4833441

oscar.gonzalezded...@telefonica.com
  


  Huawei Technologies
  

  F3-5-B RD Center, Huawei Base
  Bantian, Longgang District 
  Shenzhen
  
  518129
  P.R.China

zhangfa...@huawei.com

  






Routing
Network Working Group
RSVP-TE
GMPLS
PCE


  A Path Computation Element (PCE) provides path computation functions
  for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
  networks. Additional requirements for GMPLS are identified in
  RFC7025.
  
  
This memo provides extensions to the Path Computation Element
communication Protocol (PCEP) for the support of the GMPLS control plane
to address those requirements.
  

  
  

  Although  defines the PCE architecture and framework for both MPLS and GMPLS networks, most preexisting PCEP RFCs , , ,  are focused on MPLS networks, and do not cover the wide range of GMPLS networks. This document complements these RFCs by addressing the extensions required for GMPLS applications and routing requests, for example for Optical Transport Network (OTN) and Wavelength Switched Optical Network (WSON) networks.

  The functional requirements to be addressed by the PCEP
  extensions to support these applications are fully described in  and .
  

  


This document uses terminologies from the PCE architecture document , the PCEP documents including , , , ,  and ,
and the GMPLS documents such as ,  and so
on.  Note that it is expected the reader is familiar
with these documents.
The following abbreviations are used in this document

   

Re: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

[Adrian Farrel]

Hi,

I wouldn't object to any solution.
- What Dhruv suggests
- Just 32 bits and define a new TLV if more bits are ever needed

Best,
Adrian

-Original Message-
From: Dhruv Dhody  
Sent: 02 December 2019 05:28
To: xiong.q...@zte.com.cn
Cc: Farrel Adrian ; Stone, Andrew (Nokia - CA/Ottawa) 
; Loa Andersson ; pce@ietf.org
Subject: Re: [Pce] [pce] :New Version Notification for 
draft-xiong-pce-lsp-flag-00.txt

Hi Quan,

> But for the last issue, I am not sure if the length of 32 bits is good or 
> not. If 32 bits is enough for the extensions of other I-Ds?
>
> What is your suggestion?

I can think of one case: PCE capability flags in [1], where we defined
it as an array of units of 32-bit flags   numbered from the most
significant as bit zero, where  each bit represents one flag. In the
corresponding IANA registry [2], we maintained it as 32 bits for now,
which can be easily updated by a future document when needed.

As a WG contributor, I think it is better to be future proof even
though 32 bits seems good enough at the present.

Thanks!
Dhruv


[1] https://tools.ietf.org/html/rfc5088#section-4.5
[2] 
https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#ospfv2-parameters-14

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] [pce] :New Version Notification for draft-xiong-pce-lsp-flag-00.txt

[Adrian Farrel]

Hi Quan,

 

Thanks for picking up this work. You are right that we need a solution.

 

A couple of points about your draft…

 

I don’t think it is necessary or advisable to repeat the format of the existing 
PLSP-ID object, or to list the currently-assigned bits and meanings. Doing so 
creates potential conflict between two different normative documents.

 

I believe that processing the TLVs in the object is mandatory, so I do not 
believe that you need to use a bit (bit 0) in the existing flags field to 
indicate that the LSP-Extended-Flags TLV is present. It will be found if it is 
there. (I don’t feel strongly about this, and other may find the indication to 
be useful).

 

You have not given a value for the Length field in the LSP-Extended-Flags TLV. 
Is this because you intend that the TLV should scale if more than 32 bits are 
needed? If so, you should give some clues about processing. If not, you should 
just set the value.

 

You need to describe backwards compatibility. How will legacy implementations 
process this TLV and what will be the effect on the setting of any bits?

 

I think that in Singapore someone suggested comparing with the work done for 
RSVP-TE LSP Attributes. See RFC 5420. In that work we defined two TLVs to cover 
attributes that must be processed, and attributes that may be ignored. I’m not 
sure you need this, but think about it.

 

I think section 6.1 is broken. You don’t need two flags, do you?

 

You need to ask IANA for a new TLV type for your new TLV.

 

You need to ask IANA for a new registry to track the bits in your new TLV.

 

Cheers,

Adrian

 

From: Pce  On Behalf Of xiong.q...@zte.com.cn
Sent: 28 November 2019 03:44
To: andrew.st...@nokia.com; dhruv.i...@gmail.com; l...@pi.nu
Cc: pce@ietf.org
Subject: [Pce] [pce] :New Version Notification for 
draft-xiong-pce-lsp-flag-00.txt

 

Hi all,

 

I  have summitted the draft which proposes a new LSP-EXTENDED-FLAG TLV for LSP 
object to extend the length of the flag field.

Could you please give me some suggestions about the format?

 

Thanks,

Quan

 

 

原始邮件

发件人：internet-dra...@ietf.org   
mailto:internet-dra...@ietf.org> >

收件人：熊泉00091065;

日 期 ：2019年11月27日 15:54

主 题 ：New Version Notification for draft-xiong-pce-lsp-flag-00.txt


A new version of I-D, draft-xiong-pce-lsp-flag-00.txt
has been successfully submitted by Quan Xiong and posted to the
IETF repository.

Name:draft-xiong-pce-lsp-flag
Revision:00
Title:LSP Object Flag field of Stateful PCE
Document date:2019-11-26
Group:Individual Submission
Pages:6
URL:
https://www.ietf.org/internet-drafts/draft-xiong-pce-lsp-flag-00.txt
Status: https://datatracker.ietf.org/doc/draft-xiong-pce-lsp-flag/
Htmlized:   https://tools.ietf.org/html/draft-xiong-pce-lsp-flag-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-xiong-pce-lsp-flag


Abstract:
   RFC8231 describes a set of extensions to PCEP to enable stateful
   control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP.
   One of the extensions is the LSP object which includes a Flag field
   and the length is 12 bits.  However, 11 bits of the Flag field has
   been assigned in RFC8231, RFC8281 and RFC8623 respectively.

   This document updates RFC8231 by defining a new LSP-EXTENDED-FLAG TLV
   for LSP object to extend the length of the flag.


  


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.

The IETF Secretariat

 

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Thanks, Julien.

We have received a private communication from someone about the same section so 
the authors are going to take a little time to try to work over this section. 
We'll see whether our changes make enough difference to warrant re-polling that 
section with the WG.

Cheers,
Adrian
--
Bored with reading Interent-Drafts?
Read some fairy stories for adults of all ages instead.
• Tales from the Wood
• More Tales from the Wood
• Tales from Beyond the Wood
• Tales from the Castle
Get them on line https://www.feedaread.com/profiles/8604/
Or buy a signed copy from me by post
*** Stop me in the corridor at IETF-106 to get a copy ***



-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: 15 November 2019 15:02
To: draft-ietf-pce-pcep-flows...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] Shepherd Review of draft-ietf-pce-pcep-flowspec

Dear authors,

Thank for addressing the comments received during WG LC and RtgDir
reviews. Technically, the I-D looks almost ready.

I still have one pending question, related to section 8.7. (Priorities
and Overlapping Flow Specifications). I understand this section as
"priorities within PCEP-installed flow specs follow the same ordering
rules as BGP-installed flow specs, i.e. [RFC5575]". Let us now look at a
device supporting both protocols to install flow specs:
- Is there an implicit scope associated to each set of flow specs making
them mutually exclusive?
- If both sets can overlap, can we assume that priority rules do not
care about the protocol used to install the flow specs?
Adding a couple of sentences may be enough to clarify that.

Please find below a few additional nits.
--
1. Introduction
---
- The abstract uses "traffic engineered networks", the intro "traffic
engineering networks". I do not have any strong preference, but
consistency would be welcome. (By the way, no hyphen in
"traffic-engineered"?)
- s/to Generalized MPLS (GMPLS) networks/to Generalized MPLS
(GMPLS)-controlled networks/
- s/about the the LSPs/about the LSPs/

- OLD:
   The data flows
   intended for a tunnel can be described using Flow Specification
   Components, and when PCEP is in use for tunnel initiation it makes
   sense for that same protocol to be used to distribute the Flow
   Specification Components that describe what data is to flow on those
   tunnels.
  NEW:
   The data flows
   intended for a tunnel can be described using Flow Specification
   Components; when PCEP is in use for tunnel initiation, it makes
   sense for that same protocol to be used to distribute the Flow
   Specification Components that describe what data is to flow on those
   tunnels.
--
3.2. Elements of Procedure
---
- s/in each case including whether/in each case. This includes whether/
--
6. Flow Filter TLV
---
OLD:
   Only one Flow Filter TLV can be
   present and represents the complete definition of a Flow
   Specification for traffic to be placed on the tunnel indicated by the
   PCEP message in which the PCEP Flow Spec Object is carried.
NEW:
   Only one Flow Filter TLV can be
   present and represents the complete definition of a Flow
   Specification for traffic to be placed on a tunnel; this tunnel is
   indicated by the PCEP message in which the PCEP Flow Spec Object
   is carried.
--
7. Flow Specification TLVs
---
[Page 14]
"Two bit flags (S and G) are defined.  They have the common meanings for
wildcarding in multicast."
-> At least a reference would be appreciated to teach about what
"common" refers to.

[Page 15]
  "if a Multicast Flow
   Specification TLV is received with S bit = 0 and G bit = 1 the
   receiver SHOULD respond"
-> Is there a reason why it is not a MUST?
--
13. Manageability Considerations
---
- s/view the the Flow Specifications/view the Flow Specifications/
- s/implementations MUST support indicating/implementations MUST
indicate/  [Guessing it was wrongly fixed in -06.]
--


Thanks,

Julien



_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

___
Pce 

Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-00.txt

[Adrian Farrel]

Hard not to be sarcastic, but I'll try.

Yes, I still support this document I wrote at the request of the chairs and
with the support of the WG to fix an error in a WG RFC and which has already
completed WG last call but now has a new name and another two weeks delay
before it can go to IETF last call.

If anyone asks why the IETF takes so long to produce RFCs, we might use this
document as a good example. I know, not the chairs' fault.

Best,
Adrian
-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: 08 November 2019 16:07
To: pce@ietf.org
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-00.txt

Hi WG,

As instructed by our AD, I-D has been posted with the file name change
- draft-ietf-pce-stateful-flags-00.

https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/

The chairs request the WG to reaffirm that the WG supports the
publication of the I-D by Friday 22nd Nov. We request you to be vocal
to enable us to judge consensus (and justify it).

Thanks!
Dhruv & Julien


On Thu, Nov 7, 2019 at 9:30 PM  wrote:
>
>
> 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   : Updated Rules for Processing Stateful PCE
Request Parameters Flags
>     Author  : Adrian Farrel
> Filename: draft-ietf-pce-stateful-flags-00.txt
> Pages   : 6
> Date: 2019-11-07
>
> Abstract:
>Extensions to the Path Computation Element Communication Protocol
>(PCEP) to support stateful Path Computation Elements (PCEs) are
>defined in RFC 8231.  One of the extensions is the Stateful PCE
>Request Parameters (SRP) object.  That object includes a Flags field
>that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
>for tracking assigned flags.  However, RFC 8231 does not explain how
>an implementation should set unassigned flags in transmitted
>messages, nor how an implementation should process unassigned,
>unknown, or unsupported flags in received messages.
>
>This document updates RFC 8231 by defining the correct behaviors.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-pce-stateful-flags-00
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-flags-00
>
>
> 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] Rtgdir last call review of draft-farrel-pce-stateful-flags-02

[Adrian Farrel]

Hello Deborah,

I wonder whether something has changed in the IETF process that I'm not aware 
of. That is possible.

> Adrian, I'm also a bit confused on the intention of the draft. While
> the tools are not error checking a draft with intended status of PS
> against a title indicating an individual submission, the title does 
> indicate the source of the document. With the current title, this
> document is an individual submission to the IETF stream. If this
> is a product of the working group, the title needs to reflect it. As
> it is requested to be "PS", it does need to reflect the associated
> working group.

The document has not been adopted by the working group, but it has been last 
called by the working group.
While the WG chairs are allowed to adopt a document off their own bat, they 
prefer to use an adoption poll whenever they do an adoption. That can add a two 
week poll, but there is also a queue in many working groups, so a document can 
end up dying of boredom.

If you can point me at the process rule that says that document emerging from a 
WG must have a specific name format then I guess we can change the document 
(and also write a draft to change the rule ;-) 

If you can point me at the rule that says Standards Track documents must be the 
product of a working group (not, for example, AD sponsored) I'll be surprised.

> While it is a bit surprising this was not raised in WG Last Call (hopefully
> folks have read the document), 

The chairs did call out the direct progression of this draft to WG last call in 
a mail to the list prior to starting the last call.

> it will definitely be flagged with the other
> Area Directorate reviews and IESG review.

I shall delight in helping them to understand the processes of which they are 
guardians :-)

> While the working group cycle was very short, the resulting publication
> cycle will be very long.

Oh, I have long ago given up on doing things to simply follow the path of least 
resistance. The IESG needs to recognise that they are supposed to facilitate 
publication (of good documents) not get in the way! If the resulting cycle is 
long we will at least know why.

> As the WG LC was based on PS status, I would conclude the group is 
> ok with PS. Either you can change the title to reflect a product of the
> pce working group or change the status to Informational and I'll take
> it forward as an individual submission. If you change the title to a
> product of the pce working group, I'll follow up with a note to the list
> to double check if anyone has any concerns. And then we can move
> ahead.

I do hope that we will not get hung up on any misunderstandings of process. As 
you observe, the publication cycle for drafts has become long. Many times they 
leave the WG and don't hit the RFC Editor Queue for four months.. I see the 
process including:
- Shepherd review
- Directorate review
- AD review
- IETF last call
- Late directorate reviews
- IESG review
Each of these has three steps:
- Queued for action
- Review period
- Update period

Even when the authors are immediately responsive to any review comments raised, 
this can drag on a long time. If each review is scheduled for two weeks, that's 
12 weeks burned. If the "silent" time to queue for action is also a week or 
two, you can quickly see why the tail of our process has become a burden. 
Suddenly the RFC Editor's 8 week queue seems short!

> Looking forward to your choice

My choice as author is to follow IETF process.
You've had a publication request, from the PCE working group to publish an 
Internet-Draft on the Standards Track.
I hope we can proceed with that without further delay.

Thanks,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] FW: New Version Notification for draft-ietf-pce-pcep-flowspec-06.txt

[Adrian Farrel]

Hi,

I think I caught all of the WG last call comments: viz. Acee's RTGDir review.

Best,
Adrian
--
In Singapore? Need something to read?
Don't waste your time with Internet-Drafts.
Read fairy tales instead.
Fairy stories for adults of all ages
• Tales from the Wood
• More Tales from the Wood
• Tales from Beyond the Wood
• Tales from the Castle
Get them on line https://www.feedaread.com/profiles/8604/
Or buy a signed copy from me by post
*** Stop me in the corridor at IETF-106 to get a copy ***



-Original Message-
From: internet-dra...@ietf.org  
Sent: 02 November 2019 23:25
To: Adrian Farrel ; Dhruv Dhody ; 
Zhenbin Li 
Subject: New Version Notification for draft-ietf-pce-pcep-flowspec-06.txt


A new version of I-D, draft-ietf-pce-pcep-flowspec-06.txt
has been successfully submitted by Adrian Farrel and posted to the
IETF repository.

Name:   draft-ietf-pce-pcep-flowspec
Revision:   06
Title:  PCEP Extension for Flow Specification
Document date:  2019-11-02
Group:  pce
Pages:  32
URL:
https://www.ietf.org/internet-drafts/draft-ietf-pce-pcep-flowspec-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/
Htmlized:   https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-06
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-06

Abstract:
   The Path Computation Element (PCE) is a functional component capable
   of selecting paths through a traffic engineered network.  These paths
   may be supplied in response to requests for computation, or may be
   unsolicited instructions issued by the PCE to network elements.  Both
   approaches use the PCE Communication Protocol (PCEP) to convey the
   details of the computed path.

   Traffic flows may be categorized and described using "Flow
   Specifications".  RFC 5575 defines the Flow Specification and
   describes how Flow Specification Components are used to describe
   traffic flows.  RFC 5575 also defines how Flow Specifications may be
   distributed in BGP to allow specific traffic flows to be associated
   with routes.

   This document specifies a set of extensions to PCEP to support
   dissemination of Flow Specifications.  This allows a PCE to indicate
   what traffic should be placed on each path that it is aware of.


  


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.

The IETF Secretariat

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Rtgdir last call review of draft-farrel-pce-stateful-flags-02

[Adrian Farrel]

Hi Mike,

Thanks for taking the time to read this.

> Great job on the easy to understand draft. I probably
> don't want to know the history of why this is an individual
> draft but I am curious. I'll ask Adrian over a drink sometime.

Not rejecting the idea of a drink, but just sharing with the wider community...

It is fun to exercise the full range of IETF process options from time to time.
The chairs did not think it was necessary to delay the draft by putting it into 
the adoption queue and going through all that piece of process when all that 
was needed was a last call.

> Nits for your consideration:
>
> Abstract:
> "Extensions to the Path Computation Element communications Protocol"
> -capitalize "communications" as you do in the Introduction.

Oh look! Officially there is no 's' on Communication. (Also right in the 
Introduction)
Thanks.

> 4. Compatibility Considerations
> ..
> "It should be noted that common behavior for flags fields is as described by
> the updated text presented in Section 3 so many implementations, lacking
> guidance from RFC 8231, will still have implemented a consistent and
> future-proof approach."
>
> For better readability change to:
> "It should be noted that common behavior for flags fields is as described by
> the updated text presented in Section 3. Therefore, many implementations,
> lacking guidance from RFC 8231, will still have implemented a consistent and
> future-proof approach." Or something similar.
>
> Consider removing all instances of the word "so".

So, you think 'so' is so so-so?

Yup. Caught a couple of equally ambiguous cases.

Best,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] RtgDir: Early Review of draft-ietf-pce-pcep-flowspec-05.txt - "PCEP Extension for Flow Specification"

[Adrian Farrel]

Hi Acee,

Thanks for the review and the kind words.
I believe this document is in WG last call at the moment, so this is not quite 
so early as an “Early Review” might normally be.

>  I have a question and a few suggestions:
>
>1. For the multicast flow filter TLVs, is there some reason why
>   the S-bit and G-bit respectively indicate that the fields are
>   NOT used? In most protocol encodings, a Set bit indicates that
>   a field is used and a Clear bit indicates that it is not used.
>   Also, all zeros has also been used a wildcard specification
>   but I guess you preferred something explicit.

No particular reason for the bit settings that I can remember. It makes the 
bits fit nicely with the "Reserved" field, but that is not a very telling 
point. We could change this if there is a good reason to do so.

IIRC the setting of all zeros has a specific meaning in this case and so a 
different wildcard value was needed.

>2. For IGPs, we always hyphenate Bit definitions. However, in this
>   specification, the Bit definitions are not hyphenated other
>   than in the IANA section. Being the LSR chair, I'd prefer
>   consistency with the IGP specifications.

I just checked back with RFC 5440 (the PCEP base specification) and there 
hyphenation is not used.

I have no strong opinion and will let the PCE chairs tell me what to do.

>3. In most IETF specifications, "headend" is a single compound
>   word. 

Oooh, I hate that 
Can we leave it to the RPC to fix as a matter of house style?

>4. In section 9, could you indicate that the only change is adding
>   the ? This seems to be the case but it would be
>   good to state it explicitly.

In my working copy.

>   5. I have attached an RFCDIFF of suggested editorial changes.

That was unusually thorough of you. Thanks! All of those nits were spot on and 
are in my working copy (modulo one s/am/an/).

Best,
Adrian

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Hi Julien,

Probably no surprise: as an author, I support this document going forward.

I just did a quick re-read of the draft and don't see any issues beyond the
fact that Section 11 refers to the -04 version.

Thanks,
Adrian

-Original Message-
From: Pce  On Behalf Of julien.meu...@orange.com
Sent: 14 October 2019 13:55
To: pce@ietf.org
Subject: [Pce] WG Last Call of draft-ietf-pce-pcep-flowspec

Hi all,

In our WGLC queue, draft-ietf-pce-pcep-flowspec has been stable for a
while. This message starts a 2-week WG last call on this I-D. Please
review the document and share your feedback using the PCE mailing list
by Monday October, 28.

You will note that the I-D includes an implementation section. If you
have an implementation, you may also contact the chairs privately.

Thanks,

Dhruv & Julien



_

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

___
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] IPR Poll on draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Hi Hari,

 

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

 

Thanks,

Adrian

 

From: Hariharan Ananthakrishnan  
Sent: 14 October 2019 18:00
To: Dhruv Dhody ; Farrel Adrian ; 
lizhen...@huawei.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-ietf-pce-pcep-flowspec

 

Hi Authors,
 
In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
 
Please respond (copying the mailing list) to say one of:
 
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
 
I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.
 
I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.
 
Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] Review of draft-zhang-pce-resource-sharing-10

[Adrian Farrel]

Hi,

Now I'm no longer one of the PCE chairs, I have a little more time for
reviewing works in progress.

This document popped up as a candidate because it has been around for a
long time and is now on its eleventh version. (It's also not too long,
which makes it attractive.)

I hope these comments are useful.

Best,
Adrian

===

Title

OLD
Extensions to Path Computation Element Protocol (PCEP) to Support
Resource Sharing-based Path Computation
NEW
  Extensions to the Path Computation Element Protocol (PCEP) to Support
Resource Sharing-based Path Computation
END

---

Boilerplate

You should reorganise the header sections to match with the current
best practice. That it:

Title
File name
Abstract
Status of this memo
Copyright
Table of contents

The requirements language should be moved to Section 1.1 or Section 2
where you should use the latest form of words...

   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 also gives you an additional Normative reference for 8174.

---

Optional plurals. In English you do not need say things like "use common
piece(s)". You can use the unequivocal plural and it is understood that
it is optional. So you should say "use common pieces".

Please s/(s)/s/ throughout the document.

---

In the Abstract you have a use of "PCEP" before the expansion of the
term.

---

The last words of the Abstract are:
   which is a special case in the association path computation.

This is slightly confusing because you haven't established what
"association path computation" is. I suggest you might change the
Abstract to read something like:

   Resource sharing in a network means two or more Label Switched Paths
   (LSPs) use common piece(s) of resource along their paths. This can
   help save network resource and is useful in scenarios such as LSP
   recovery or when two LSPs do not need to be active at the same time.
   A Path Computation Element (PCE) is responsible for path computation
   with such requirement.

   Existing extensions to the Path Computation Element Protocol (PCEP)
   allow one path computation request for an LSP to be associated with
   other (existing) LSPs through the use of the PCEP Association Object.

   The resource-sharing-based path computation
   with better efficiency can be achieved together with the association
   object in PCEP.

   This document extends PCEP to support resource sharing-based path
   computation as another use of the Association Object.

---

Section 1

OLD
   provides an alternative way for providing
NEW
   is a way to provide
END

Since "passive" and "active" have not yet been mentioned...
OLD
   Unless specified, this
   document assumes a PCE mentioned is a stateful PCE (either passive
   or active).
NEW
   Unless specified, this
   document assumes a PCE mentioned is a stateful PCE.
END

---

Global search and replace "a LSP" to "an LSP"

---

In Section 1 you have:

   Furthermore, if there is resource sharing between new LSP and
   existing LSP, the two LSPs cannot exist simultaneously, the new LSP
   will replace the existing LSP(s).

I know why you say this, because (obviously) you can't double-book
resources. But I think that you can relax the requirement here especially
for the case of protection and restoration. All you actually need is
that both LSPs can't be active (i.e., carry traffic) at the same time.

Actually, a little while later you talk about make-before-break where
(obviously) both LSPs can exist at the same time.

Of course, this is not a concern for the PCE, just for the LSP head-end,
so perhaps it isn't a requirement to state here. Maybe just state it as
an observation in this paragraph.

But you will need to clean up the hole text, I think. For example, a
little later you have:
   However, these objects
   are used to describe the relationship with two simultaneous LSPs,
   instead of a new one and an old one, which is different with the
   object proposed in this draft.
and you say that like only one of the two LSPs will exist at any
time, but (again) that is not consistent with MBB or other forms of
protection. So this could be clarified to mean "used to carry traffic".

---

In Section 1

   but also the same slice of bandwidth in TDM networks.

While true, this appears to be limiting to TDM where, I think, you
intend the document to apply to any technology. So how about:

   but also the same slice of bandwidth in the network.

---

Throughout the document, where you have written "this draft" say "this
document" to future-proof yourself against becoming an RFC.

Similarly s/proposed/defined/

---

Section 1

   As mentioned in [RFC8231], the PLSP-ID is unique during a PCEP
   session between PCC and PCE. 

Re: [Pce] I-D Action: draft-farrel-pce-stateful-flags-02.txt

[Adrian Farrel]

New revision to ask IANA to add this document as a reference in the
appropriate registry (as suggested by Hari).

-Original Message-
From: Pce  On Behalf Of internet-dra...@ietf.org
Sent: 23 September 2019 11:42
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-farrel-pce-stateful-flags-02.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   : Updated Rules for Processing Stateful PCE Request
Parameters Flags
Author  : Adrian Farrel
Filename: draft-farrel-pce-stateful-flags-02.txt
Pages   : 6
Date: 2019-09-23

Abstract:
   Extensions to the Path Computation Element communications Protocol
   (PCEP) to support stateful Path Computation Elements (PCEs) are
   defined in RFC 8231.  One of the extensions is the Stateful PCE
   Request Parameters (SRP) object.  That object includes a Flags field
   that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
   for tracking assigned flags.  However, RFC 8231 does not explain how
   an implementation should set unassigned flags in transmitted
   messages, nor how an implementation should process unassigned,
   unknown, or unsupported flags in received messages.

   This document updates RFC 8231 by defining the correct behaviors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-farrel-pce-stateful-flags-02
https://datatracker.ietf.org/doc/html/draft-farrel-pce-stateful-flags-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-farrel-pce-stateful-flags-02


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

Re: [Pce] Shepherd Review of draft-farrel-pce-stateful-flags-01

[Adrian Farrel]

Hi,

I’m willing to be guided here.

I don’t think the new draft makes any changes to how a code point seen in in 
the wild should be interpreted.
And the “updates” relationship will be in place.

But if people think it is valuable we could have…

IANA maintains a registry called the “Path Computation Element Protocol (PCEP) 
Numbers” registry with a subregistry called " SRP Object Flag Field". IANA is 
requested to update the Reference in that subregistry to include a reference to 
this document in addition to [RFC8281].

Best,
Adrian

> This document is well written and clear. Thanks for the update. Please find 
> below
> my comments on draft-farrel-pce-stateful-flags-01.
>
> OLD:
> 8. IANA Considerations
> This document makes no requests for IANA action
>
> NEW:
> The current IANA for this object has reference to "RFC8281" 
> (https://www.iana.org/
> assignments/pcep/pcep.xhtml#srp-object-flag-field) Dont we want that refer to 
> this
> new draft since we have updated the text ?

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**

[Adrian Farrel]

Yes, that's a reasonable request.

Should send a Notification.
If congested or would only serve to increase overload, May choose to not send a 
Notification.
Not sending a Notification could result in foo
A PCC experiencing foo should to bar.
Note that when a PCE serves very many PCCs, congestion may arise without any 
one PCC becoming aware of multiple unserved messages, in which case something.

Adrian

-Original Message-
From: Barry Leiba  
Sent: 16 September 2019 17:00
To: Dhruv Dhody 
Cc: pce@ietf.org; The IESG ; pce-chairs ; 
Farrel Adrian ; 
draft-ietf-pce-stateful-pce-auto-bandwi...@ietf.org
Subject: Re: **Barry Leiba's DISCUSS on 
draft-ietf-pce-stateful-pce-auto-bandwidth**

Thanks for the reply, Dhruv.

To be clear, I am NOT suggesting changing it to MUST (though that
could be a perfectly good outcome of the discussion).  I am suggesting
that if it remains as SHOULD, there has to be some explanation of what
the constraints are and what interoperability or security issues could
arise if an implementation doesn't do it that way.

Barry

On Mon, Sep 16, 2019 at 4:21 AM Dhruv Dhody  wrote:
>
> Hi again!
>
> On Mon, Sep 16, 2019 at 4:48 PM Dhruv Dhody  wrote:
> >
> > Hi Barry, WG,
> >
> > I saw the DISCUSS [1] in the datatracker but for some reason the email
> > never landed in my inbox or the list [2]. I am manually posting it
> > here -
> >
> > 
> >
> > Discuss (2019-09-16)
> >
> > Thanks for another clear document.  There are some "SHOULD" key words
> > in one section that I would like to discuss, and that I think we ought
> > to be able to resolve without much difficulty:
> >
> > — Section 5.7 —
> >
> > There are various “SHOULD”s in this section, and I have the same
> > comment about all of them: BCP 14 says, about “SHOULD”, that “there
> > may exist valid reasons in particular circumstances to ignore a
> > particular item, but the full implications must be understood and
> > carefully weighed before choosing a different course.”  I see no
> > guidance here to help the reader understand what such circumstances
> > and implications are, so I can’t see how an implementer can evaluate
> > the situation.  Can you provide any help here?
> >
> > 
> >
>
> I checked the base RFC for PCEP - RFC 5440 where notifications are
> first defined. They do not use MUST for sending notification in the
> PCE overload case [1].
>
> Leaving that aside, in case of auto-bandwidth feature, this
> notification is important for scaling. I am inclined to change it to
> MUST as suggested.
>
> Co-authors, WG, please speak up if you disagree!!
>
> I have incorporated all other comments in the working copy.
>
> Diff: 
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-stateful-pce-auto-bandwidth-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt
>
> Thanks!
> Dhruv
>
> [1] https://tools.ietf.org/html/rfc5440#section-7.14
>
> > Comment (2019-09-16)
> >
> > Again, these are purely editorial comments, which need no detailed
> > response; please just consider them.
> >
> > — Section 1 —
> >
> >Over time, based on the varying traffic pattern, an LSP established
> >with a certain bandwidth may require to adjust the bandwidth reserved
> >in the network dynamically.
> >
> > “may require adjustment of the bandwidth”
> >
> >This is similar to
> >the Passive stateful PCE model, while the Passive stateful PCE uses
> >path request/reply mechanism, the Active stateful PCE uses
> >report/update mechanism.
> >
> > NEW
> >This is similar to
> >the Passive stateful PCE model: while the Passive stateful PCE uses
> >a path request/reply mechanism, the Active stateful PCE uses a
> >report/update mechanism.
> > END
> >
> >This document defines the PCEP extensions needed to support Auto-
> >Bandwidth feature in a Active stateful PCE model
> >
> > NEW
> >This document defines the PCEP extensions needed to support an Auto-
> >Bandwidth feature in an Active stateful PCE model
> > END
> >
> > — Section 2.3 —
> >
> >   This value indicates how many times
> >   consecutively, the percentage or absolute difference
> >
> > Add a comma after “times”.
> >
> > — Section 3 —
> >
> >The PCEP speaker supporting this document must have a mechanism
> >
> > “A PCEP speaker”.
> >
> >o  It is required to identify and inform the PCC, which LSPs are
> >   enabled with Auto-Bandwidth feature.  Not all LSPs in some
> >   deployments would like their bandwidth to be dependent on the
> >   real-time bandwidth usage but be constant as set by the operator.
> >
> > NEW
> >o  It is necessary to identify and inform the PCC which LSPs have
> >   the Auto-Bandwidth feature enabled.  In some deployments, not
> >   all LSPs would like their bandwidth to be dependent on the
> >   real-time bandwidth usage, but would rather be constant as set
> >   by the operator.
> > END
> >
> > — 

Re: [Pce] **Barry Leiba's DISCUSS on draft-ietf-pce-stateful-pce-auto-bandwidth**

[Adrian Farrel]

Top post, historic view.

IIRC the reason for not requiring a Notification in the case of overload was 
that the process of sending a Notification might contribute to the overload. 
And, furthermore, that there might be an attack that leverages the need to send 
a Notification to perpetuate the overload.

I take no position on this: just reporting what is in my memory.

Best,
Adrian

-Original Message-
From: Dhruv Dhody  
Sent: 16 September 2019 12:21
To: Barry Leiba ; pce@ietf.org
Cc: The IESG ; pce-chairs ; Farrel Adrian 
; draft-ietf-pce-stateful-pce-auto-bandwi...@ietf.org
Subject: Re: **Barry Leiba's DISCUSS on 
draft-ietf-pce-stateful-pce-auto-bandwidth**

Hi again!

On Mon, Sep 16, 2019 at 4:48 PM Dhruv Dhody  wrote:
>
> Hi Barry, WG,
>
> I saw the DISCUSS [1] in the datatracker but for some reason the email
> never landed in my inbox or the list [2]. I am manually posting it
> here -
>
> 
>
> Discuss (2019-09-16)
>
> Thanks for another clear document.  There are some "SHOULD" key words
> in one section that I would like to discuss, and that I think we ought
> to be able to resolve without much difficulty:
>
> — Section 5.7 —
>
> There are various “SHOULD”s in this section, and I have the same
> comment about all of them: BCP 14 says, about “SHOULD”, that “there
> may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and
> carefully weighed before choosing a different course.”  I see no
> guidance here to help the reader understand what such circumstances
> and implications are, so I can’t see how an implementer can evaluate
> the situation.  Can you provide any help here?
>
> 
>

I checked the base RFC for PCEP - RFC 5440 where notifications are
first defined. They do not use MUST for sending notification in the
PCE overload case [1].

Leaving that aside, in case of auto-bandwidth feature, this
notification is important for scaling. I am inclined to change it to
MUST as suggested.

Co-authors, WG, please speak up if you disagree!!

I have incorporated all other comments in the working copy.

Diff: 
https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=draft-ietf-pce-stateful-pce-auto-bandwidth-11=https://raw.githubusercontent.com/dhruvdhody/ietf/master/draft-ietf-pce-stateful-pce-auto-bandwidth-12.txt

Thanks!
Dhruv

[1] https://tools.ietf.org/html/rfc5440#section-7.14

> Comment (2019-09-16)
>
> Again, these are purely editorial comments, which need no detailed
> response; please just consider them.
>
> — Section 1 —
>
>Over time, based on the varying traffic pattern, an LSP established
>with a certain bandwidth may require to adjust the bandwidth reserved
>in the network dynamically.
>
> “may require adjustment of the bandwidth”
>
>This is similar to
>the Passive stateful PCE model, while the Passive stateful PCE uses
>path request/reply mechanism, the Active stateful PCE uses
>report/update mechanism.
>
> NEW
>This is similar to
>the Passive stateful PCE model: while the Passive stateful PCE uses
>a path request/reply mechanism, the Active stateful PCE uses a
>report/update mechanism.
> END
>
>This document defines the PCEP extensions needed to support Auto-
>Bandwidth feature in a Active stateful PCE model
>
> NEW
>This document defines the PCEP extensions needed to support an Auto-
>Bandwidth feature in an Active stateful PCE model
> END
>
> — Section 2.3 —
>
>   This value indicates how many times
>   consecutively, the percentage or absolute difference
>
> Add a comma after “times”.
>
> — Section 3 —
>
>The PCEP speaker supporting this document must have a mechanism
>
> “A PCEP speaker”.
>
>o  It is required to identify and inform the PCC, which LSPs are
>   enabled with Auto-Bandwidth feature.  Not all LSPs in some
>   deployments would like their bandwidth to be dependent on the
>   real-time bandwidth usage but be constant as set by the operator.
>
> NEW
>o  It is necessary to identify and inform the PCC which LSPs have
>   the Auto-Bandwidth feature enabled.  In some deployments, not
>   all LSPs would like their bandwidth to be dependent on the
>   real-time bandwidth usage, but would rather be constant as set
>   by the operator.
> END
>
> — Section 4.1 —
>
>The initial LSP bandwidth can be set to an arbitrary value (including
>zero), in practice, it can be operator expected value based on design
>and planning.
>
> NEW
>The initial LSP bandwidth can be set to an arbitrary value (including
>zero).  In practice, it can be set to an expected value based on design
>and planning.
> END
>
> — Section 4.2 —
>
>When the Auto-Bandwidth feature is enabled, the measured traffic rate
>is periodically sampled at each Sample-Interval (which can be
>configured by an operator and the default value as 5 minutes) by the
>PCC, when the PCC is the head-end node of the 

Re: [Pce] IPR Poll on draft-farrel-pce-stateful-flags-01

[Adrian Farrel]

Hi Hari,

 

I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.

 

Thanks,

Adrian

 

From: Hariharan Ananthakrishnan  
Sent: 06 September 2019 15:41
To: Farrel Adrian 
Cc: pce@ietf.org
Subject: IPR Poll on draft-farrel-pce-stateful-flags-01

 

Hi Authors,
 
In preparation for Working Group last call on this draft, I'd like all
authors and contributors to confirm on the list that they are in compliance
with IETF IPR rules.
 
Please respond (copying the mailing list) to say one of:
 
I am not aware of any IPR applicable to this draft that should be disclosed
in accordance with IETF IPR rules.
 
I am aware of IPR applicable to this draft, and it has already been
disclosed to the IETF.
 
I am aware of IPR applicable to this draft, but that has not yet been
disclosed to the IETF. I will work to ensure that it will be disclosed in a
timely manner.
 
Thanks,
- Hari
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] WG LC for draft-farrel-pce-stateful-flags-01

[Adrian Farrel]

Dhruv, WG,

You'll be unsurprised to know I think this document is ready to proceed.

I've even read it.

Adrian

-Original Message-
From: Dhruv Dhody  
Sent: 30 August 2019 19:14
To: pce@ietf.org
Cc: pce-chairs 
Subject: WG LC for draft-farrel-pce-stateful-flags-01

Hi WG,

This email starts a 'working group last call' for
draft-farrel-pce-stateful-flags-01 [1]. This I-D is focused and has an
uncontroversial fix to RFC 8231, we are moving it directly to WGLC. See [2]
for context.

Please indicate your support or concern for this draft.

If you are opposed to the progression of the draft, please articulate your
concern.

If you support, please indicate that you have read the latest version and
it is ready for publication.

As always, review comments and nits are most welcome.

The WG LC will end on 16th September 2019.

Thanks,
PCE Chairs

[1] https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/
[2] https://mailarchive.ietf.org/arch/msg/pce/tTkJKO34xTD0CY48IJCk5FjmiJ4

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Secdir last call review of draft-ietf-pce-stateful-hpce-11

[Adrian Farrel]

You had me at the mention of beer.

Actually, that would be a useful conversation both in a PCE context and in a 
wider SDN context. (Always said that the SDN architecture was missing a bit of 
security work).

I'd also love us to have some clarity about TCP-AO. It's like we were all told 
we must use TCP-AO in our protocol specifications as the silver bullet, and now 
the shiny outer layer has tarnished a bit. But that is worthy of a separate 
thread.

Best,
Adrian

-Original Message-
From: Stephen Farrell via Datatracker  
Sent: 27 August 2019 23:32
To: sec...@ietf.org
Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-stateful-hpce@ietf.org
Subject: Secdir last call review of draft-ietf-pce-stateful-hpce-11

Reviewer: Stephen Farrell
Review result: Has Nits


Hiya,

This draft doesn't define new protocol but rather describes a way to use 
existing 
PCE stuff in what I guess is a new way. 

The nit I see is the usual, presumably fictional, reference to TCP-AO.  I mean, 
if
nobody actually does that, why bother? Esp. if you have a TLS option that's (I
hope) less fictional. (Is TLS less fictional for PCEP btw?) OTOH, I guess that
nearly everyone now knows that referring to TCP-AO is just a figleaf to try keep
security nerds happy, so maybe it's ok that we all suspend disbelief;-( 

Other than that, I did have two questions that occurred to me, but that are by 
no means a reason to hold up this draft - if answers required some action, it'd
almost certainly not be something that'd be fixed here. But I'm still curious:-)

1. Has anyone spent any significant amount of time/effort attempting to 
attack an H-PCE network  as a PCEP speaker? (And written that up:-) It 
looks to me like there're enough moving parts here that any real stateful 
hierarchical PCE  network could be fairly likely to have interestingly
exploitable problems in the face of such an attacker.

2. I see a reference to SPEAKER-IDENTITY-TLV. I wondered if the 
ability to e.g. use different SubjectAltNames in x.509 certificates
might create the potential for some kind of deliberate or accidental
loops to be created somewhere. 

Again, there's no reason to hold this up to try answer (or even to
understand) those questions. I'd be happy to chat over a beer with 
someone  at IETF106 about 'em as that might be easier than a bunch 
of mail. 

Cheers,
S.


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] draft-leedhody-pce-vn-association adopted by PCE WG

[Adrian Farrel]

Thanks to all who responded to this poll.

The result was not overwhelming, but the chairs think that there is just
about enough support to move forward.

Authors, please post the draft as draft-ietf-pce-vn-association-00 with no
changes except for the name, and be sure to set the "replaces" information.

Thanks,
Adrian
pp PCE Chairs

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] [Lsr] Solicit feedback on draft-ietf-lsr-pce-discovery-security-support-01

[Adrian Farrel]

Hi Qin,

I didn't see any response to this email, so I thought I should chip in with
some (old, old, old) memories and context.

tl;dr I am generally supportive of this work, but I think a little
fine-tuning is needed.

If I recall correctly, the situation when 5088 and 5089 were produced was
that there was mission creep. The initial idea was to discover the existence
of PCE-capable routers in the network, but it was quickly realised a
specific address might be preferable for reaching the PCE, so there was need
for the PCE Discovery TLV to contain an address, and it was decided to
encode it as a TLV. Then the rot set in and we determined there were some
other useful pieces of information to encode. And then we thought that it
would be helpful to have an array of capability bits.

At this point the IGP working groups started to get worried. As Les and Acee
noted, the concern was that we would be carrying "large" amounts of data in
the IGP that was not directly related to the primary purpose of the IGP
(packet routing) or even the secondary purpose (TE). We had a bit of a fight
on our hands at this stage because the PCE implementers had already built
stuff, and the IGP "purists" were digging in. So we agreed to stabilise with
"this far and no further" and the lines in 5088/9 that say:
   No additional sub-TLVs will be added to the PCED TLV in the future.
   If a future application requires the advertisement of additional PCE
   information in OSPF, this will not be carried in the Router
   Information LSA.
The idea was that it would be OK to define new capability bits, but not to
add more TLVs.

I don't recall being delighted by this outcome at the time, but it certainly
allowed us to move forward. It seemed to me that PCEs were not the only
devices exchanging non-routing information in the IGP, and if there was a
concern about volume of data or convergence time, then this seemed a bigger
problem that needed a more general resolution. On the other hand, IETF
consensus is what it is.

The approach that others have taken in this situation is to add flags as
needed, but to put the additional discovery information in the PCEP Open
message. Thus, at a high level, a PCC can decide whether there is any point
in opening a PCEP session with a PCE, but may have to try the session to
find out exactly what options are available and might, at that time,
discover that the PCE is not suitable.

Looking at your draft, the addition of the two bit flags is easy and
uncontroversial. 

It is the addition of the Key-ID and Key-Chain-Name sub-TLVs that cause you
to want to change the RFCs. And I think you have a special case here because
using the TCP security mechanism, the PCEP Open message would come too late
to exchange the relevant information. That is, you need the security
information to set up the secure TCP session before the PCEP Open messages
can be exchanged.

This point could usefully be made more clear in the document. That is, why
you cannot use the alternate mechanism for exchanging PCE characteristics
and capabilities. After that has been done, I think that it would be
reasonable to allow the approach you are describing subject to LSR WG
consensus. (The alternative, which is perfectly acceptable within the
architecture and within some operational environments, is configuration. But
configuration doesn't work in the larger use cases, and another mechanism
would constitute a third way of exchanging PCE information, and that sounds
ridiculous.)

However, while I think that you should be allowed through the doorway, I
don't think you should leave the door open behind you. That means that you
should update 5088/9 to allow your new sub-TLVs, but you should leave in
place the ruling that no more new sub-TLVs are allowed. I *think* that is
what you're trying to do, but I don't think your Section 4 is the right way
to do that - it is not necessary to make edits to the old documents to make
this change, you can simply say... 
Section 4 of [RFC5088] states that no new sub-TLVs will be added to the PCED
TLV, and no new PCE information will be carried in the Router Information
LSA. This document updates RFC 5088 by allowing the two new sub-TLVs defined
in this document to be carried in the PCED TLV of the for use in the Router
Information LSA.
Section 4 of [RFC5089] states that no new sub-TLVs will be added to the PCED
TLV, and no new PCE information will be carried in the Router CAPABLITY TLV.
This document updates RFC 5089 by allowing the two new sub-TLVs defined in
this document to be carried in the PCED TLV of the for use in the Router
CAPABILITY TLV.

Along the way, we're also going to need to do some work on Section 7. The
whole point of your draft is to exchange information about security
features, and that makes it highly sensitive if it can be attacked. For
example, just toggling the two new capability bits can be a downgrade
attack. And tweaking the content of the new TLVs would, I imagine, enable
man-in-the-middle 

[Pce] FW: I-D Action: draft-farrel-pce-stateful-flags-01.txt

[Adrian Farrel]

Hi WG.

Made some edits to clean it up:
- typos
- note that probably nothing has changed for existing implementations
- implementation considerations section (that doesn't say much)

Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 16 August 2019 13:23
To: i-d-annou...@ietf.org
Subject: I-D Action: draft-farrel-pce-stateful-flags-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


Title   : Updated Rules for Processing Stateful PCE Request
Parameters Flags
Author  : Adrian Farrel
Filename: draft-farrel-pce-stateful-flags-01.txt
Pages   : 6
Date: 2019-08-16

Abstract:
   Extensions to the Path Computation Element communications Protocol
   (PCEP) to support stateful Path Computation Elements (PCEs) are
   defined in RFC 8231.  One of the extensions is the Stateful PCE
   Request Parameters (SRP) object.  That object includes a Flags field
   that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
   for tracking assigned flags.  However, RFC 8231 does not explain how
   an implementation should set unassigned flags in transmitted
   messages, nor how an implementation should process unassigned,
   unknown, or unsupported flags in received messages.

   This document updates RFC 8231 by defining the correct behaviors.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-farrel-pce-stateful-flags-01
https://datatracker.ietf.org/doc/html/draft-farrel-pce-stateful-flags-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-farrel-pce-stateful-flags-01


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] I-D Action: draft-ietf-pce-pcep-flowspec-05.txt

[Adrian Farrel]

Thanks to Jeffrey, we think we finally fixed the last bit of ambiguity
around the multicast flowspec.

Best,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 15 August 2019 22:54
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: I-D Action: draft-ietf-pce-pcep-flowspec-05.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 Extension for Flow Specification
Authors : Dhruv Dhody
  Adrian Farrel
  Zhenbin Li
Filename: draft-ietf-pce-pcep-flowspec-05.txt
Pages   : 32
Date: 2019-08-15

Abstract:
   The Path Computation Element (PCE) is a functional component capable
   of selecting the paths through a traffic engineered network.  These
   paths may be supplied in response to requests for computation, or may
   be unsolicited instructions issued by the PCE to network elements.
   Both approaches use the PCE Communication Protocol (PCEP) to convey
   the details of the computed path.

   Traffic flows may be categorized and described using "Flow
   Specifications".  RFC 5575 defines the Flow Specification and
   describes how Flow Specification Components are used to describe
   traffic flows.  RFC 5575 also defines how Flow Specifications may be
   distributed in BGP to allow specific traffic flows to be associated
   with routes.

   This document specifies a set of extensions to PCEP to support
   dissemination of Flow Specifications.  This allows a PCE to indicate
   what traffic should be placed on each path that it is aware of.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-05
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-05


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association

[Adrian Farrel]

Hi PCE WG,

The adoption poll for this draft was not overwhelming. Possibly this was
because of the overlap with IETF-105 when you were all busy.

Thanks to everyone who did respond to the poll. If there are any more of you
out there who think the WG should adopt this work please speak up.
Especially happy to hear form those who have read the draft, and those who
plan to help with reviews and implementations.

Thanks,
Adrian (still trying to step down!)

-Original Message-
From: Pce  On Behalf Of Adrian Farrel
Sent: 14 July 2019 14:00
To: pce@ietf.org
Cc: draft-leedhody-pce-vn-associat...@ietf.org
Subject: [Pce] PCE WG Adoption poll for draft-leedhody-pce-vn-association

Hi WG,

He authors of draft-leedhody-pce-vn-association have been asking for
adoption and...

- the base PCEP association extensions seem to be stable and advancing
- I did an early review and the authors span a new version

So, this starts an adoption poll for the draft. Because IETF-105 is imminent
and you all have lots to do and read, we'll make this a three week poll
ending on 4th August.

Please send your comments of support or antipathy.

In either case, please indicate whether or not you have read the draft, and
if you support it, please say whether or not you propose to and even
possibly implement the draft.

Many thanks,
Adrian (for the chairs)

___
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] Update to draft-ietf-pce-pcep-flowspec

[Adrian Farrel]

Hi working group,

The updates in this version are:

3.1. Added an architectural overview as a result of conversations with
Olivier.

7. Updated the multicast TLV description to add S and G flags per discussion
with Jayant.

11. Added an implementation status section: I wish there was a more positive
message.

App A. Removed "Flow Specification TLV Types" as indicated in the text of
-03

Thanks,
Adrian

-Original Message-
From: I-D-Announce  On Behalf Of
internet-dra...@ietf.org
Sent: 07 August 2019 11:36
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: I-D Action: draft-ietf-pce-pcep-flowspec-04.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 Extension for Flow Specification
Authors : Dhruv Dhody
      Adrian Farrel
  Zhenbin Li
Filename: draft-ietf-pce-pcep-flowspec-04.txt
Pages   : 32
Date: 2019-08-07

Abstract:
   The Path Computation Element (PCE) is a functional component capable
   of selecting the paths through a traffic engineered network.  These
   paths may be supplied in response to requests for computation, or may
   be unsolicited instructions issued by the PCE to network elements.
   Both approaches use the PCE Communication Protocol (PCEP) to convey
   the details of the computed path.

   Traffic flows may be categorized and described using "Flow
   Specifications".  RFC 5575 defines the Flow Specification and
   describes how Flow Specification Components are used to describe
   traffic flows.  RFC 5575 also defines how Flow Specifications may be
   distributed in BGP to allow specific traffic flows to be associated
   with routes.

   This document specifies a set of extensions to PCEP to support
   dissemination of Flow Specifications.  This allows a PCE to indicate
   what traffic should be placed on each path that it is aware of.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-flowspec/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-04
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pcep-flowspec-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pcep-flowspec-04


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/

___
I-D-Announce mailing list
i-d-annou...@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce