gmane.ietf.pce

Re: Review ofdraft-ietf-pce-pcep-inter-domain-p2mp-procedures-04

Daniel King — 2013-06-18T05:47:53

Thanks Oscar! This will really help improve the readability of the draft. We
will update the draft, but also respond to each of the points specifically
and clarify any technical issues.  

 

Br, Dan. 

 

From: Oscar González de Dios [mailto:ogondio< at >tid.es] 
Sent: 17 June 2013 17:09
To: pce< at >ietf.org;
draft-ietf-pce-pcep-inter-domain-p2mp-procedures< at >tools.ietf.org
Subject: Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04

 

Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04,

 

Please find bellow some comments regarding the PCEP P2MP Procedures  draft
(sorry for sending them after the 2 weeks deadline for the LC comments):

 

- There is a strange page jump in the Terminology section. After "RFC5862]"
and "ABR: " there is whole blank page

 

- Terminology section: Blank line missing between Transit/branch domain and
VSPT

 

- During the document there are 3 different acronyms "P2MP LSP" (section 3 )
"P2MP TE-LSP" (this one only in section 6) and "P2MP TE LSP" (the most
common in the document). I suggest aligning the terminology and always use
the same term to avoid confusion. . For "historical" reasons, "P2MP TE LSP",
used in RFC 4461 seems appropriate. The definition of P2M2 TE LSP used in
RFC 4661 may be cited too in the terminology section for completeness.

 

- In the terminology section the term "Boundary node (BN) is defined.
However, later on, the term "border node" is also used, presumably as an
synonym. I suggest either choose one term for the whole document or include
the term border node too in the terminology. 

 

- Section 3. The sentence "A sub-tree is a part of the P2MP tree describing
how the root or an intermediate P2MP LSPs minimizes packet duplication when
P2P TE sub-LSPs traverse common links" is hard to understand (maybe there is
a typo and it should say "the root of an intermediate P2P LSP"). 

- The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined in RFC
4661. Maybe it should be worth adding the sub-LSP terms it to the
terminology section.

- In section 4 the term "sequence of domains" is also used to refer to the
path domain tree. This introduces confusion, as there is also a "domain
sequence" term which applies only to P2P. Please use always "path domain
tree"

 

-Section 4, 2nd paragraph, "domain path tree", use the term "path domain
tree" defined in the terminology section.

- Section 4, figure 1 legend is "Domain sequence tree". This term is not
defined in the terminology. I would prefer to stick to the term "Path Domain
tree". Sorry to be picky about the terminology, but reading the document is
hard when the terms are mixed as they are very alike.

 

- Section 4, assumptions, first bullet. Where it says " each of the P2MP
destination" it should day "each of the P2MP destinations".

 

Section 4,   assumption 1, "or PCE sequence (i.e. PCE that serves each
domain in the path domain tree)". I don't get this point. Initially it was
stated that the path domain tree is known. In this point, is it suggested an
alternative to knowing the path domain tree? That is, instead of assuming
that the path domain tree is known, what is known is a set of PCEs? Please
clarify

 

Section 4, assumption 1, How is the set of PCEs and their relationships
exchanged? What are the relationships that need to be exchanged?

 

Section 4, assumptions, I guess, there is an (maybe obvious) assumptions
that the association domain - PCE is known in advance.

 

Sesction 4, assumption 4. "The boundary nodes to use on the LSP are
pre-determined". Does this mean then that both the path domain tree AND the
boundary nodes are known in advance for each possible P2MP combination?

At this point there is something I miss  Later, in section 7, it is
mentioned that a core tree is computed. However, it seems from the
assumptions that the core tree is fixed in advance Maybe I am
mis-interpreting the assumptions Please clarify the assumptions of what is
really pre-determined and what is computed.

 

Section 5. requirement 4. I suggest using better "PCReq and PCEReq messages"
using the terminology of RFC 5440.

 

Section 5. The requirements from 5 to 8 are not written like requirements. I
suggest re-writing them with requirements language. 

 

Section 6. Objective function 3. The definition of the core tree  in the
terminology section considers ONLY entry boundary nodes as leaves. However,
it seems here both entry and exit BNs are considered. Please clarify (maybe
it should be mentioned only BNs without distinction among entry or exit).

 

Section 6. Objective function 3 is about limiting the number of entry points
to a domain. Why would there be more that one entry point to a domain? I
would expect multiple exit points (that is, several boundary nodes to exit
to other domains in the tree). Also, given that, by the assumptions in
section 4, the path domain tree AND the boundary nodes are flxed, I do not
know if this objective function has any impact at all. 

In any case, limiting the number of entry points may an additional
constraint to the previous objective functions It seems more a metric
constraint rather than an objective function.. 

Also, is it considered that several of this objective functions can be
applied or combined?

 

Section 6, objective function 4 I don't get that one could you clarify it?

 

