[Pce] Spencer Dawkins' No Objection on draft-ietf-pce-wson-rwa-ext-11: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-pce-wson-rwa-ext-11: 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-wson-rwa-ext/



--
COMMENT:
--

Thank you for the very helpful Section 3.


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

Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Jon,

On Fri, Dec 21, 2018 at 11:25 AM Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> Spencer,
>
> I think it is as Adrian has described below (thanks Adrian).  I will add
> the reference to RFC 8413.
>

Thanks!

Spencer


> Best regards
> Jon
>
> -Original Message-
> From: Adrian Farrel 
> Sent: Thursday, 6 December, 2018 2:49 PM
> To: 'Spencer Dawkins' ; 'The IESG' <
> i...@ietf.org>
> Cc: pce@ietf.org; pce-cha...@ietf.org;
> draft-ietf-pce-segment-rout...@ietf.org
> Subject: RE: [Pce] Spencer Dawkins' No Objection on
> draft-ietf-pce-segment-routing-14: (with COMMENT)
>
> I think that for "bandwidth calendaring" we might reference 8413.
>
> I *think* "on-demand engineering" is simply the converse. That is, traffic
> engineering / path computation at the time of request for service delivery.
> That is "what we have always done" and might not qualify for a specific
> reference.
>
> But the authors will have a better view of what they meant 
>
> Cheers,
> Adrian
> --
> It's Christmas.
> Buy someone you love a book of fairy tales.
> https://www.feedaread.com/profiles/8604/
> Available from your favourite online bookseller.
> Or contact me to receive a signed copy by mail.
>
> -Original Message-
> From: Pce  On Behalf Of Spencer Dawkins
> Sent: 06 December 2018 04:38
> To: The IESG 
> Cc: pce@ietf.org; pce-cha...@ietf.org;
> draft-ietf-pce-segment-rout...@ietf.org
> Subject: [Pce] Spencer Dawkins' No Objection on
> draft-ietf-pce-segment-routing-14: (with COMMENT)
>
> Spencer Dawkins has entered the following ballot position for
> draft-ietf-pce-segment-routing-14: 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-segment-routing/
>
>
>
> --
> COMMENT:
> --
>
> I can guess what
>
>This mechanism is useful in Software Defined
>Networking (SDN) applications, such as on-demand engineering, or
>bandwidth calendaring.
>
> means, but I'm guessing. Is there a reference for "on-demand engineering"
> or "bandwidth calendaring"?
>
>
> ___
> 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] Spencer Dawkins' No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-pce-segment-routing-14: 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-segment-routing/



--
COMMENT:
--

I can guess what

   This mechanism is useful in Software Defined
   Networking (SDN) applications, such as on-demand engineering, or
   bandwidth calendaring.

means, but I'm guessing. Is there a reference for "on-demand engineering" or
"bandwidth calendaring"?


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

Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Jonathan,

