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

[Mirja Kuehlewind]

Mirja Kühlewind 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:
--

I have quite a few comments and some parts really need fixing as things
seems wrong to me. However, all these things are no big issues in itself
that do not justify a discuss. I strongly recommend to discuss these
points and apply changes where appropriate to make these metrics useful
by providing the right information.

- This doesn't seem right to mean:
"The link bandwidth utilization (the total
   bandwidth of a link in current use for the forwarding)"
Especially the word "current" is irritating as I strongly assume you'd be
interested in something like the average utilization...?

- In general I would clarify that you always talk about averages and not
the current values because those change too dynamically to use them for
path computation.

- section 3 could be removed. It didn't really help me and the normative
language here is actually a little bit confusing to me.

- section 4.2.1: This also doesn't seem to be fully correct:
"An implementation,
   therefore, MAY use the sum of the average delay variation of links
   along a path to derive the average delay variation of the Path."
I would assume that the average path delay variation is NOT the sum of
the link variation.
What you get is the maximum variation of the average link delay
variation... not sure if that's the best metric to provide for path
computation.
Maybe it would be more useful to use the maximum of the average link
delay variation as an extimate for the path delay variation?

Also not sure what exactly the next sentence should tell me:
"An implementation MAY also use some enhanced composition function for
   computing the average delay variation of a path."

- OLD:
"The value for the P2MP path delay metric type (T) = TBD8 is to be
   assigned by IANA."
NEW:
"The value for the P2MP path delay metric type (T) is TBD8."
Also in the next two sections...

- The term "Link Bandwidth Utilization (LBU)" is really confusing because
I thought that utilization always is a value in percentage. I would
propose to go inline with [RFC7471] and [RFC7810] and call it "Utilized
Link Bandwidth"! (Similar for next section)

- section 4.2.2.: Really?
"The actual bandwidth by non-RSVP-TE
   traffic can be calculated by subtracting the available Bandwidth from
   the residual Bandwidth ([RFC7471] and [RFC7810]).  Once we have the
   actual bandwidth for non-RSVP TE traffic, subtracting this from LBU
   would result in LRBU."
Isn't the bandwidth utilization/ulilized bandwidth inculding the Link
Reserved Bandwidth Utilization...? Not sure if I get this part
correctly...

- section 4.2.3.1:
OLD
"A PCE that supports this object MUST ensure that no link on
   the computed path has bandwidth utilization (LBU or LRBU percentage)
   exceeding the given value."
NEW
"A PCE that supports this object MUST compute a path with LBU or LRBU
percentage that does not
   exceed the given value."
I don't think the thing stated in the original sentence is possible based
on the given information in the LBU/LRBU.

- "If, for a given request, two or more instances
   of a BU object with the same type are present, only the first
   instance MUST be considered and other instances MUST be ignored."
Maybe it's better to consider the lowest value instead of the first
instance?

- "If a PCE receives a PCReq message containing a BU object, and the PCE
   does not understand or support the BU object, and the P bit is clear
   in the BU object header then the PCE SHOULD simply ignore the BU
   object."
  Isn't this the default behavior? How should a PCE that does support
this draft/understand the BU object do any actions...?
Similar, the next part:
"If the PCE does not understand the BU object, and the P bit is set in
   the BU object header, then the PCE MUST send a PCErr message
   containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object)
   and Error-value = 1 (Unrecognized object class) as per [RFC5440]."
Just remove those two paragraphs...?

- In general, had the feeling that the order of the document is a little
up-side-down. However, I'm not sure if changing the order helps. Maybe
double-check (also to avoid redunancy)!


___
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

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

[Dhruv Dhody]

Will add. Thanks for the text.

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

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

[Kathleen Moriarty]

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

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

[Dhruv Dhody]

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.
 

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

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

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

[Dhruv Dhody]

Hi Stephen, 

Thanks for your review. Please see inline...

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Stephen Farrell
> Sent: 14 September 2016 17:16
> To: The IESG 
> Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aw...@ietf.org;
> pce-cha...@ietf.org
> Subject: [Pce] Stephen Farrell's No Objection on
> draft-ietf-pce-pcep-service-aware-12: (with COMMENT)
> 
> Stephen Farrell 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:
> --
> 
> 
> - You're missing a reference for TCP-AO (RFC5925 I
> guess)
> 
[Dhruv] Added! 

> - My understanding is that TCP-AO is not widely deployed. If it is expected
> that PCEPS will be, then it'd maybe be good to indicate that in section
> 9.
> 
> - I would have thought that these extensions would provide new ways in which
> networks could lie about things in order to influence what paths are chosen.
> Is that new or was it already considered in the referenced RFCs? (Sorry,
> didn't have time to check right now.) If it is new, maybe it's worth a 
> mention?
> Note: I'm not suggesting that this document specify the one true way to
> deal with that, just that it be noted, if it's useful to do that, but given
> one motivation offered is financial services, presumably not everyone trusts
> everyone to be entirely honest;-)
>
[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.
 

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

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

Re: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE

[Huaimo Chen]

Hi Eric,

Thanks much for your comments.
The static configurations will be minimum regarding to distributing 
connections and accesses from a child PCE to its parent PCE. A child PCE (not 
as a parent of others) will distribute the connections to its domain to its 
parent automatically and dynamically. It will also distribute the access points 
in its domain to its parent. For a child PCE as a parent PCE of some other 
child PCEs, it will summarize the multiple domains under it  (i.e., summarize 
the domains for which its child PCEs are responsible) into one domain (or say 
one cloud) to its parent PCE automatically and dynamically. It will also 
summarize access points for multiple domains received from its child PCEs into 
the access points for one domain (or say one cloud) to its parent PCE. For 
summarizing access points, there may be some policy configurations.

Best Regards,
Huaimo
From: Wunan (Eric)
Sent: Thursday, September 01, 2016 5:42 AM
To: Huaimo Chen; Dhruv Dhody
Cc: pce@ietf.org
Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections 
and Accesses for H-PCE


Hi Huaimo, Dhruv,



I think this is an interesting and constructive discussion. Sorry for 
intervening as non-author for neither of draft, since I'm glad to see it go 
into deeper, technically.

@Dhruv, from my reading, Huaimo is emphasizing "procedure" missing and 
"statically configuration". And you are saying "MAY carry" in PCEP-LS draft. 
Maybe a little more detailed explanation for procedure or protocol extension 
will help. Or missing does exist? So the WG can work on this?

@Huaimo, on the other side, how does your draft solve "statically 
configuration"? Or better on that? Do I make any sense?



Regards

Eric







-

Date: Thu, 1 Sep 2016 11:03:38 +0200

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>

To: Huaimo Chen mailto:huaimo.c...@huawei.com>>

Cc: "pce@ietf.org" mailto:pce@ietf.org>>

Subject: Re: [Pce] Some thoughts on H-PCE topology construction in

Connections and Accesses for H-PCE

Message-ID:


mailto:cab75xn7vdayrhejs8fzpzkzbazzn7ctk5opd1+atzjkqfwp...@mail.gmail.com>>

Content-Type: text/plain; charset="utf-8"



Hi Huaimo,



You say...



   Note that in the existing PCE-LS draft, there are not any procedures

   defined for a child PCE to send and summarize the inter-domain

   connections and access points to its parent PCE, and for a parent PCE

   to receive and process the inter-domain connections and access points

   from its child PCEs.



[PCEP-LS]? draft says...



   Further [RFC6805] describes Hierarchical-PCE architecture, where a

   parent PCE maintains a domain topology map.  To build this domain

   topology map, the child PCE MAY carry the border nodes and inter-

   domain link information to the parent PCE using the mechanism

   described in this document.  Further as described in

   [I-D.dhody-pce-applicability-actn], the child PCE MAY also transport

   abstract Link-State and TE information from child PCE to a Parent PCE

   using the mechanism described in this document to build an abstract

   topology at the parent PCE.?



Thus I respectfully disagree with your assertion. I think the confusion for you 
might be because you are expecting a new set of procedures and encoding to be 
used especially for the purpose of H-PCE from child PCE to parent PCE. When 
there is no need for a *new* set of procedure and encoding. The child PCE, 
acting as a PCC, is responsible for deciding what information needs to be 
transported to the parent PCE, and in this case can use the existing LS node 
object to carry boundary node information and existing LS link object to carry 
the inter-domain link. The LS node/link descriptor TLVs has information that 
will identify that the node/link is boundary-node/inter-AS-link respectfully.



For ex, incase of inter-AS-link, the local node descriptor and remote node 
descriptor will have different AS number clearly identifying that the link is 
inter-AS.



I hope this clarifies the intention from the [PCEP-LS] point of view.



I do not have regular access to email this and coming week, so there might be 
delay from my side in replying future post.



Thanks!



Regards,

Dhruv



On Wed, Aug 31, 2016 at 10:55 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>>

wrote:



> Hi Everyone,

>

> Customers are very interested in the H-PCE and as we continue to

> develop the H-PCE we would like to minimize the amount of manual

> configurations. Two key areas for better automation are:

>

> 1. Advertisement of inter-domain connections (inter-domain links

> and

> ABRs) from child PCE to parent PCE

> 2. Construction of the parent PCE TED based on the advertisement

>

> Existing methods for these two objectives require manual efforts.

> Some automation is possible if the parent PCE can also join the IGP

> instan

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

[Kathleen Moriarty]

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.


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

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

[Stephen Farrell]

Stephen Farrell 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:
--


- You're missing a reference for TCP-AO (RFC5925 I
guess)

- My understanding is that TCP-AO is not widely
deployed. If it is expected that PCEPS will be, then
it'd maybe be good to indicate that in section 9. 

- I would have thought that these extensions would
provide new ways in which networks could lie about
things in order to influence what paths are chosen.
Is that new or was it already considered in the
referenced RFCs? (Sorry, didn't have time to check
right now.) If it is new, maybe it's worth a mention?
Note: I'm not suggesting that this document specify
the one true way to deal with that, just that it be
noted, if it's useful to do that, but given one
motivation offered is financial services, presumably
not everyone trusts everyone to be entirely honest;-)


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

Re: [Pce] Some thoughts on H-PCE topology construction in Connections and Accesses for H-PCE

[Dhruv Dhody]

Hi Eric, Huaimo,

I have updated the PCEP-LS draft with an appendix describing some examples, 
which include the H-PCE case.
https://tools.ietf.org/html/draft-dhodylee-pce-pcep-ls-06#appendix-B.3

B.3.  Between PCEs

   As per Hierarchical-PCE [RFC6805], Parent PCE builds an abstract
   domain topology map with each domain as an abstract node and inter-
   domain links as an abstract link.  Each child PCE may provide this
   information to the parent PCE.  Considering the example in figure 1
   of [RFC6805], following LS object will be generated:

   PCE1
   
   LS Node
  TLV - Local Node Descriptors
  Sub-TLV - 1: Autonomous System: 100 (Domain 1)
  Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)

   LS Link
  TLV - Local Node Descriptors
  Sub-TLV - 1: Autonomous System: 100
  Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
  TLV - Remote Node Descriptors
  Sub-TLV - 1: Autonomous System: 200 (Domain 2)
  Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract)
  TLV - Link Descriptors
  Sub-TLV - 7: IPv4 interface: 11.1.1.1
  Sub-TLV - 8: IPv4 neighbor: 11.1.1.2
  TLV - Link Attributes TLV
  Sub-TLV(s)

   LS Link
  TLV - Local Node Descriptors
  Sub-TLV - 1: Autonomous System: 100
  Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
  TLV - Remote Node Descriptors
  Sub-TLV - 1: Autonomous System: 200
  Sub-TLV - 4: Router-ID: 22.22.22.22 (abstract)
  TLV - Link Descriptors
  Sub-TLV - 7: IPv4 interface: 12.1.1.1
  Sub-TLV - 8: IPv4 neighbor: 12.1.1.2
  TLV - Link Attributes TLV
  Sub-TLV(s)

   LS Link
  TLV - Local Node Descriptors
  Sub-TLV - 1: Autonomous System: 100
  Sub-TLV - 4: Router-ID: 11.11.11.11 (abstract)
  TLV - Remote Node Descriptors
  Sub-TLV - 1: Autonomous System: 400 (Domain 4)
  Sub-TLV - 4: Router-ID: 44.44.44.44 (abstract)
  TLV - Link Descriptors
  Sub-TLV - 7: IPv4 interface: 13.1.1.1
  Sub-TLV - 8: IPv4 neighbor: 13.1.1.2
  TLV - Link Attributes TLV
  Sub-TLV(s)

   * similar information will be generated by other PCE
 to help form the abstract domain topology.

   Further the exact border nodes and abstract internal path between the
   border nodes may also be transported to the Parent PCE to enable ACTN
   as described in [I-D.dhody-pce-applicability-actn] using the similar
   LS node and link objects encodings.

I hope this example clears up how PCEP-LS can be used between child PCE and 
parent PCE. There is no "statically configuration" here.

If you or the WG has any other comment on 
[https://datatracker.ietf.org/doc/draft-dhodylee-pce-pcep-ls/], please let us 
know.

Regards,
Dhruv

From: Wunan (Eric)
Sent: 01 September 2016 15:12
To: Huaimo Chen ; Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] Some thoughts on H-PCE topology construction in Connections 
and Accesses for H-PCE


Hi Huaimo, Dhruv,



I think this is an interesting and constructive discussion. Sorry for 
intervening as non-author for neither of draft, since I'm glad to see it go 
into deeper, technically.

@Dhruv, from my reading, Huaimo is emphasizing "procedure" missing and 
"statically configuration". And you are saying "MAY carry" in PCEP-LS draft. 
Maybe a little more detailed explanation for procedure or protocol extension 
will help. Or missing does exist? So the WG can work on this?

@Huaimo, on the other side, how does your draft solve "statically 
configuration"? Or better on that? Do I make any sense?



Regards

Eric







-

Date: Thu, 1 Sep 2016 11:03:38 +0200

From: Dhruv Dhody mailto:dhruv.i...@gmail.com>>

To: Huaimo Chen mailto:huaimo.c...@huawei.com>>

Cc: "pce@ietf.org" mailto:pce@ietf.org>>

Subject: Re: [Pce] Some thoughts on H-PCE topology construction in

Connections and Accesses for H-PCE

Message-ID:


mailto:cab75xn7vdayrhejs8fzpzkzbazzn7ctk5opd1+atzjkqfwp...@mail.gmail.com>>

Content-Type: text/plain; charset="utf-8"



Hi Huaimo,



You say...



   Note that in the existing PCE-LS draft, there are not any procedures

   defined for a child PCE to send and summarize the inter-domain

   connections and access points to its parent PCE, and for a parent PCE

   to receive and process the inter-domain connections and access points

   from its child PCEs.



[PCEP-LS]? draft says...



   Further [RFC6805] describes Hierarchical-PCE architecture, where a

   parent PCE maintains a domain topology map.  To build this domain

   topology map, the child PCE MAY carry the border nodes and inter-

   domain link information to the parent PCE using the mechanism

   described in this document.  Further as described in

   [I-D.dhody-pce-applicability-actn], the child PCE MAY also transport

   abstract Link-State and TE information from child PCE to a Par