Section 7.1 The sentence "An optimal core-tree [based on the OF] will be
computed with analyzing the nodes and links within the domains" sounds a bit
strange maybe the "with" is not needed in the sentence? Also.. Previously
it was mentioned that the core-tree was formed only considering entry and
exit nodes, but now, it seems that the core-tree is obtained taking into
account the whole set of nodes and links Please clarify here (or clarify
objective function 2 where it says "formed by considering only the entry and
exit nodes")

 

-  Section 7.3 When mentioning the request with the C bit set I suggest
adding "(defined later in section 7.4.1 of this document)", as it is a new
flag 

 

- Section 7.4.2. I guess "domain-sequence" is really the domain tree One
question the PCE sequence is a PCE tree? 

 

And that's all :-) I hope the comments can be useful to improve the
readability of the draft.

 

 Best Regards,

 

Oscar 

 

  _____  


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04

Oscar González de Dios — 2013-06-17T16:09:05

Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04,

Please find bellow some comments regarding the PCEP P2MP Procedures draft (sorry for sending them after the 2 weeks deadline for the LC comments):

- There is a strange page jump in the Terminology section. After "RFC5862]" and "ABR: " there is whole blank page…

- Terminology section: Blank line missing between Transit/branch domain and VSPT

- During the document there are 3 different acronyms "P2MP LSP" (section 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE LSP" (the most common in the document). I suggest aligning the terminology and always use the same term to avoid confusion. . For "historical" reasons, "P2MP TE LSP", used in RFC 4461 seems appropriate. The definition of P2M2 TE LSP used in RFC 4661 may be cited too in the terminology section for completeness.

- In the terminology section the term "Boundary node (BN) is defined. However, later on, the term "border node" is also used, presumably as an synonym. I suggest either choose one term for the whole document or include the term border node too in the terminology.

- Section 3. The sentence "A sub-tree is a part of the P2MP tree describing how the root or an intermediate P2MP LSPs minimizes packet duplication when P2P TE sub-LSPs traverse common links" is hard to understand (maybe there is a typo and it should say "the root of an intermediate P2P LSP").
- The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined in RFC 4661. Maybe it should be worth adding the sub-LSP terms it to the terminology section.
- In section 4 the term "sequence of domains" is also used to refer to the path domain tree. This introduces confusion, as there is also a "domain sequence" term which applies only to P2P. Please use always "path domain tree"

-Section 4, 2nd paragraph, "domain path tree", use the term "path domain tree" defined in the terminology section.
- Section 4, figure 1 legend is "Domain sequence tree". This term is not defined in the terminology. I would prefer to stick to the term "Path Domain tree". Sorry to be picky about the terminology, but reading the document is hard when the terms are mixed as they are very alike….

- Section 4, assumptions, first bullet. Where it says " each of the P2MP destination" it should day "each of the P2MP destinations".

Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each domain in the path domain tree)". I don't get this point…. Initially it was stated that the path domain tree is known. In this point, is it suggested an alternative to knowing the path domain tree? That is, instead of assuming that the path domain tree is known, what is known is a set of PCEs? Please clarify

Section 4, assumption 1, How is the set of PCEs and their relationships exchanged? What are the relationships that need to be exchanged?

Section 4, assumptions, I guess, there is an (maybe obvious) assumptions that the association domain - PCE is known in advance.

Sesction 4, assumption 4. "The boundary nodes to use on the LSP are pre-determined". Does this mean then that both the path domain tree AND the boundary nodes are known in advance for each possible P2MP combination?
At this point there is something I miss… Later, in section 7, it is mentioned that a core tree is computed. However, it seems from the assumptions that the core tree is fixed in advance… Maybe I am mis-interpreting the assumptions… Please clarify the assumptions of what is really pre-determined and what is computed.

Section 5. requirement 4. I suggest using better "PCReq and PCEReq messages" using the terminology of RFC 5440.

Section 5. The requirements from 5 to 8 are not written like requirements. I suggest re-writing them with requirements language.

Section 6. Objective function 3. The definition of the core tree in the terminology section considers ONLY entry boundary nodes as leaves. However, it seems here both entry and exit BNs are considered. Please clarify… (maybe it should be mentioned only BNs without distinction among entry or exit).

Section 6. Objective function 3 is about limiting the number of entry points to a domain. Why would there be more that one entry point to a domain? I would expect multiple exit points (that is, several boundary nodes to exit to other domains in the tree). Also, given that, by the assumptions in section 4, the path domain tree AND the boundary nodes are flxed, I do not know if this objective function has any impact at all….
In any case, limiting the number of entry points may an additional constraint to the previous objective functions… It seems more a metric constraint rather than an objective function..
Also, is it considered that several of this objective functions can be applied or combined?

Section 6, objective function 4… I don't get that one… could you clarify it?

Section 7.1 The sentence "An optimal core-tree [based on the OF] will be computed with analyzing the nodes and links within the domains" sounds a bit strange… maybe the "with" is not needed in the sentence? Also.. Previously it was mentioned that the core-tree was formed only considering entry and exit nodes, but now, it seems that the core-tree is obtained taking into account the whole set of nodes and links… Please clarify here (or clarify objective function 2 where it says "formed by considering only the entry and exit nodes"…)

- Section 7.3 When mentioning the request with the C bit set I suggest adding "(defined later in section 7.4.1 of this document)", as it is a new flag…

- Section 7.4.2. I guess "domain-sequence" is really the domain tree… One question… the PCE sequence… is a PCE tree?

And that's all :-) I hope the comments can be useful to improve the readability of the draft.

Best Regards,

Oscar

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Re: Next steps for draft-farrkingel-pce-questions

Julien Meuric — 2013-06-17T15:43:41

Hi all.

As individual, I share the views expressed on the list: now that the I-D 
exists, it would be a pity to let it die. Contrary to elephants, human 
beings forget, so I would say: "go for an RFC!"

Chair hat on, I thinks that:
- RFC errata is out of scope: it is supposed to be used for document 
fixes, not updates;
- the choice between WG stream and individual streams remains in 
authors' hands (just note that, based on the feedback seen on the list, 
it would make sense to poll for WG adoption);
- I am not really comfortable with the option refered to as "publication 
of the individual I-D under the care of the WG" because "under the care 
of the WG" is not clear to me in that context;
- in any case, once published as an RFC, nothing prevents from 
submitting a volume 2 later ("PCE FAQ: the pachyderm returns [for 
peanuts]").

Regards,

Julien


On 06/12/2013 16:27, Adrian Farrel wrote:

Re: New version of the stateful pce applicabilitydraft-draft-zhang-pce-stateful-pce-app-04

Ina Minei — 2013-06-14T21:50:01

Ravi,

Thank you for the careful review.

I think you bring up very good points on the opportunities active stateful PCE opens. In particular, the ability to simplify the routers and scale various components, simplify operations, etc.  Although this may not directly translate to a specific use case, I think there is value in discussing these issues in the next version of the draft and will work on adding specific text.

Thank you,

Ina

From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Zhangxian (Xian)
Sent: Tuesday, June 04, 2013 6:26 PM
To: Ravi Torvi; adrian< at >olddog.co.uk
Cc: pce< at >ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

Hi, Ravi,

   Thank you very much for the useful suggestions. Please find my reply inline:

Regards,
Xian

From: pce-bounces< at >ietf.org<mailto:pce-bounces< at >ietf.org> [mailto:pce-bounces< at >ietf.org] On Behalf Of Ravi Torvi
Sent: 2013年6月5日 0:32
To: adrian< at >olddog.co.uk<mailto:adrian< at >olddog.co.uk>
Cc: pce< at >ietf.org<mailto:pce< at >ietf.org>
Subject: Re: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

Hi Ina & Authors,
Now that we have new WG charter, I think it is a good time to clarify applicability of PCE-Stateful.

Following are some of my observations that can be considered in your next revisions of draft:
1. We need to scope the PCE-Stateful applicability, i.e., clarify explicitly where vanilla PCE can be sufficient or PCE-Stateful could be an overkill.
    - Similarly, it would be nice to describe deployments of Passive Stateful PCE and  with Active Stateful PCE separately
I think draft describes goodness of Stateful well, however, it should provide guidelines for choosing right set of PCE-stateful features.
###: In this version, we did explicitly describe these two different kinds of stateful PCEs in a variety of use cases since they have different capabilities. If you have look at the use cases we have from Section 5, you should be able to find such update. If there are still things missing , please let us know.
###: As for where the stateful PCE is applicable, I think the whole document is trying to say its necessity, I do not see why we need to name examples where it is not needed. However, we do state the pros and cons of stateful PCEs here and there as well as in the use cases so as to make it less advertising as JP suggested in last IETF.

Few basic applications (I am not sure this draft covers them explicitly) from PCC Scale point of view:

2. I think draft should describe on performance w/ PCE-Stateful
    i.e., How PCE Stateful helps in dynamic changes compared to NMS based.
###: In this document, we are comparing with a stateless PCE, not NMS. Why do you think there is such a need to compare with the latter? IMHO,  stateful PCEs are not trying to replace NMS since they have different utilities. Just as you mentioned that stateful PCEs can help with dynamic changes, which I do not think it is what NMS is mainly used for.
3. One obvious applicability of Active PCE-Stateful would be : config scaling. Operators do not have to maintain tons of LSP configuration on the box.
###: I do not get your point, are you comparing NMS-based configuration with stateful PCE-based configuration?
4. LSP monitoring is less expensive with PCE Stateful, as PCE is expected to maintain complete state.
This reduces burden on routers.
###: Again, what entity are you comparing stateful PCE with? Could you elaborate more? I haven’t thought about this before. BTW, this draft works for both MPLS-TE and GMPLS controlled networks. So I wonder when you say “this reduces burden on routers”, do you mean this applications are only possible with MPLS-TE networks?
Thanks,
Ravi


http://www.google.com/profiles/pratiravi

On Sun, Jun 2, 2013 at 11:36 AM, Adrian Farrel <adrian< at >olddog.co.uk<mailto:adrian< at >olddog.co.uk>> wrote:
Ina, WG,

Pleased to see people thinking about applicability and use cases. IMHO, not enough attention is paid to why we are doing things and how they will be used.

Thanks for the work, and hope people will review it (especially service providers!)

Adrian

From: pce-bounces< at >ietf.org<mailto:pce-bounces< at >ietf.org> [mailto:pce-bounces< at >ietf.org<mailto:pce-bounces< at >ietf.org>] On Behalf Of Ina Minei
Sent: 26 May 2013 22:52
To: pce< at >ietf.org<mailto:pce< at >ietf.org>
Subject: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

A new version of the stateful pce applicability draft was posted yesterday.

In the interest of making progress on this document, the authors would like to solicit review, comments and discussion from the working group, before the next IETF meeting.


URL:             http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt
Status:          http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app
Htmlized:        http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-zhang-pce-stateful-pce-app-04


Ina and Xian on behalf of all the authors


_______________________________________________
Pce mailing list
Pce< at >ietf.org<mailto:Pce< at >ietf.org>
https://www.ietf.org/mailman/listinfo/pce

Re: Next steps for draft-farrkingel-pce-questions

Leeyoung — 2013-06-14T21:35:49

I agree with Fatai and Ina on that this draft might be worthy of the consideration for an informational RFC. 

Regards,
Young

-----Original Message-----
From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Ina Minei
Sent: Friday, June 14, 2013 4:19 PM
To: adrian< at >olddog.co.uk; 'Ramon Casellas'; Fatai Zhang
Cc: pce< at >ietf.org
Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions

Adrian, 

I think there is value in this document, and it seems to fit well with an informational document. While I share your concern that some areas are rapidly changing, the process of progressing documents is not very fast either, so there is time and opportunity to update it :-)

Ina  

-----Original Message-----
From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, June 13, 2013 9:45 AM
To: 'Ramon Casellas'
Cc: pce< at >ietf.org
Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions

[snip]

I suppose the question might be:
Could we get to a position where we have covered 90% of the questions that might arise in subsequent two years?
If so, then it would sound like an RFC might be useful. Just like we published the original framework RFC without keeping it alive for ever as a regularly-updated I-D.

But if we don't think we can get this stable (perhaps the field is expanding too
fast) then maybe a wiki? 
I don't like a wiki for this because it doesn't register consensus or become more widely visible.

Cheers,
Adrian

_______________________________________________
Pce mailing list
Pce< at >ietf.org
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce< at >ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: Next steps for draft-farrkingel-pce-questions

Ina Minei — 2013-06-14T21:18:46

Adrian, 

I think there is value in this document, and it seems to fit well with an informational document. While I share your concern that some areas are rapidly changing, the process of progressing documents is not very fast either, so there is time and opportunity to update it :-)

Ina  


-----Original Message-----
From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Adrian Farrel
Sent: Thursday, June 13, 2013 9:45 AM
To: 'Ramon Casellas'
Cc: pce< at >ietf.org
Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions

[snip]

I suppose the question might be:
Could we get to a position where we have covered 90% of the questions that might arise in subsequent two years?
If so, then it would sound like an RFC might be useful. Just like we published the original framework RFC without keeping it alive for ever as a regularly-updated I-D.

But if we don't think we can get this stable (perhaps the field is expanding too
fast) then maybe a wiki? 
I don't like a wiki for this because it doesn't register consensus or become more widely visible.

Cheers,
Adrian

_______________________________________________
Pce mailing list
Pce< at >ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: Next steps for draft-farrkingel-pce-questions

Fatai Zhang — 2013-06-14T03:13:11

Hi Adrian,

I prefer an informational RFC, where people can get much valuable information by reading this document quickly. 





Best Regards

Fatai


-----Original Message-----
From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Adrian Farrel
Sent: Friday, June 14, 2013 12:45 AM
To: 'Ramon Casellas'
Cc: pce< at >ietf.org
Subject: Re: [Pce] Next steps for draft-farrkingel-pce-questions

Hi Ramon,

so

I suppose the question might be:
Could we get to a position where we have covered 90% of the questions that might
arise in subsequent two years?
If so, then it would sound like an RFC might be useful. Just like we published
the original framework RFC without keeping it alive for ever as a
regularly-updated I-D.

But if we don't think we can get this stable (perhaps the field is expanding too
fast) then maybe a wiki? 
I don't like a wiki for this because it doesn't register consensus or become
more widely visible.

Cheers,
Adrian

_______________________________________________
Pce mailing list
Pce< at >ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: Next steps for draft-farrkingel-pce-questions

Adrian Farrel — 2013-06-13T16:45:26

Hi Ramon,

so

I suppose the question might be:
Could we get to a position where we have covered 90% of the questions that might
arise in subsequent two years?
If so, then it would sound like an RFC might be useful. Just like we published
the original framework RFC without keeping it alive for ever as a
regularly-updated I-D.

But if we don't think we can get this stable (perhaps the field is expanding too
fast) then maybe a wiki? 
I don't like a wiki for this because it doesn't register consensus or become
more widely visible.

Cheers,
Adrian

Re: Next steps for draft-farrkingel-pce-questions

Ramon Casellas — 2013-06-12T14:35:50

El 12/06/2013 16:27, Adrian Farrel escribió:
Dear Adrian, all,

Just thinking out loud, I don't have (yet) an opinion on this ... I find 
the draft useful, and I wouldn't want it to dissapear but, on the other 
hand, I also think of it as of something "alive" and which could, 
potentially, be updated more-or-less "regularly" depending on the 
working group progress. What would be in this case the best way to 
proceed? refresh it as I-D  -01,02,03... "ad infinitum", publish as RFC 
and then submit -bis -ter if need be, or update it via RFC errata?

thanks, R.

Next steps for draft-farrkingel-pce-questions

Adrian Farrel — 2013-06-12T14:27:04

Hi chairs and working group,

Dan and I are wondering what to do with this draft.

It seems that a number of people have been reading it and have found it useful
or at least stimulating.

At the moment, it represents just the rambling thoughts of two individuals, so
my question is really whether the WG thinks this would be something that could
be usefully published as an RFC or should be judged to have served its purpose
now and allowed to die.

If published as an RFC there would be a number of ways to go forward: adoption
by the WG and subsequent edits; publication of the individual I-D under the care
of the WG (still review and edit, but faster); publication as an individual I-D
(under the care of an AD with review by the PCE working group).

We'd be interested to know what you think before we decide what action to
request for the document.

And, of course, any issues or thoughts on the document would be very welcome.

Thanks,
Adrian

WG Last Call of draft-ietf-pce-vendor-constraints-10

Julien Meuric — 2013-06-12T08:08:49

Hi PCE'rs.

This message ignites a 2-week-long WG last call for 
draft-ietf-pce-vendor-constraints-10. Please send your comments on the 
I-D to the PCE mailing list by Wednesday June 26.

Best regards,

JP & Julien

Re: WG Last Call ofdraft-ietf-pce-pcep-inter-domain-p2mp-procedures

Julien Meuric — 2013-06-11T08:25:44

Hi PCE WG.

This last call ended last week, but I have not seen much comment from 
reviewers. You might still get a chance before IETF last call...

Chairs' review will be sent soon.

Regards,

Julien


Le 21/05/2013 10:42, Julien Meuric a écrit :

Re: I-D Action: draft-ietf-pce-gmpls-aps-req-08.txt

Kenichi Ogaki — 2013-06-10T17:03:00

Dear PCErs,

We uploaded the revised draft which addressed all the comments in IETF last call as follows.

https://www.ietf.org/ibin/c5i?mid=6&rid=49&gid=0&k1=933&k2=69807&tid=1370830337
http://www.ietf.org/mail-archive/web/pce/current/msg03141.html

Thanks,
Kenichi & co-authors

I-D Action: draft-ietf-pce-gmpls-aps-req-08.txt

2013-06-10T17:00:05

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Path Computation Element Working Group of the IETF.

Title           : Requirements for GMPLS applications of PCE
Author(s)       : Tomohiro Otani
                          Kenichi Ogaki
                          Diego Caviglia
                          Fatai Zhang
                          Cyril Margaria
Filename        : draft-ietf-pce-gmpls-aps-req-08.txt
Pages           : 12
Date            : 2013-06-10

Abstract:
   The initial effort of the PCE (Path computation element) WG is
   specifically focused on MPLS.  As a next step, this draft describes
   functional requirements for GMPLS application of PCE.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-gmpls-aps-req

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-gmpls-aps-req-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-gmpls-aps-req-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Re: Xian's comments on draft-ietf-pce-stateful-pce V2

Zhangxian (Xian — 2013-06-08T09:36:22

Hi, Ina,

  Thank you for your reply and update on the draft. Please see my further comments on some of the points inline, starting with “>Xian:”.

  I have additional comments on Version 4, will send them out in a separate email soon.

Regards,
Xian

PS:  I have added the PCE WG mailing list for the benefit of the working group.


From: Ina Minei [mailto:ina< at >juniper.net]
Sent: 2013年4月3日 4:04
To: Zhangxian (Xian); draft-ietf-pce-stateful-pce< at >tools.ietf.org
Cc: Fatai Zhang; Leeyoung
Subject: RE: Xian's comments on draft-ietf-pce-stateful-pce

Xian,

Apologies for the delay in reply, please see responses inline below, look for ###.

From: Zhangxian (Xian) [mailto:zhang.xian< at >huawei.com]
Sent: Wednesday, February 20, 2013 10:57 PM
To: draft-ietf-pce-stateful-pce< at >tools.ietf.org
Cc: Fatai Zhang; Leeyoung
Subject:

Hi, Dear all,

   As promised during last IETF meeting, I have reviewed this draft. The following is my detailed suggestions with provided text for improving the draft as well as a couple of questions I am looking forward to hear from you.

*Suggestions/Comments:

Section 3.2:
o  Allow a PCE to specify protection / restoration settings for all LSPs that have been delegated to it.
Comment: This may be, indeed, a requirement for stateful PCEP extension, but it is not covered in this document as pointed out later in the document. Alternatively, this section can be re-written a bit to make the Objective not confined to this document.

### Yes, good point, will update in the next revision.

Section 5.2:
Since in Section 4, it is clearly stated that stateful capabilities discovery is not in the scope of this document, I would recommend to remove the last two rows of the table presented in this section. Moreover, add a reference to the document which defines so would also be helpful.

### The reference to the discovery draft was added in version 03 in section 4, so I think it is ok to leave the last 2 lines.

Section 5.3:
Old: LSP delegation and LSP update operations defined in this document MAY only be used if both PCEP Speakers set the LSP-UPDATE Flag in the "Stateful Capability" TLV to 'Updates Allowed (U Flag = 1)', otherwise a PCErr with code "Delegation not negotiated" (see Section 8.4) will be generated.
New: LSP delegation and LSP update operations defined in this document MUST only be used if both PCEP Speakers set the LSP-UPDATE-CAPABILITY Flag in the "Stateful PCE Capability" TLV to 'Updates Allowed (U Flag = 1)', otherwise a PCErr with code "Delegation not negotiated" (see Section 8.4) will be generated.
Comment: From Section 7.1.1, the requirement is a MUST not a MAY?

### I don’t agree, here is an explanation. Section 7.1.1 says the capability MUST be advertised by both ends. The extensions MAY be used, not MUST be used. Basically, you can negotiate the capability and then don’t do any delegation or update, and that is ok. If you want to use them, you can, but only if you did the negotiation.  So I think it should be  MAY.

Section 5.4.1：
Old：If a PCC's LSP State Database survived the restart, the PCC will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the last LSP State Database version sent on an LSP State Update from the PCC in the previous PCEP session.
New：If a PCC's LSP State Database survived the restart, the PCC will include the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain the LSP State Database version included in its last LSP State Report sent in the previous PCEP session.

### There was a terminology change from lsp state update to lsp state report in one of the very early versions of this draft, and the text still had a few old references. I have fixed them all now, thank you for pointing them out.

Old: Note that the same State Synchronization sequence would happen if either the PCE or the PCE would not include the LSP-DB-VERSION TLV in their respective Open messages.
New: Note that the same State Synchronization sequence would happen if either the PCE or the PCC would not include the LSP-DB-VERSION TLV in their respective Open messages.

### fixed in version 03

Figure 8: the “LSP State Update” should be changed to “LSP State Report”.

### Thanks for catching, see the explanation above.

Section 5.5:
LSPs are delegated individually - different LSPs may be delegated to different PCEs, and an LSP may be delegated to one or more PCEs.
Comment: To avoid confusion and link this back to Section 3.2, I would suggest to add the following sentence:
However, a LSP is under control of a single PCE at any given time.

### The text is clarified in version 03.

Section 5.5.1:
Old: Delegation acceptance is confirmed when the PCC wishes to update the LSP via the LSP Update Request.  If a PCE does not accept the LSP Delegation, it MUST immediately respond with an empty LSP Update Request which has the Delegate flag set to 0.
New: Delegation acceptance is confirmed when the PCE sends the first LSP Update Request with Delegate flag set to 1. If a PCE does not accept the LSP Delegation, it MUST immediately respond with an empty LSP Update Request which has the Delegate flag set to 0.

### The text is clarified in version 03.


Section 6.2：
Old: An LSP Update Request MUST contain all LSP parameters that a PCC wishes to set for the LSP. A PCC MAY set missing parameters from locally configured defaults.
New: An LSP Update Request MUST contain all LSP parameters that a PCE wishes to set for the LSP. A PCC MAY set missing parameters from locally configured defaults.

### Thanks for catching!

Comments: If a PCC MUST receive all the LSP parameters from the LSP Update Request send from an active stateful PCE, why the second sentence is required?

### Because the PCE may wish to only update bandwidth for example, so everything else (e.g. priorities ) will be set from locally configured defaults.

Section 7.1:
Since multiple TLVs are defined in this section, I suggest moving the only sentence directly under this section to Section 7.1.1. The following is the suggested text (to replace the first paragraph under Section 7.1.1):
Stateful PCE Capability TLV is an optional TLV for the OPEN Object to support stateful PCE capability negotiation. The format of this new TLV is shown in the following figure.

### Thank you for catching

Section 7.1.1.:
Old: if set to 1 by a PCE, the U Flag indicates that the PCE wishes to update LSP parameters.
New: if set to 1 by a PCE, the U Flag indicates that the PCE is capable of updating LSP parameters.

### Will add to version 04.

Questions：
1: I am trying to get a better understanding of LSP delegation and its process. From Figure 13, Step One (LSP state synchronization or add new LSP), do you mean that when a PCC get a service request, it only( and have to) will assign a 20-bit LSP identifier (probably the LSP identifier TLV as well?), and then delegate it to PCE for route selection etc.? If so, it looks to me a bit like replacing PCReq message function here. If I am wrong, please correct me.

### The moment you delegate, you have to assign the identifier. Not sure what you mean by “replacing Pcreq”.

2: In the RBNF definition of PCRpt message, <state-report> ::= <LSP> [<path-list>]. But for a given LSP identified by the 20 bit LSP ID, it matches the <source addr, destination address, tunnel ID, LSP ID> identifier. Then, it should have one <path> descriptor not list. I wonder whether there is any misunderstanding of the concept here?

### There needs to be cleanup in several places in the doc.

3: If a RSVP 16-bit LSP ID change, will the 20-bit LSP ID change? It is not explained in this draft. I suggest adding some sort of explanation since it is important in cases such as re-optimization/re-routing.

### No, the intent was for the PLSP-id not to change. Will evaluate a clarification for version 04.


Best Regards,

Miss Xian ZHANG (Ph.D.)

Research Engineer
Transmission Technology Research Dept.
Network Product Line
Research Area F3-5, Huawei Industrial Base, Bantian, Longgang District, Shenzhen.
518129 , P.R.C.
Tel：+86 0755 28972913

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

Re: Supplementary question on draft-ietf-pce-gmpls-aps-req

Adrian Farrel — 2013-06-07T12:38:47

Hello again,


I think that covers the protection use case for the Association object. And it
would be good to add it to the document.

There are many other uses of the object for associating LSPs with each other.
However, if those use cases are not showing up in PCE requirements at the
moment, that is fine and we do not need to discuss the object any further in the
document.

Thanks,
Adrian

FW: Supplementary question on draft-ietf-pce-gmpls-aps-req

Adrian Farrel — 2013-06-07T12:34:31

Strangely I sent this email to CCAMP not PCE. 

Here is the thread for your information.

Adrian

Re: New version of the stateful pce applicability draft-draft-zhang-pce-stateful-pce-app-04

Zhangxian (Xian — 2013-06-05T01:26:01

Hi, Ravi,

   Thank you very much for the useful suggestions. Please find my reply inline:

Regards,
Xian

From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Ravi Torvi
Sent: 2013年6月5日 0:32
To: adrian< at >olddog.co.uk
Cc: pce< at >ietf.org
Subject: Re: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

Hi Ina & Authors,
Now that we have new WG charter, I think it is a good time to clarify applicability of PCE-Stateful.

Following are some of my observations that can be considered in your next revisions of draft:
1. We need to scope the PCE-Stateful applicability, i.e., clarify explicitly where vanilla PCE can be sufficient or PCE-Stateful could be an overkill.
    - Similarly, it would be nice to describe deployments of Passive Stateful PCE and  with Active Stateful PCE separately
I think draft describes goodness of Stateful well, however, it should provide guidelines for choosing right set of PCE-stateful features.
###: In this version, we did explicitly describe these two different kinds of stateful PCEs in a variety of use cases since they have different capabilities. If you have look at the use cases we have from Section 5, you should be able to find such update. If there are still things missing , please let us know.
###: As for where the stateful PCE is applicable, I think the whole document is trying to say its necessity, I do not see why we need to name examples where it is not needed. However, we do state the pros and cons of stateful PCEs here and there as well as in the use cases so as to make it less advertising as JP suggested in last IETF.

Few basic applications (I am not sure this draft covers them explicitly) from PCC Scale point of view:

2. I think draft should describe on performance w/ PCE-Stateful
    i.e., How PCE Stateful helps in dynamic changes compared to NMS based.
###: In this document, we are comparing with a stateless PCE, not NMS. Why do you think there is such a need to compare with the latter? IMHO,  stateful PCEs are not trying to replace NMS since they have different utilities. Just as you mentioned that stateful PCEs can help with dynamic changes, which I do not think it is what NMS is mainly used for.
3. One obvious applicability of Active PCE-Stateful would be : config scaling. Operators do not have to maintain tons of LSP configuration on the box.
###: I do not get your point, are you comparing NMS-based configuration with stateful PCE-based configuration?
4. LSP monitoring is less expensive with PCE Stateful, as PCE is expected to maintain complete state.
This reduces burden on routers.
###: Again, what entity are you comparing stateful PCE with? Could you elaborate more? I haven’t thought about this before. BTW, this draft works for both MPLS-TE and GMPLS controlled networks. So I wonder when you say “this reduces burden on routers”, do you mean this applications are only possible with MPLS-TE networks?
Thanks,
Ravi


http://www.google.com/profiles/pratiravi

On Sun, Jun 2, 2013 at 11:36 AM, Adrian Farrel <adrian< at >olddog.co.uk<mailto:adrian< at >olddog.co.uk>> wrote:
Ina, WG,

Pleased to see people thinking about applicability and use cases. IMHO, not enough attention is paid to why we are doing things and how they will be used.

Thanks for the work, and hope people will review it (especially service providers!)

Adrian

From: pce-bounces< at >ietf.org<mailto:pce-bounces< at >ietf.org> [mailto:pce-bounces< at >ietf.org<mailto:pce-bounces< at >ietf.org>] On Behalf Of Ina Minei
Sent: 26 May 2013 22:52
To: pce< at >ietf.org<mailto:pce< at >ietf.org>
Subject: [Pce] New version of the stateful pce applicability draft - draft-zhang-pce-stateful-pce-app-04

A new version of the stateful pce applicability draft was posted yesterday.

In the interest of making progress on this document, the authors would like to solicit review, comments and discussion from the working group, before the next IETF meeting.


URL:             http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt
Status:          http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app
Htmlized:        http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-zhang-pce-stateful-pce-app-04


Ina and Xian on behalf of all the authors


_______________________________________________
Pce mailing list
Pce< at >ietf.org<mailto:Pce< at >ietf.org>
https://www.ietf.org/mailman/listinfo/pce

Re: New version of the stateful pce applicability draft -draft-zhang-pce-stateful-pce-app-04

Ravi Torvi — 2013-06-04T16:31:44

Hi Ina & Authors,
Now that we have new WG charter, I think it is a good time to clarify
applicability of PCE-Stateful.

Following are some of my observations that can be considered in your next
revisions of draft:

1. We need to scope the PCE-Stateful applicability, i.e., clarify
explicitly where vanilla PCE can be sufficient or PCE-Stateful could be an
overkill.
    - Similarly, it would be nice to describe deployments of Passive
Stateful PCE and  with Active Stateful PCE separately

I think draft describes goodness of Stateful well, however, it should
provide guidelines for choosing right set of PCE-stateful features.

Few basic applications (I am not sure this draft covers them explicitly)
from PCC Scale point of view:

2. I think draft should describe on performance w/ PCE-Stateful
    i.e., How PCE Stateful helps in dynamic changes compared to NMS based.

3. One obvious applicability of Active PCE-Stateful would be : config
scaling. Operators do not have to maintain tons of LSP configuration on the
box.

4. LSP monitoring is less expensive with PCE Stateful, as PCE is expected
to maintain complete state.
This reduces burden on routers.

Thanks,
Ravi



http://www.google.com/profiles/pratiravi


On Sun, Jun 2, 2013 at 11:36 AM, Adrian Farrel <adrian< at >olddog.co.uk> wrote:

Re: New version of the stateful pce applicability draft -draft-zhang-pce-stateful-pce-app-04

Adrian Farrel — 2013-06-02T15:36:47

Ina, WG,
 
Pleased to see people thinking about applicability and use cases. IMHO, not
enough attention is paid to why we are doing things and how they will be used. 
 
Thanks for the work, and hope people will review it (especially service
providers!)
 
Adrian
 
From: pce-bounces< at >ietf.org [mailto:pce-bounces< at >ietf.org] On Behalf Of Ina Minei
Sent: 26 May 2013 22:52
To: pce< at >ietf.org
Subject: [Pce] New version of the stateful pce applicability draft -
draft-zhang-pce-stateful-pce-app-04
 
A new version of the stateful pce applicability draft was posted yesterday. 
 
In the interest of making progress on this document, the authors would like to
solicit review, comments and discussion from the working group, before the next
IETF meeting. 
 
 
URL:
http://www.ietf.org/internet-drafts/draft-zhang-pce-stateful-pce-app-04.txt
Status:
http://datatracker.ietf.org/doc/draft-zhang-pce-stateful-pce-app
Htmlized:        http://tools.ietf.org/html/draft-zhang-pce-stateful-pce-app-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-zhang-pce-stateful-pce-app-04
 
 
Ina and Xian on behalf of all the authors

Fwd: [CCAMP] 2nd WG Last Call: g709-framework, g709-info-model, ospf-g709v3, signaling-g709v3

Lou Berger — 2013-05-31T16:19:55

Hello,
    The last call just started in CCAMP may be of interest to some in
this WG. Comments and discussion should be directed to the *CCAMP* WG
mailing list.

Much thanks,
Lou
CCAMP WG Co-Chair

-------- Original Message --------
Subject: [CCAMP] 2nd WG Last Call: g709-framework, g709-info-model,
ospf-g709v3, signaling-g709v3
Date: Fri, 31 May 2013 12:11:09 -0400
From: Lou Berger <lberger< at >labn.net>
To: CCAMP <ccamp< at >ietf.org>

This mail begins a 2nd two week working group last call on:

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-12
(Informational)

http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-08
(Informational)

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-06
(Standards Track)

http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-09
(Standards Track)

This working group last call ends on June 16.  Comments should be
sent to the CCAMP mailing list.  Please remember to include the
technical basis for any comments.

Please note that we're still missing an IPR statement on the 2nd
draft.  Any forthcoming publication request will be delayed by late
IPR statements/disclosures.

Thank you,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP< at >ietf.org
https://www.ietf.org/mailman/listinfo/ccamp