On Mon, Apr 16, 2018 at 10:54 AM, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> Hi Spencer
>
> Thanks for your comments.  Please see [Jon] below.
>
> Cheers
> Jon
>
> -Original Message-
> From: Spencer Dawkins [mailto:spencerdawkins.i...@gmail.com]
> Sent: 03 April 2018 03:23
> To: The IESG <i...@ietf.org>
> Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric <
> julien.meu...@orange.com>; pce-cha...@ietf.org; julien.meu...@orange.com;
> pce@ietf.org
> Subject: Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09:
> (with COMMENT)
>
>
> I'll let you folks work with Benjamin on this, but I echo his concern
> about the level of specification covering sub-TLVs (Spencer's summary: "not
> much specification").  As a related comment, I note that not defining any
> sub-TLVs in this document prevents the authors from giving any examples of
> what sub-TLVs might be appropriate, which would have been helpful for me in
> both the Abstract and Introduction.
>
> (I usually prefer clues about whether the reader should be reading a
> specification or not. It would be easier for me to know whether this
> document is relevant to me, if I knew what kinds of sub-TLVs were
> envisioned, even if only a couple of examples were provided. But do the
> right thing, of course)
>
> [Jon] I have proposed an update to Benjamin.  The draft does not need any
> sub-TLVs, hence there are no examples, which has been a frequent pattern in
> PCE RFCs since the working group got started!  Having said that, we could
> immediately point to the first real example of a PST sub-TLV by providing
> an informative reference to draft-ietf-pce-segment-routing.  I don't see
> a problem doing this as the documents were always intended to be published
> together.  How about
>
> OLD
>   This document does not define any sub-TLVs.
> NEW
>   This document does not define any sub-TLVs; an example can be found in
> [I-D.ietf-pce-segment-routing].
> END
>

Since I was echoing Benjamin's concern, I'll echo his relief - whatever you
folks work out, will work for me.

But that sounds like a fine plan to me.

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

[Pce] Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-pce-lsp-setup-type-09: 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-lsp-setup-type/



--
COMMENT:
--

I'll let you folks work with Benjamin on this, but I echo his concern about the
level of specification covering sub-TLVs (Spencer's summary: "not much
specification").  As a related comment, I note that not defining any sub-TLVs
in this document prevents the authors from giving any examples of what sub-TLVs
might be appropriate, which would have been helpful for me in both the Abstract
and Introduction.

(I usually prefer clues about whether the reader should be reading a
specification or not. It would be easier for me to know whether this document
is relevant to me, if I knew what kinds of sub-TLVs were envisioned, even if
only a couple of examples were provided. But do the right thing, of course)


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

[Pce] Spencer Dawkins' No Objection on draft-ietf-pce-pce-initiated-lsp-11: (with COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-pce-pce-initiated-lsp-11: 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-pce-initiated-lsp/



--
COMMENT:
--

Thanks for considering my Discuss.

Previous comments follow - I didn't check for these in the new version.

In this text,

  The State Timeout Interval timer ensures that a PCE crash does not
   result in automatic and immediate disruption for the services using
   PCE-initiated LSPs.  PCE-initiated LSPs are not removed immediately
   upon PCE failure.  Instead, they are cleaned up on the expiration of
   this timer.  This allows for network cleanup without manual
   intervention.  The PCC SHOULD support removal of PCE-initiated LSPs
   as one of the behaviors applied on expiration of the State Timeout
   Interval timer.  The behavior SHOULD be picked based on local policy,
   and can result either in LSP removal, or in reverting to operator-
   defined default parameters.

I found myself wondering why “The PCC SHOULD support removal of PCE-initiated
LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say
something about the effects of not supporting this, in order to help
implementers make an informed decision about whether to support it.

In the same text, I found myself wondering if there were other alternatives to
local policy for the last SHOULD, which is, of course, the last stop on the way
to asking why this isn’t a MUST …


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

Re: [Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)

[Spencer Dawkins at IETF]

Hi, Jon,

On Wed, Oct 4, 2017 at 8:48 AM, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> Hi Spencer
>
> Many thanks for these comments.  I'm picking up this thread and replying
> as PCE working group chair, as the authors are unavailable.  I am very
> sorry for the delay.
>
> Please see my proposed resolutions inline below, marked with "Jon>"
>

I'd clear based on an update that heads this direction. Want to let me know
when the working group has had a chance to review the proposed text?

And thanks.

Spencer


> Best regards
> Jon
>
> 
>
> --
> DISCUSS:
> --
>
> This ballot position would be Please Educate Me, if that was a choice, but
> that's not a choice. I'm sure we can clear this quickly. And I found this
> document very easy to read as a reviewer - thanks for that.
>
> I found a couple of places where SHOULDs seemed at least under-specified,
> and this one looked important.
>
> In this text,
>
>   LSP State Synchronization procedures are described in section 5.4 of
>[I-D.ietf-pce-stateful-pce].  During State Synchronization, a PCC
>reports the state of its LSPs to the PCE using PCRpt messages,
>setting the SYNC flag in the LSP Object.  For PCE-initiated LSPs, the
>PCC MUST also set the Create Flag in the LSP Object and MAY include
>the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP
>creation.  At the end of state synchronization, the PCE SHOULD
>compare the reported PCE-Initiated LSPs with its configuration.  For
>any mismatch, the PCE SHOULD send a PCInitiate message to initiate
>any missing LSPs and/or remove any LSPs that are not wanted.
>
> I’m having a hard time understanding why a PCE would not compare reported
> PCE-Initiated LSPs with its configuration, which is allowed by the first
> SHOULD. Does that mean you thought it was important to TRY to synchronize,
> but you’re not curious enough to check whether that worked?
>
> I can imagine reasons why you wouldn't try to fix the LSPs that weren't
> synchronized, at least not immediately, but you might also give guidance
> about one or more reasons why you wouldn't try, to help implementers
> understand what not doing what the SHOULD means, and make informed choices
> for their implementations.
>
>
> Jon> I definitely agree with you that, having received a snapshot from the
> PCC, there is no reason that the PCE would not then compare the PCC's state
> with its local copy i.e. the first SHOULD ought to be a MUST.  The
> intention of the second SHOULD was to leave the PCE with some flexibility
> for dealing with clients that are out of sync.  For example, perhaps the
> clients are slow, or perhaps the operator's policy is to prefer not to
> disrupt existing flows so long as the main characteristics of the flows are
> correct.  These are just my invented examples, but we expect there might be
> valid operational reasons along these lines, so we wanted to the draft to
> allow the server the flexibility to choose whether it updates the flows, or
> not.
>
> Here is my proposed fix.
>
> OLD
>== as quoted above ===
> NEW
>LSP State Synchronization procedures are described in section 5.4 of
>[RFC8231].  During State Synchronization, a PCC
>reports the state of its LSPs to the PCE using PCRpt messages,
>setting the SYNC flag in the LSP Object.  For PCE-initiated LSPs, the
>PCC MUST also set the Create Flag in the LSP Object and MAY include
>the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP
>creation.  At the end of state synchronization, the PCE MUST
>compare the reported PCE-Initiated LSPs with its configuration.  For
>any mismatch, the PCE SHOULD send a PCInitiate message to initiate
>any missing LSPs and/or remove any LSPs that are not wanted.  Under
>some circumstances, depending on the deployment,  it might be preferable
>for a PCE not to send this PCInitiate immediately, or at all.  For
>example, the PCC may be a slow device, or the operator might prefer
>not to disrupt active flows.
>
>
> --
> COMMENT:
> --
>
> In this text,
>
>   The State Timeout Interval timer ensures that a PCE crash does not
>result in automatic and immediate disruption for the services using
>PCE-initiated LSPs.  PCE-initiated LSPs are not removed immediately
>upon PCE failure.  Instead, they are cleaned up on the expiration of
>this timer.  This allows for network cleanup without manual
>intervention.  The PCC SHOULD support removal of PCE-initiated LSPs
>as one of the behaviors applied on expiration of the State Timeout
>Interval timer.  The behavior SHOULD be picked based on local policy,
>and can result either in LSP 

[Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)

[Spencer Dawkins]

Spencer Dawkins has entered the following ballot position for
draft-ietf-pce-pce-initiated-lsp-10: 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://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-pce-initiated-lsp/



--
DISCUSS:
--

This ballot position would be Please Educate Me, if that was a choice, but
that's not a choice. I'm sure we can clear this quickly. And I found this
document very easy to read as a reviewer - thanks for that.

I found a couple of places where SHOULDs seemed at least under-specified, and
this one looked important.

In this text,

  LSP State Synchronization procedures are described in section 5.4 of
   [I-D.ietf-pce-stateful-pce].  During State Synchronization, a PCC
   reports the state of its LSPs to the PCE using PCRpt messages,
   setting the SYNC flag in the LSP Object.  For PCE-initiated LSPs, the
   PCC MUST also set the Create Flag in the LSP Object and MAY include
   the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP
   creation.  At the end of state synchronization, the PCE SHOULD
   compare the reported PCE-Initiated LSPs with its configuration.  For
   any mismatch, the PCE SHOULD send a PCInitiate message to initiate
   any missing LSPs and/or remove any LSPs that are not wanted.

I’m having a hard time understanding why a PCE would not compare reported
PCE-Initiated LSPs with its configuration, which is allowed by the first
SHOULD. Does that mean you thought it was important to TRY to synchronize, but
you’re not curious enough to check whether that worked?

I can imagine reasons why you wouldn't try to fix the LSPs that weren't
synchronized, at least not immediately, but you might also give guidance about
one or more reasons why you wouldn't try, to help implementers understand what
not doing what the SHOULD means, and make informed choices for their
implementations.


--
COMMENT:
--

In this text,

  The State Timeout Interval timer ensures that a PCE crash does not
   result in automatic and immediate disruption for the services using
   PCE-initiated LSPs.  PCE-initiated LSPs are not removed immediately
   upon PCE failure.  Instead, they are cleaned up on the expiration of
   this timer.  This allows for network cleanup without manual
   intervention.  The PCC SHOULD support removal of PCE-initiated LSPs
   as one of the behaviors applied on expiration of the State Timeout
   Interval timer.  The behavior SHOULD be picked based on local policy,
   and can result either in LSP removal, or in reverting to operator-
   defined default parameters.

I found myself wondering why “The PCC SHOULD support removal of PCE-initiated
LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say
something about the effects of not supporting this, in order to help
implementers make an informed decision about whether to support it.

In the same text, I found myself wondering if there were other alternatives to
local policy for the last SHOULD, which is, of course, the last stop on the way
to asking why this isn’t a MUST …


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

Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Dhruv,

On Tue, Aug 8, 2017 at 6:08 AM, Dhruv Dhody <dhruv.dh...@huawei.com> wrote:

> Hi Spencer,
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.i...@gmail.com]
> *Sent:* 07 August 2017 21:17
> *To:* Dhruv Dhody <dhruv.dh...@huawei.com>
> *Cc:* Alexey Melnikov <aamelni...@fastmail.fm>; cmarga...@juniper.net;
> draft-ietf-pce-pc...@ietf.org; pce@ietf.org; The IESG <i...@ietf.org>;
> pce-cha...@ietf.org
> *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15:
> (with COMMENT)
>
>
>
> Hi, Dhruv,
>
>
>
> On Mon, Aug 7, 2017 at 9:43 AM, Dhruv Dhody <dhruv.dh...@huawei.com>
> wrote:
>
> Hi Spencer, Alexey,
>
>
>
> The text refers to the Error itself.
>
>
>
>If a PCEP speaker that is unwilling or unable to negotiate TLS
>
>receives a StartTLS messages, it MUST return a PCErr message (in
>
>clear) with Error-Type set to [TBA2 by IANA] (PCEP StartTLS failure)
>
>and Error-value set to:
>
>
>
>o  3 (not without TLS) if it is not willing to exchange PCEP messages
>
>   without the solicited TLS connection, and it MUST close the TCP
>
>   session.
>
>
>
> I can see how it could be misleading and I have corrected it to –
>
>
>
>   +-+-+ +-+-+
>
>   |PCC| |PCE|
>
>   +-+-+ +-+-+
>
> | |
>
> | StartTLS|
>
> | msg | PCE waits
>
> |>| for PCC
>
> |   PCErr |
>
> |<| Send Error
>
> | | Type=TBA2,Value=3
>
> | | (not without TLS)
>
> |<|
>
> |   Close |
>
>
>
>
>
>
>
>Figure 5: Both PCEP Speaker supports PCEPS as well as without PCEPS,
>
>but PCE cannot start TLS negotiation
>
>
>
> This is still Alexey's ballot, of course, but ...
>
>
>
> I like the change you're making, but the part that confused me is that in
> English, multiple negatives don't work well - so, "not without TLS"
> simplifies to "with TLS" in common usage.
>
>
>
> Are you using "not without TLS" to mean "TLS usage required", or something
> like that?
>
>
>
> Spencer
>
> *[[Dhruv Dhody]] Yes, it means *"TLS usage required".  *I can reword it
> to the text we have in the IANA section –*
>

Thanks! I know what that means.

Spencer


>
>
>Error-
>
>TypeMeaning   Error-value Reference
>
>
>
>  3:Failure, connection   This document
>
>  without TLS not
>
>  possible
>
>  4:Failure, connection   This document
>
>   without TLS possible
>
>
>
> *Regards,*
>
> *Dhruv*
>
>
>
> Regards,
>
> Dhruv
>
>
>
> *From:* Pce [mailto:pce-boun...@ietf.org] *On Behalf Of *Spencer Dawkins
> at IETF
> *Sent:* 07 August 2017 19:16
> *To:* Alexey Melnikov <aamelni...@fastmail.fm>
> *Cc:* cmarga...@juniper.net; draft-ietf-pce-pc...@ietf.org; pce@ietf.org;
> The IESG <i...@ietf.org>; pce-cha...@ietf.org
> *Subject:* Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15:
> (with COMMENT)
>
>
>
> This is Alexey's ballot, but ...
>
>
>
> On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov <aamelni...@fastmail.fm>
> wrote:
>
> One more little thing:
>
>
> In figure 5, I see: Send Error (not without TLS)
>
> What does "not without TLS" mean? I think the figure is sending PCErr in
> the clear (without TLS)
>
>
>
> This text wasn't clear to me, either.
>
>
>
> Thanks for actually mentioning this in your ballot, Alexey.
>
>
>
> Spencer
>
>
>
> On Mon, Aug 7, 2017, at 11:46 AM, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-pce-pceps-15: Yes
>  (snip)
>
> > I think the text about use of RFC 6125 should use RFC 6125 terminology
> > like
> > DNS-ID and CN-ID, because they have a bit more semantics associated with
> > them
> > other than just subjectAltName:DNS. I think you should also clarify
> > whether you
> > want to allow wildcards in DNS-ID/CN-ID (RFC 6125 talks about that).
> >
> >
>
>
>
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Alexey Melnikov's Yes on draft-ietf-pce-pceps-15: (with COMMENT)

[Spencer Dawkins at IETF]

This is Alexey's ballot, but ...

On Mon, Aug 7, 2017 at 5:48 AM, Alexey Melnikov 
wrote:

> One more little thing:
>
>
> In figure 5, I see: Send Error (not without TLS)
>
> What does "not without TLS" mean? I think the figure is sending PCErr in
> the clear (without TLS)
>

This text wasn't clear to me, either.

Thanks for actually mentioning this in your ballot, Alexey.

Spencer


> On Mon, Aug 7, 2017, at 11:46 AM, Alexey Melnikov wrote:
> > Alexey Melnikov has entered the following ballot position for
> > draft-ietf-pce-pceps-15: Yes
>  (snip)
> > I think the text about use of RFC 6125 should use RFC 6125 terminology
> > like
> > DNS-ID and CN-ID, because they have a bit more semantics associated with
> > them
> > other than just subjectAltName:DNS. I think you should also clarify
> > whether you
> > want to allow wildcards in DNS-ID/CN-ID (RFC 6125 talks about that).
> >
> >
>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[Spencer Dawkins at IETF]

Hi, Deborah/Dhruv,

On Thu, Sep 15, 2016 at 9:03 AM, BRUNGARD, DEBORAH A  wrote:

> Hi Mirja,
>
> Yes, thanks Mirja for you detailed review.
>
> As Dhruv noted, this is not representing an average utilization, but the
> current bandwidth utilization. As Dhruv noted, we could swap this sentence
> in the Abstract for the term later used in section 4.2.2 "actual". For me,
> though, current bandwidth utilization is a common (simple) term used often
> by operational folks, and it has a time element clarification. The document
> has been reviewed quite extensively by others, so I'm not convinced about
> the need to change this sentence of the Abstract. We'll discuss it more
> among the Chairs and authors.


Mirja may be having a post-telechat beer, and this is for her ballot
position, but I'm thinking that "time element clarification" is key here.
If "current bandwidth utilization" is measured on a scale of minutes or
larger, it usually doesn't freak out TSV folk, but if it's measured on a
scale of single-digit seconds or smaller, it usually does.

At least, it freaks me out. I spent most of the time I was responsible AD
for one particular working group talking to them about how frequently they
should be adjusting cost maps based on bandwidth utilization and other,
basically instantaneous, transport metrics. The more frequently people make
adjustments, the more likely you are to see oscillation between paths that
you don't really want to see. For a distributed system, you're always
basing decisions on something in the past that may have changed since you
found out about it.

I'll let Mirja take it from here on resolving her comment (because she
might be talking about something completely different), but wanted to chime
in, so that her comment doesn't become my comment, too.

