IETF-76 PCE Meeting Minutes
Friday November 13th, 2009, 1:00 PM
Agenda
1.1 Administrivia
1.2. WG Status
2.1. Extensions to PCEP
for P2MP LSPs
2.2. PCE-based
Shortest Constrained P2MP Inter-domain TE-LSPs
3.1. PCEP Extension for RWA
3.2. PCEP
Requirements for WSON Impairments
3.3. PCEP
Extension for WSON Signal Compatibility Constraints
3.4.
Requirements for PCE Applied in OTN
4.1.
Determination of a Sequence of Domains in MPLS & GMPLS
4.2. PCE
TED Creation and Maintenance
4.3. A PCE
Application for Pre-configured Routing
5.1. A PCE
Solution for Multi-Layer LSP
Administrivia
Presented by PCE Chair
- JP will not be attending.
- No agenda changes.
1.2. WG Status
Presented by PCE Chair
- Inter-Layer MPLS and GMPLS Traffic
Engineering Applicability Statement document
Julien Meuric: Daniel King volunteered to help with this
draft. Dan, do you have an update?
Daniel King: I have an initial
version ready. I'd like some vendor and operator support on the draft. If
anyone is interested please contact me. Meanwhile I will submit the draft in
the next month and present at IETF 77.
- PCE MIB documents
Julien Meuric: Dan [Daniel King], can you provide an update?
Daniel King: I have been working on
two MIB modules [PCE Discovery and PCE Textual Conventions]. This is work
started by Stephan Emile, who did a very good job, and we are now finalizing
the documents. I have compiled both MIB modules and apart from a few errors the
work is fairly mature. I will clean up the documents and review the functions,
but would urge people to review the documents themselves. I have spoken to a
number of implementers of PCEP and some have their own MIBs. It would be good
for these implementers to provide comments and suggestions for the existing
documents. I hope to have the documents ready for Last Call (and review by a
MIB Dr) before IETF 77.
2.1. Extensions to PCEP
for P2MP LSPs
Presented by Daniel King
No comments or
questions.
2.2. PCE-based Shortest
Constrained P2MP Inter-domain TE-LSPs
Presented by Quintin Zhao
Dajiang
Wang: In the typical WDM ASON, if the primary tree
fails, how can you solve this problem? Do you recompute the whole tree or just
partial part of the tree?
Quintin Zhao: It depends on which
part of the tree fails. We can recompute in individual domains. This allows the
recomputation to be performed in the domain where failure occurred. The entire
core tree in this case will not be recomputed. If we want to recompute the
entire tree, we can avoid the failed areas. In a real deployment you might have
a backup core tree pre-computed so you can switch over in the event of failure.
Dajiang Wang: If the [primary] core
tree is repaired than the tree is
not SPT [shortest path first].
Quintin Zhao: Yes, but if you have a
backup mechanism running in parallel the primary tree is optimal and the backup
is the next best available.
Daniel King: Another scenario for a
failover mechanism is in a domain with fairly fluid traffic and new links being
added. So you may want to reoptimize the primary core tree, this would mean
recomputing a new tree and falling over to the new path if a more optimal path
is found. Additionally, you may want to just reoptimize a single domain rather
than the entire core tree. These are the discussion we would like to have with
users of the technology, how static are these services, do you expect to
reoptimize, how often/when, optimization of the entire tree or sub-path, etc.
Quintin Zhao: Good point. It is costly to have backup traffic
running simultaneously. As Dan [Daniel King] mentioned we can also optimize
full or partial parts of the tree and make-before-break [in order to switch to
the new core tree] so we do not impact traffic.
Xihua Fu: In optical
networks the recovery time for failure is very strict, if the core tree fails.
You have to recover the core tree quickly; I suggest there should be
considerations to cover recovery in the solution.
Quintin Zhao: Some good comments. We
should update the draft to add some details on improving recovering time.
Daniel King: It's also probably
worth considering that these applications [large, multi-domain P2MP service
paths] are generally planned days or weeks in advance. As are any protection
paths, that may include a back up path that is link and node disjoint.
Real-time requirements for tree computation are limited, unless there is a
catastrophic failure in the network and completely new sub-path or entire core
is computed.
Julien Meuric: It would be good to
continue these types of discussions on the list. The authors have also managed
to merge two drafts so let's support them and provide feedback.
3.1. PCEP Extension for
RWA
Presented by Young Lee
Julien Meuric: Young Lee has a request for comments; please send these to the mailing list.
3.2. PCEP Requirements
for WSON Impairments
Presented by Greg Bernstein
Greg Bernstein: This document is aligned with the CCAMP work.
Julien Meuric: We had the meeting with CCAMP so
it's good to have the companion document with PCE. However you mentioned the
document is aligned with the CCAMP work, but I remember in the CCAMP work there
are some scenarios with multiple PCEs communicating. I am not sure if those
scenarios are included in this document.
Greg Bernstein: Those detailed
scenarios are subject to standardization. The core material has general agreement.
The detailed piece, grouped into same interface, etc. We just wanted to
simplify things.
Julien Meuric: We need alignment.
Greg Bernstein: We took what was
going to stay. We did not want to include things in this document that might
change.
Julien Meuric: We just need to keep
aligned as much as possible. Maybe have pointers from the CCAMP document to the
PCE document.
Pierre Peloso: A suggestion for
Section 4 of the GMPLS and PCE Framework draft in CCAMP, could be moved into
this document. It makes more sense that’s it's in the PCE working group than
CCAMP working group. I also have another question to the authors regarding
equipment vendors that do not want to share impairment features.
Greg Bernstein: To clarify, this
refers to the fact that the ITU-T has not standardized certain concepts,
including "black links". For us, this is a sub-link where information
details are not shared.
Pierre Peloso: My understanding of
"black links" means that it’s not necessary to get into a situation
of impairment computation. I am also taken aback by the use of "impairment
validation", I think a better name could be used.
Greg Bernstein: We are always open
to suggestions.
Pierre Peloso: Regarding equipment
vendor's unwillingness to share impairment information. I think vendors may
have intellectual property that they may not want to share. I think the
physical capabilities are not an issue and can be exchanged.
Greg Bernstein: This is work in
progress. Making the document a working group item does not mean it's completed.
It just opens up the decisions and makes it easier to discuss the work with
other standards organizations.
Dajiang Wang: If in the combined PCE
and RWA is used, should the TLV with parameters be flooded?
Greg Bernstein: We just received
some clarification and temporary documentation from the ITU that discussed
"black link" concepts. So when we are scoping "black
links", in the diagram, combined optimization, RWA, impairment validation,
the more info you have the better for optimization. In reality you may break up
the pieces. Sharing impairment parameters (both ITU and no ITU) via routing
protocols, that’s the direction things are headed.
Pierre Peloso: I would say in the
general point of view, you still do not discuss the parameters. You want to
compute the parameters to verify the feasibility of the path.
Greg Bernstein: The feasibility of
the path parameters is happening in CCAMP.
Pierre Peloso: For the parameters to
be usable, they have to support cascading.
Greg Bernstein: That’s more an ITU
item. You will find this in G.680 coming up in the ITU. ITU defines these
things. When I talk abstractly it's because that's in the scope of CCAMP,
things like what parameters can be cascaded, we do not touch that here.
Julien Meuric: Except that they need
to be specified for PCEP. So you need to discuss them.
Greg Bernstein: Yes. Except that the
parameters do not affect the interface. The actual impact to PCE is not that
big.
Young Lee: We do not discuss data
dissemination. We assume some data is available already via IGP or some other
method. Some parameters can be cascaded, others cannot be cascaded. This comes
down to algorithm paradigm. You need to come up scheme for estimation, but
that’s out of scope. What Greg is discussing is what communication is needed to
convey information for the PCE to compute. I'd like to make that point clear.
Julien Meuric: To progress you need
discuss this on the list to see if there is interest. Try to keep constancy
with CCAMP. Maybe we move items from the CCAMP framework to here.
3.3. PCEP Extension for
WSON Signal Compatibility Constraints
Presented by Young Lee
Julien
Meuric: The CCAMP working group poll in the room
was positive. They need to take to the list before adoption. It makes sense to
wait for CCAMP. If it's accepted then we can pose the question here. We can
still continue to discuss the work, even as an individual submission. It will
ease the way for polling the PCE working group when relevant.
Eve Varma: In CCAMP there is going
to be the integration of the work. In the spirit of doing a similar approach I
assume the same thing will happen.
Julien Meuric: Yes.
3.4. Requirements for PCE
Applied in OTN
Presented by Fei Zhang
Eve
Varma: Can you go back to Scenario 1. I wanted to
point things like pre-FEC, these are items discussed in ITU. There is not
agreement [in the ITU] that there is utility on this. I think data plane
orientated items should be sent over to the ITU. If it's decided something is
useful then we can discuss it here. I happen to know that this particular item
was subject to multiple discussions and was not something that was agreed.
Julien Meuric: You seem to be using
OTN as generic name for optical networks. There is clear overlap with WSON work
so I suggest you discuss with other authors how you can work together.
4.1. Determination of a
Sequence of Domains in MPLS & GMPLS
Presented by Daniel King
- Techniques avalable to compute
inter-domain paths
Kam
Lam: In the event of several NMS systems you can
compute an inter-domain path.
Daniel King: You can stitch domains
together and manually connect them. In this case we are looking at a scenario
where the source can request an end-to-end path across multiple domains. Two
techniques also exist [Per Domain and BRPC]. Take your point that an NMS based
solution is also applicable [when computing inter-domain paths].
Eve Varma: This sounds a little like
Call Routing.
Adrian Farrel: Yes it does sound
similar. There are some differences. When routing a call you select the call
controllers. When you route the call you are not selecting the domain
interconnection points. A simple example would be two adjacent domains with two
interconnection links. You need to select which interconnection use. There is
some call routing similarities in this [H-PCE], but it's not limited to call
routing.
Daniel King: We do specifically discuss in the document the applicability
to various applications. In essence any environment with sub domains that are
interconnected with links might be a candidate.
- H-PCE Applicability to ASON
Eve Varma: The work that stimulated G.7715.2 was making sure that a PCE approach could fit. So it's not a coincidence that this [H-PCE] fits the ASON model, it was done deliberately.
- In summary / Questions
Dan
Li: This is perhaps a clarification. Can BGP be
involved to gather the inter-domain information?
Daniel King: Yes, the PCE may be
able to use a variety of methods to learn about its neighbor/inter-domain
connectivity.
Dan Li: You mentioned that the work
is within charter. Does this mean the current solution does not consider
stateful?
Julien Meuric: I think the work is
within the charter, however, seeing as we are discussing the charter, it's
worth waiting for charter feedback and working group discussions.
Richard Gray: I looked at the requirements for authentication and
confidentiality. It seems to have a basis that requires an adequate naming
scheme, so you know what you are
authenticating. Is that available?
Daniel King: The draft is
work-in-progress, it's going to be a requirement we just have not documented
the details.
Richard Gray: I think it’s a good
place to start.
Daniel King: Great, perhaps you
might be interested in providing some text.
Richard Gray: Sure.
4.2. PCE TED Creation
and Maintenance
Presented by Greg Bernstein
- Applicability for PCE TED to H-PCE
Adrian
Farrel: There is a small flow of information.
"Hello, I am here" for instance.
Greg Bernstein: What about
interconnection information.
Adrian Farrel: There are requests
and responses. PCEP between the [P-PCE] child and parent is not substantially
changed. It's important to not be sharing topology information.
Greg Bernstein: Not the border info?
Adrian Farrel: Yes, that info is
shared [between the child and parent PCE].
Daniel King: An objective in H-PCE
was to maintain domain confidentiality, so we would not share internal domain
topologies. There are going to be multiple interconnection points. So these do
need to be sent to the H-PCE so it can apply policy and select the preferred
interconnection for the end-to-end path.
Greg Bernstein: So in essence, you
do no need to send information. Not as much as we might send.
Daniel King: Yes, I'd expect 10s of
interconnections, perhaps not 100s or 1000s.
- In summary / Next Steps
Greg Bernstein: So, we need to know if we should or should not move this
work forward.
Julien Meuric: The chairs of CCMAP confirmed there is no blocking issue
from the CCAMP perspective. The concern was not that you were going break
GMPLS; more of a concern is the use of the IGP. When I reviewed the draft I
think most of the features discussed can be fulfilled by using the existing
IGP. If you want to do something that’s not currently performed by the IGP you
need to point to what is missing.
Greg Bernstein: The issue is not
what the IGP cannot do. It's more, what you do not want to use it for. Most
folks in the optical space are limited by management bandwidth.
Julien Meuric: Perhaps in SDH but on
WDM systems the signaling channels can be much bigger than SDH DCCs.
Greg Bernstein: Scaling may be an
issue if you just put everything thru there [management pipe].
Julien Meuric: Sometimes it's not
the control plane that has the issue. It may be a management plane scaling
issue.
David [missed last name]: It’s a
scaling issue. We need to decide what scale of network should we support and
how often it should it update.
Eve Varma: I was going to mention it
depends on how much information you decide you need to flood. Is this
information you don’t need to update regularly. I think this is a factor as
well.
Pierre Peloso: It's also related to
how you relay information via the IGP, if you're able to relay it differently
static versus dynamic. We have not finished this work with the IGP, and then
this is a very specific direction to take. We may need to make a choice. Do we
want WSON to have a solution that’s only applicable with a PCE, or do we want
an IGP that is able to achieve the routing function of WSON?
Young Lee: It does not matter if
it’s dynamic to static, we are talking about the function of events. If
something breaks, the situation becomes dynamic. A failure situation would
require the flooding of information as well.
Greg Bernstein: We have worked on
this draft for two years. We would like to ask that we poll the list [to
request working group status]. If the answer no then we can drop the work.
Julien Meuric: Scaling issues aside,
I would like to see some more detail. Where are you going, what do you want to
standardize?
Greg Bernstein: The draft indicates
three distinct areas for potential standardisation. It discusses the concepts
and interfaces for standardisation.
Julien Meuric: It's not clear that
this fits the PCE working group. It may be an IGP working group, perhaps
another area or even a BOF. The solution needs to be clearer so we can decide
if its fits the PCE working group or not. It's not obvious from the current
draft.
Young Lee: Just for clarification.
What you describe is in the PCE architecture document.
Julien Meuric: The PCE architecture
allows that the TE is populated by something else, but it's not within the
charter to define all the means that could be used. For instance the IGP is
defined in the OSPF and IS-IS working groups.
Young Lee: I think PCE is the most
viable working group.
Greg Bernstein: We need to decided
if the work should progress or not.
Martin Vigoureux: I rapidly read the
draft. I understand that one aspect of the work is using an IGP to flood all
the necessary information might slow things down.
Greg Bernstein: In OSPF we share all
the info with all the nodes, in this solution, we share a subset of information
specifically based on what's needed by specific nodes. It’s the PCE that needs
the info, which is why we are talking about this in the PCE working group. We
are not inventing a new routing protocol.
Martin Vigoureux: The information
can come from every node, or a subset of nodes?
Greg Bernstein: Yes.
Martin Vigoureux: Why is some
information only available on specific nodes?
Greg Bernstein: Some nodes are aware
of specific link or capabilities like connectivity matrix, wavelength
constraints, and convertor pools. The initial motivation stems from WSON. Nodes
perform a self inventory and can understand the resources it has and that
information can be exported.
Martin Vigoureux: I am concerned with
opening the door and feeding proprietary information using that mechanism.
Greg Bernstein: We encourage standardisation and want to provide hooks for
vendor information.
Julien Meuric: It's not clear how
much.
Adrian Farrel: With my AD hat on,
let me help. [To Greg] What are you trying to standardize. Are you looking to
standardize a general framework? Are you looking to standardize protocols,
format and content of information that’s distributed? This is the information
Julien needs, so he knows where this is going.
Greg Bernstein: The encoding and
format information is maturing in CCAMP. So the information that would flow is
being standardized in CCAMP. The interface of how you get that information into
a PCE is what we are intending.
Adrian Farrel: What do you want to
do, you’re writing code?
Greg Bernstein: I would use a
familiar protocol. The work would cover the protocol interface and what gets
sent. We want to reuse protocols, and add messages.
Pierre Peloso: I am not comfortable
with a model that only floods information to the PCE. So this information won't
be flooded to all these nodes, just the PCE? So only the PCE would be able to
compute RWA?
Greg Bernstein: That is an
implementation choice. PCE is the general concept. Every node can have a PCE.
If you are trying to do optimization, or specialized computations, then this
PCE may require the information we are talking about. Only a few might have the
capability.
Pierre Peloso: What do you mean by
optimization? PCE offers high level path computation.
Julien Meuric: If you want to
propose something, you need define where the protocol is and which protocol you
are specifying. What’s behind the function?
Greg Bernstein: A protocol. It could
look like PCEP, with some extra information and messages.
Julien Meuric: Why not document this
and submit it? It would have details.
Greg Bernstein: We started these two
years ago with the requirements document that indicated the concepts, and how
it fits into the general role of PCE. We had interest and discussions on the
list but I think the chairs are opposed to the work.
Julien Meuric: We cannot poll the
group today, we have too few people.
Eve Varma: It sounds like there a
few conversations; one conversation would be is there some utility for the PCE
to do this? A second conversation is this the best and only way to do this?
Greg Bernstein: The first the time
we discussed this work it was clear that this is not the only way.
Eve Varma: The third conversation is
how much information is going to be circulated. What information is end-to-end
and what is local? How much information needs to be flooded, this is relative
to the scalability discussion.
Greg Bernstein: I would think that
is a network design. What information needs to be sent to all nodes and what
should be sent to a single or multiple PCEs?
Julien Meuric: We need further
clarification if you want to move the work forward. We need discussion on list.
Greg Bernstein: I think we have done
every clarification the chairs have asked. I really want to poll the working
group.
Julien Meuric: From what we have
heard. I do not feel we have consensus.
Greg Bernstein. To get consensus we
can poll the list. If there no interest we can drop the work.
Julien Meuric: Discussion on the list has been limited as well.
Greg Bernstein: We had a lot of
discussion on the list bit no one polled the list. The first version of this
document had solutions. Let’s poll the group, if no one wants to do the work
then we can drop it. We just want a decision.
Julien Meuric: Ok my decision is trigger
discussions on the list with people other than the authors.
Greg Bernstein: Ok I am asking on
the record that I asked for the work to be polled.
Daniel King: Duly noted.
4.3. A PCE Application
for Pre-configured Routing
Presented by Yuanlin Bao
Julien Meuric: Please send comments
and questions to the list.
5.1. A PCE Solution
for Multi-Layer LSP
Presented by Xihua Fu
Julien Meuric: This presentation was proposed in ccamp. There are some actions from CCAMP to split the work. Do you want to present? We only have 2 minutes.
Speaker: Yes.
Julien Meuric: Please give feedback on mailing. You [Xihua Fu] may want to present two drafts next time, one signaling draft in CCAMP, and one PCE draft.
6. PCE Working Group Charter
Julien Meuric: We are out of time. No time for charter discussions. Let's continue discussions on the mailing list.