Thanks,

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

Re: [Pce] Kathleen Moriarty's No Objection on draft-ietf-pce-pcep-service-aware-12: (with COMMENT)

[Spencer Dawkins at IETF]

Dhruv,

On Wed, Sep 14, 2016 at 1:41 PM, Dhruv Dhody  wrote:

> Will add. Thanks for the text.


Now that you have feedback from at least one SEC AD, I wanted to add that I
thought your text was very helpful (and even more helpful with Kathleen's
addition, of course).

Thanks,

Spencer, who isn't speaking for Mirja, either, of course!


>
> Dhruv
>
>
> On Thursday 15 September 2016, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
>
>> Hello,
>>
>> Thanks for the quick response.  inline.
>>
>> On Wed, Sep 14, 2016 at 1:57 PM, Dhruv Dhody 
>> wrote:
>> > Hi Kathleen,
>> >
>> > Thanks for your review.
>> > I am posting the updated security consideration text (same as in the
>> reply to Stephen), see inline.
>> >
>> >> -Original Message-
>> >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Kathleen Moriarty
>> >> Sent: 14 September 2016 22:27
>> >> To: The IESG 
>> >> Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org;
>> >> pce-cha...@ietf.org
>> >> Subject: [Pce] Kathleen Moriarty's No Objection on
>> >> draft-ietf-pce-pcep-service-aware-12: (with COMMENT)
>> >>
>> >> Kathleen Moriarty has entered the following ballot position for
>> >> draft-ietf-pce-pcep-service-aware-12: 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-service-aware/
>> >>
>> >>
>> >>
>> >> --
>> >> COMMENT:
>> >> --
>> >>
>> >> The security sections of the referenced documents look very good.  The
>> one
>> >> thing I don't see mentioned is use of these metrics to perform network
>> >> reconnaissance to perform other attacks.  I'm also interested to see
>> the
>> >> responses to Stephen's questions.
>> >>
>> >> Thanks.
>> >
>> >
>> > [Dhruv] Updated security consideration section reads -
>> > OLD
>> >This document defines new METRIC types, a new BU object, and new OF
>> >codes which does not add any new security concerns beyond those
>> >discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
>> >find the service aware information like delay and packet loss to be
>> >extra sensitive and thus should employ suitable PCEP security
>> >mechanisms like TCP-AO or [PCEPS].
>> > NEW
>> >This document defines new METRIC types, a new BU object, and new OF
>> >codes which does not add any new security concerns beyond those
>> >discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
>> >find the service aware information like delay and packet loss to be
>> >extra sensitive and could be used to influence path computation and
>> >setup with adverse effect.  Additionally snooping of PCEP messages
>> >with such data may give an attacker sensitive information about the
>> >operations of the network.  Thus, such deployment should employ
>> >suitable PCEP security mechanisms like TCP Authentication Option
>> >(TCP-AO) [RFC5925] or [PCEPS].  The Transport Layer Security (TLS)
>> >based procedure in [PCEPS] is considered as a security enhancement
>> >and thus much better suited for the sensitive service aware
>> >information.
>>
>> This looks good for Stephen's comment, could you add in something
>> about reconnaissance as well?  Maybe:
>>
>> current new:
>>   Additionally snooping of PCEP messages
>>   with such data may give an attacker sensitive information about the
>>  operations of the network.
>> proposed new:
>>   Additionally snooping of PCEP messages
>>   with such data, or using PCEP messages for network
>> reconnaissance, may give an attacker sensitive information about the
>>   operations of the network.
>>
>> Thanks,
>> Kathleen
>>
>> >
>> >
>> > Let me know if you would like some change in wordings.
>> >
>> > Thanks!
>> > Dhruv
>> >
>> >>
>> >>
>> >> ___
>> >> Pce mailing list
>> >> Pce@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/pce
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce