IETF 77
CCAMP First Session
Monday, March 22, 2010. 1300-1500 Afternoon Session I
1 - WG status, RFCs, drafts, milestones, charter, errata
Presenter: Chairs
- RFC Editors Queue. A number of documents recently became RFCs (see
slides).
- Co-chairs are
looking for assistance on draft-ietf-ccamp-gmpls-ted-mib.
The document needs to be updated based on the
- draft-ietf-ccamp-wson-impairments
Lou Berger: What's the status of this [draft-ietf-ccamp-wson-impairments] document?
Greg Bernstein: No updates.
- draft-ietf-ccamp-mpls-tp-control-plane-framework has been published as a WG document. It is joint work with the PWE WG. The document will be presented in the MPLS-TP joint session as it is joint work..
- Ethernet
provider requirements document is going to be abandoned for lack of interest.
Lyndon Ong: A question on MPLS-TP
document. This document is going to be discussed in the MPLS session this
meeting? Is it coming back to this group at some point?
Lou Berger: The second MPLS session is joint
work. So it will be discussed in the joint session.
- ITU Liaisons: The co-chairs plan to answer these before the June
Plenary.
- Charter updated per last meeting. The new text has been recently posted.
- Thank you to Ross Callon who is moving from the IESG to IAB
- RSVP related discussion to take place in the TSV AREA session
2 - ITU-T and OIF
progress report
Presenter: Lyndon Ong
- OIF Status Update. In addition to the notes on the slides there are
some active OAM projects as well as security in the control-plan.
Lou Berger: How do you foresee the OIF’s work related
to the IETF OAM work?
Lyndon Ong: The OAM work in the OIF is a broad range of possible issues
with input from carriers. Feedback for protocol specification could be done
here. It will be mainly broader issues, processes and flows. If new work is
identified it will be liaised here.
Lou Berger: If you do discover issues and requirements that are not
covered with existing work, we would be interested to see them.
Nurit Sprecher: Clarification for G709 extensions for PCE extensions. Is
it really PCE extensions or OTN extensions?
Lyndon Ong: I was referring to the new extensions in G709.
- Questions and comments.
Lou Berger: We expect the G709 documents being discussed
tomorrow [CCAMP Session 2] will need to address the technical issues raised in
the received liaisons.
3 - Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)
Presenter: Young Lee
Lou Berger: How many people have looked at this
document?
(A very good number)
Lou Berger: Anyone have reservations?
(None)
Lou Berger: Any feeling that it’s time to move forward?
(A notable number but not as many who read document)
Lou Berger: Not as many who read the document? Would
anyone care to talk about why they feel the document should not move forward?
(No response)
Lou Berger: So I am not seeing any reservations on the document. We
should take it to the list for moving document forward. One
minor point to the authors. An additional constraint mentioned in a
document later today is "Adjacent Lambda Constraints" [10 - OSPF Link
Information Model for OSPF], how do you see
this fitting into the framework? Do we need to update the framework, or leave
it outside the document?
Young Lee: We would like to see the discussion later today.
Lou Berger: I would like to request an offline or on list discussions as
to how that particular constraint should be handled. You need to address it or
leave it out, before we last call this document.
4 - Routing and
Wavelength Assignment Information Model for Wavelength Switched Optical
Networks
Presenter: Young Lee
- Questions and comments.
Lou Berger: We should complete the generic encoding
discussions.
Young Lee: Ok.
5 - Routing and
Wavelength Assignment Information Encoding for Wavelength Switched Optical
Networks
Presenter: Greg Bernstein
- Questions and comments.
Igor Bryskin: Do you plan to address ROADM
directionless technology [resources that are available from several links]?
Greg Bernstein: Sounds like this would be an additional constraint.
Igor Bryskin: During discussions with clients we had identified a
problem where we had to address how to use protection path computation where it
can only be used on one degree or another. It would be nice if your framework
and model included this technology.
Lou Berger: Are those transponders being used for client signals or for
regen?
Igor Bryskin: It could be a fixed regenerator or tunable, or client
transponders.
Lou Berger:
The regenerator pool sounds similar to what you are discussing, but without
clients.
Igor Bryskin: The regenerator pools are a separate discussion.
Greg Bernstein: We need diagrams and an email to the list and we can
discuss.
Igor Bryskin: Ok. When people discuss colorless, they also mean
directionless.
6 - General Network
Element Constraint Encoding for GMPLS Controlled Networks
Presenter: Greg Bernstein
- Questions and comments.
Greg Bernstein: Should we expand this to cover other
technologies. Right now examples are from WSON.
Lou Berger: I’d like to see how many have read the document.
(Some)
Lou Berger: Of those that have read this document do you think this is a
good direction to be taking? Should we keep this as WSON specific, or widen the
applicability. Previously we have tried to generalize control plane
technologies.
Igor Bryskin: I believe this is purely WSON. [Routing and Wavelength
Assignment Information Encoding for Wavelength Switched Optical Networks].
Greg Bernstein: Those parts are in the presented WSON
specific draft.
Igor Bryskin: I can offer my opinion on General
Network Constraints. They may occur in multiple layers, but I still say this is
WSON specific.
Young Lee: I agree with Igor [Bryskin], but also
the direction was initiated by [CCAMP] WG chairs. Certain things only apply to
WSON so I prefer to stay on this direction.
Lou Berger: Sorry, which direction? Keep the document with the generic
encoding, or go back to WSON specific encoding.
Young Lee: Some can be applied to other technologies, but when we say
WSON specific, we mean resource level, regen, compatibility which may not be
applied to other technologies.
Lou Berger: So you support the current technology breakout.
Young Lee: Yes.
Lou Berger: I think it would be worthwhile if we had
other technology examples. If anyone has a technology that they would like to
see applied would they be interested in contributing to this work?
(No takers)
Lou Berger: We have some support for both directions. The chairs and
authors need to discuss this.
Igor Bryskin: When discussing WSON. When we discuss how to build
cross-connects these have to be expressed in terms of lambdas. All other
technologies may be a very different thing. Our experience in binding lambdas
together is different from say multiple Ethernet links.
7 - OSPF Enhancement
for Signal and Network Element Compatibility for WSON
Presenter: Greg Bernstein
- Questions and comments.
Lou Berger: It's worth reducing the number of
independent drafts and try to match them to other
work. It would be very beneficial to combine drafts wherever possible rather
than have many drafts, none of which standalone. We will need to resolve
disconnects and overlaps [adjacency constraints] this does not change the high
level objective or merge of the drafts as much as possible.
8 - Signaling Extensions
for Wavelength Switched Optical Networks
Presenter: Greg Bernstein
- Questions and comments.
Igor Bryskin: [Signal Attributes Slide] What do you gain by signaling this information? This
information needs to be considered during routing and traffic engineering. If a
node doesn't like its FEC type or signal type it rejects. What can you do next?
You will have to constrain your path computation and exclude this specific
node. My point is this is needed in the routing but not the signaling.
Greg Bernstein: Yes, but what happens when your
configuring equipment and your configuring pools of resources, and at a
specific node you would like to specify the configuration?
Igor Bryskin: This signal type will work when your network is fine. Why
do we need this? During initial path computation this can be done.
Greg Bernstein: We need this because once you change a parameter in
flight and you may want to specify where regeneration can occur. You may want
to indicate a modulator that supports two different modulation formats. Once
you change any parameter in flight [during signaling] we assume the bit rate
has to the stay the same, or the modulation stays the same.
Igor Bryskin: When you signal the path does the ERO contain the
lambdas?
Greg Bernstein: We have distributed wavelength assignment or PCE
(centralized) wavelength assignment. Neither of these affects the issue
regeneration.
Igor Bryskin: I have a problem seeing the value signaling these parameters.
Greg Bernstein: Ok.
Lou Berger: We have two separate discussions in your draft. It's
important to make sure that any mechanism is in sync with our discussions
tomorrow [CCAMP Session 2]. The document also discusses bidirectional issues
this has not been discussed in a while. It would be good to have more discussion
on this area. Especially to make sure that people agree to the changes proposed
in this context.
Greg Bernstein: Ok.
Pierre Peloso: In a previous version of this draft there used to be a
wavelength metric. This has disappeared. Why?
Greg Bernstein: We discussed previously that RWA algorithms were too
experimental.
Pierre Peloso: I understand this. The wavelength metric could be used by
an algorithm but the document does not have to discuss an algorithm.
Greg Bernstein: If we were to do something like that I think it would be
more appropriate to do it in another draft. Putting a metric in a signaling
protocol is not what I am used to.
Lou Berger: Propose text to the list and discuss there.
Pierre Peloso: I will propose text.
Presenter: Fatai Zhang
- Questions and Comments.
- Request that this document becomes WG document.
Lou Berger: As discussed earlier I think it would be
worthwhile to converge on documents that match
our information encoding. So we should have one information encoding for WSON
and one document for [WSON] routing. If we have a generic encoding document we
need the generic OSPF routing document. We do not want to have multiple
documents that do not support themselves. Please look at merging work that
mirrors the encoding document
Young Lee: A third alternative. If we stay with two separate encoding
documents we could avoid separating the OSPF document and have one OSPF
document that points to two encoding documents.
Lou Berger: The problem is with any future non-WSON technology that
wants to use that general encoding information. They will need to reference
WSON technology to non-WSON implementations.
Young Lee: In respects to OSPF that’s fine.
Lou Berger: An example from the TDM world. You would not want the SONET
gear to reference a WSON specification. It's better to have stand-alone
documents just from a conformance perspective.
Young Lee: Either way is fine.
Lou Berger: Yes, just do not want to have conformance issues in the long
term.
10 - OSPF Link
Information Model for OSPF
Presenter: Dirk Schroetter
Igor Bryskin: Are we discussing pools of regenerators. How is this
advertised? Per node or per link.
Giovanni Martinelli: This info applies per node.
Igor Bryskin: What if a regenerator is available from a single link or
subset of links? How would this be advertised?
Giovanni Martinelli: This constraint should be general OSPF
information.
Igor Bryskin: Pools of regenerator are advertised per node.
Giovanni Martinelli: This document describes more detailed
link information.
Greg Bernstein: The way I see this. This allows us to look at sub-sets
of wavelengths to work with those as sub-links? This could be helpful. This is
useful to see what restrictions we have, what modulations, etc. Is this something
that should be included in info model and encoding drafts or separate them?
Giovanni Martinelli: Good question.
Lou Berger: Seems you are covering two issues. First comment, by
optimizing particular pieces of information and by introducing a sub link you
gain some optimization. Is this a correct characterization?
Giovanni Martinelli: Not really an optimization but a better
description of the link
Lou Berger: Can this not be achieved with the current information model?
Giovanni Martinelli: No.
Lou Berger: Second comment. You have the new info; we have a better way
of describing info. Should this new info not be brought into the document?
Giovanni Martinelli: Basically, yes.
Lou Berger: Is this new information [Adjacent Channel] something that
should be brought into the general info document?
Greg Bernstein: I saw there was an admin grouping
Lou Berger: By grouping information you're optimizing. The document is
also introducing new information. Does this become elevated to the framework
and then is filtered down?
Greg Bernstein: It may not need to go all the way up to the framework
but it should be in the info model.
Giovanni Martinelli: On the framework there are other comments from Igor.
Lou Berger: I think this could go either way. In your next update
include how you are addressing this. We can then discuss this on the list.
11 - OSPF Extensions
in support of O-E-O pools in GMPLS controlled all-optical networks
Presenter: Pierre Peloso
Igor Bryskin: You want to advertise in a single LSA
all constraints.
Pierre Peloso: There are three LSA’s, one for node (spectral etc.).
Igor Bryskin: Each of them is separate TLV. We found it quite
problematic to split link info across several LSA’s. Have you made an
evaluation on using this on existing equipment and the affect on LSA size?
Pierre Peloso: For instance you are just updating OEO resources. (See
Slide LSA describing OEO resources). These are fixed sizes, dependent on your
pool.
Igor Bryskin: Well let's say you have a potential 80 channels what are
the binding constraints and LSA size. Maybe you should have an appendix with
examples?
Pierre Peloso: I would defer to Greg Bernstein. I am using his encoding
descriptions.
Lou Berger: Before you do that we are out of time for this draft. I
suggest you take this to the list. It might be useful to have examples in an
appendix. Also same comment as before, please see how this work can be merged
into existing documents as we do not want to have multiple drafts on the same
topic.
12 - OAM Configuration Framework and Technology Spec Extensions
Presenter: Attila Takacs
Lou Berger: Fist point, the usage of 2119 conformance
language. Please try to stay consistent. The second point, the framework
document title. Maybe it's more than a framework, maybe "General OAM using
RSVP-TE".
Curtis Villamizar: I agree it should be a base spec really, as opposed to a
framework document. Also the attribute bits are in short supply. It would be
better to put these somewhere else. If you ever want
to address a MIP, it might be better to put some of this info in an ERO to
identify a specific MIP. It would also be useful to set a loopback as per our
recent email.
Attila Takacs: The bit addressing is
being discussed. Perhaps by having a field where you can add this info.
Lou Berger: The discussion is where the object lives, not necessarily if
the function is there.
13 - RSVP-TE
Extensions for MPLS-TP OAM Configuration
Presenter: Elisa Bellagamba
Nurit Sprecher: Is this version three?
Elisa Bellagamba: This is version two.
Lou Berger: Any other comments? No? Time to adjourn, will
reconvene tomorrow.
IETF 77
CCAMP Second Session
Tuesday, March 23, 2010. 0900-1130 Morning Session I
14 - Framework
for GMPLS and PCE Control of G.709 Optical Transport Networks
Presenter: Fatai Zhang
- Questions and comments?
Igor
Bryskin: I think this
is a useful draft for implementers and operators. It would be good for the
routing considerations. For instance you can create hierarchies, FAs, encoding
types, etc. That would be useful.
Fatai Zhang: This is described in this draft; we just do not list them
in these slides. The framework document describes those requirements from a
high-level.
Igor Bryskin: We are looking to implement this as our part of a multilayer
control plane. I was looking for a switching type for hierarchies that are
advertised. It would be nice to have these defined.
Lou Berger: An example of that is in the Ethernet framework document. We
did not define specific values this happened in the solutions documents. The
intent and use was defined in the framework so I think the comment [from Igor]
is valid.
Fatai Zhang: We can do this.
Lou Berger: Igor, independent of the comment is this a good foundation
for the WG activity?
Igor Bryskin: Yes.Biao Lu: I did
not see this document mention OTN multi-level muxing. In terms of multilayer
forwarding, I would suggest that this should cover multilayer hierarchies as
well.
Fatai Zhang: We have cases for multilayer. For example if we look at ODU
1, 2, 3 at multilayer. They are multilayer. At the moment we look at the single
ODU layer. For multilayer we use this existing technology.
Biao Lu: I suggest you mention
this in the document.
Fatai Zhang: This is mentioned in the document.
Biao Lu: I didn’t see it, maybe I missed it.
Malcolm Betts: I support this draft it’s a good base for moving forward
and I support it becoming a WG document. The work in the ITU is keeping pace so
it's completely appropriate at this time. On the multilayer, as Igor [Bryskin]
mentioned, some application examples / use cases would useful.
Lou Berger: That’s correct; the muxing issue would also be addressed
with Igor's [Bryskin] comments.
Deborah Brungard: How many have read this draft?
(Quite a few)
Deborah Brungard: How many people would support this becoming a WG
document?
(Similar number)
Deborah Brungard: Good response, we will take to list for WG status.
Lou Berger: Are the liaisons that came in from the ITU addressed?
Malcolm Betts: Answering my liaison, I think it's pretty much addressed.
That's one reason why I would like to see this document become a WG document so
we could have a formal liaison to make sure we stay aligned and do not drift.
Lou Berger: Do we liaise the 00 version of the
WG document, or the 01 version that addresses the outstanding liaisons?
Malcolm Betts: We do not see open issues. Look at liaison if you see
something let us know and we will try to respond.
Lou Berger: Well with your co-author hat on, can you review your liaison
and see if there are still any holes?
Malcolm Betts: Yes.
Presenter: Fatai Zhang
- Questions and comments?
Lou Berger: Good comments on the previous document [14 - Framework
for GMPLS and PCE Control of G.709 Optical Transport Networks]. Can anyone comment on this, is this a good document to continue
activities within the working group on this area? How many people have read the
document?
(a few)
Lou Berger: Definitely a much smaller showing [than the previous
document]. Perhaps we need to address the issue raised at the framework level
first. This can translate into technical changes at this level. I agree with
previous comments that there will be some changes, including switching types.
Hopefully we will have more people review and we can look at making this a WG
document after the next version.
16 -
Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of
Evolutive G.709 OTN Network
Presenter: Daniele Ceccarelli
- No questions
or comments.
Lou Berger: We look forward to the next version.
This is good progress.
Presenter: Daniele Ceccarelli
- Questions and comments?
Jonathan
Sadler: I see your
referencing the appendix of G.7714.1. The CCAMP document that it was based on
in the past, the bootstrap draft, never made it to completion. Is there an
expectation that that it will be revived?
Daniele Ceccarelli: Yes.
Deborah Brungard: How many have read this draft?
(Not too many)
Deborah Brungard: I encourage people to read the draft.
Lou Berger: It’s good to see the next technical steps mentioned [see
slide 8].
18 – LSP Data
Path Delay Metric in Generalized MPLS-TE Networks
Presenter: Guoying Zhang
- Questions and comments?
Adrian
Farrel:
draft-shiomoto-ccamp-switch-programming is in limbo. It was informational; we
did not say anything that was not already in existing RFCs. It seemed that
people were not extracting the information correctly from existing RFCs. We are
not quite sure what to do with it. No significant mailing list comments. We
would like to know from the chairs and WG what they would like us to do. Maybe
we could cut and paste our work into your document.
Lou Berger: A cut and paste concerns me a little. If we make this
document a proposed standard I'm not sure that your document, which is
informational, fits inside this document.
Adrian Farrel: I see three options [for
draft-shiomoto-ccamp-switch-programming]. 1 Kill it. 2 Make
WG draft. 3 Progress as an independent RFC.
Lou Berger: Does anyone have an opinion on this? Would anyone like to
voice support for these options mentioned by
(no comments)
Lou Berger: This is the issue with the [switch-programming] document,
i.e., lack of support. Let's try again and see if we can make it an
informational document. If that fails option 3 is better than option 1.
Curtis Villamizar: [On the presentation:] The motivation for signaling
back a RESV before having the hardware signaled [with multiple hops] is the
delay to get all the signaling completed, which is proportional to the delay by
N of hops. The root cause of this is that the signaling is not separated from
indication that the hardware that is set up. If we go back almost 10 years we
had a draft that indicated the path as the signaling was being performed,
without actual setup. That way the ingress would know that the hardware setup
along the entire path has been completed, other than trying to indicate what
you're expected your delay was and when you were done. Maybe we should revise
this work instead of trying to estimate the delay.
Lou Berger: There are two separate topics. First, is
it okay to signal before your hardware is there?
Curtis Villamizar: I am suggesting a protocol extension
that allows you to do this if the ingress understands the signaling.
Lou Berger: That would be an interesting piece of work. The work being
presented here is really something along the lines of what you would see from a
benchmarking group. Except that here we are benchmarking the relationship of
control plane and data plane. This is something suitable for the lab. The chairs think this is important for the WG, and was requested
to progress DPPM work, and being able to correlate the control plane
transactions to the data plane. This was motivated from a request from the
chairs. Is there a feeling that the work should be progressed as a WG product?
(Not many)
Lou Berger: How many have read this document?
(Not many)
The document is not getting a lot of attention. We will talk offline to discuss
how to progress this document.
19 – GMPLS
RSVP-TE Recovery Extension for data plane initiated reversion
Presenter: Attila Takacs
- Questions and comments?
- Request WG document.
Lou Berger: Who has read this document?
(A few)
Lou Berger: It seems a little light to take on a WG document. Of those
that read the document do you think this is a good start?
(Same number of hands that read the document)
Loa Anderson: if you poll this document, please send the request also to
the MPLS-TP list as well.
Lou Berger: It's a good idea for the authors to point out this work on
the MPLS-TP list as well.
Deborah Brungard: The recommendation is that you give the document some
more visibility.
Nitin Bahadur: [Slide 1] The
motivation seems to decide it reversion is dictated by the ingress, shouldn’t
it be that the ingress or the PLR makes that make the decision?
Attila Takacs: This refers to both cases.
Lou Berger: Are you suggesting that different timers should be applied
at different points?
Nitin Bahadur: There may be a case where the PLR needs to
decide to revert not.
Lou Berger: This document governs the timing not the decision point.
20 – Encoding
of Attributes of LSP intermediate hops using RSVP-TE
21 – Use cases
and alternatives for configuring intermediate nodes using RSVP-TE
Presenter: Attila Takacs
Lou Berger: We had a good discussion on the use of
ERO at the last IETF [76]. What we are doing here is slightly different from
the original intention of ERO. It started out as data path control, and now we
are using it for targeted control plane operations. While we could encode it
this way, it's not necessarily the right semantics. We should do what we have
done in the past other instances. For instance we have similar issue with
segment protection and we came up with a solution that provides a targeted
object (SERO), and perhaps a similar approach is appropriate here. I think
there are other options to explore. Given the previous discussion I do not
think we should go down the path of ERO as a way to carry non-data path
selection.
Attila Takacs: I think it depends on the use case. I think for say ROADM
configuration you are probably right. I agree that we do need to consider use
cases.
Deborah Brungard: How many read the draft?
(not many)
Deborah Brungard: We need to encourage more people to read the draft.
22 - On the
association of GMPLS Recovery LSPs
Presenter: Lou Berger
Adrian
Farrel: With my AD hat
on. "Allow for non-GMPLS usage", is this in the CCAMP charter. Have
you gone to the transport area with this work?
Lou Berger: We have not taken it to transport area. We do intend to find
out what the plan is with the [RSVP] mini-bof on
Wednesday. I was waiting on that session to help with the discussion of this
document.
Adrian Farrel: That's wise, after the [RSVP] mini-bof
you might setup a meeting with various ADs and chairs to see where we can
perform this work, and if we need to do any chartering.
Lou Berger: Regarding the charter, I do not think it was envisioned in
the charter, but its not clear if this is precluded.
Loa Anderson: I think at least a part of the non-GMPLS use, is within
scope as there is a long list of WGs list on the charter page that CCAMP can
cooperate with.
Lou Berger: I agree on the MPLS side, regarding INTSERV it's not so
clear
Adrian Farrel: [Regarding Loa's comments] just because it [charter] says
you will co-operate does not mean you do other work of WGs.
Fatai Zhang: Clarification for LAN recovery usage, if we have two parallel
LSPs, and they have no common nodes. Can we create a relationship between these
two LSPs?
Lou Berger: If they have no common nodes? Other than ingress or ingress,
what do you mean? Or are you saying no common node at all.
Fatei Zhang: No common at all.
Lou Berger: If they have no common node at all. The mechanism will work
but there will be no node where the identification will be identified. From the
management plane perspective you can establish association, but it cannot
happen in the control plane because there are no shared nodes. Technically it
works, semantically it's irrelevant. If two LSP's pass
through the same node, then the association can be identified.
Francois Le Faucheur: Concerning Adrian's [Farrel] point, how should we
handle RSVP based on the mini-bof later in the week. Being pragmatic, we have this problem for RSVP for
non-MPLS, RSVP-TE, RSVP for GMPLS and overlapping MPLS and GMPLS work. We have
tried very hard to reapply work where possible. We are taking advantage of work
that is useful in multiple WGs.
Adrian Farrel: I'm not saying kill the work. I'm saying take it to the
right WG or re-charter.
Lou Berger: Two options. We can make changes that only affect MPLS and GMPLS,
regarding INTSERV we do not know yet. Or we can recharter to expand allow for
this work.
Julien Meuric: The main usage is INTSERV, as a member of the CCAMP I do not
know anything about INTSERV. I'm really not sure this is the right place.
Deborah Brungard: As
23 - RSVP
Resource Sharing Remote Identification Association
Presenter: Francois Le Faucheur
Deborah
Brungard: As Francois
mentioned, we will see how this progresses.
24 – RSVP-TE Extensions
to Realize Dynamic Binding of Associated Bidirectional LSP
Presenter: Fei Zhang
George
Swallow: Have you read
RFC4206, how would you compare this work to that document. This seems to be
very similar where you combine two LSPS together. You should take a careful
look at that document and see how it should be extended.
Lou Berger: I think it's good to have alternatives to meet requirements
from TP. Its good to see solution documents from the
TP framework mentions calls, but it should not restrict solution use, whether
it's forwarding adjacencies or association. The association object approach
should sync with the association document.
Deborah Brungard: We encourage you to please read this document as it is
relevant to MPLS-TP work.
25 – OSPF ASON
Routing Extensions
Presenter: Lyndon Ong
Andy
Lou Berger: By this do you document what was presented, or RFC5787?
Andy
Lou Berger: From an IETF process standpoint I think the latter is the
fastest choice, which is the opposite of the first.
Andy
Lyndon: I would support Andy, getting this stuff onto the standards
track. Secondly, effort on the OIF part is not a high priority within this
group. We would find it faster and easier to implement the standard the closer
it is the work that has already been implemented and tested.
Lou Berger: Proposals for RFC5787 BIS's would be interesting. Given that
the document went thru the WG and the reason for being experimental rather than
proposed standard was [lack of] intent of implementation. Given that I think
it's really necessary to state the reasons to change the formats. There needs
to be strong justification for changes. We look forward to seeing future drafts
proposing RFC5787 BISs.
Lyndon Ong: I guess that strong justification is a judgment,
I would hope that having running code provides something in favor of changes.
Eve Varma: As we are moving into the OTH work we are also finding the
bandwidth quantification issue is something that does have an impact on the
quality of the path computation. What I think is useful is to make sure that
TDM-type or ODH routing that has fixed and flexible containers, have a common
approach. A lot of work has gone on with the BW quantification to see how we
can do things in a coherent way, and it moves forward smoothly and there is a
balance to do everything in the same way. There are some opportunities for
joint solution approaches and I don't think it's all or nothing and there will
be things in common.
Julien Meuric: With respect to the earlier comment on running code. I
know an LMP implementation that has been deployed on 10s of nodes,
this is deployed on running code. It uses class type 30 instead of 18. Do you
think we should update the RFC to take that into account? In my view the answer
is obvious. Does it make sense in terms of processes to make minor changes?
Lyndon Ong: I understand, it’s really a two
step argument. There is running code, and there is also an RFC that came out as
experimental because of a lack of running code. We can converge on a solution
and bring this to standards track.
Zafar Ali: For a BIS there needs to be a tactical reason, some gaps in
the RFC, not just running code.
Lyndon Ong: From a technical perspective, the most serious concern is
with the ISCD. Having to put in repeated versions of the ISCD. I think the
other, local and remote, is more trivial difference. With addresses there is
some preference for the length version rather than the network mask. I take it that
one outcome from this discussion is that there is interest to start up a
RFC5787 BIS.
Malcolm Betts: I would like to support the proposal that Eve [Varma]
made. We need to take into account the extensions for OTN. If we're going to do
an update to do one that covers all the cases, and not get
caught with multiple updates. Let's also base this on proven implementation
experience.
Deborah Brungard: This is not the first time that private
implementations got ahead of standards. It's good to hear that there is
willingness to come to an agreement. If you are willing to come to a compromise
this is all good. Let's go forward with BIS, we really
need to see the justification for technical changes.
26 –
Requirements for auto-config of control plane
adjacency
Presenter: Lyndon Ong
Igor
Bryskin: I would
support this draft; we analyzed the hierarchy draft in my company we concluded
also that lots of things need to be advertised and controlled for dynamic
hierarchies. For instance the TE metric. How can you
do this on the receiver side, port colors, etc. You
might need to support multiple clients and multiple layers to support the
hierarchy. There is no way to specify how this can be done.
Lyndon Ong: I think LSP hierarchy mechanism provides ways to provide
extensions; we just need to see if the extensions are necessary and how to do
them. Perhaps further discussion on the list?
Lou Berger: If would be good if you guys can get together and bring in
the issues that Igor [Bryskin] indentified. Then identify which aspects are
already covered inthe standard GMPLS solutions. A
number of requirements will go away but there will be the new additional
requirements particularly based on Igor’s [Bryskin] requirements. He can also help and he can contribute to the
work.
27 – PLR Designation in RSVP-TE FRR
Presenter: Jie Dong
Zafar Ali: [Requirements Slide] some resources can
have resiliency. What makes a resource, a node or link, what makes the LSP not
fail? What is the mechanism that allows the LSP to not fail when there is a
node or link failure?
Jie Dong: This is based on network and local policy. GMPLS segment
recovery already provides this. It can explicitly designate the start point and
end point of the protection. In some scenarios we need to know which links all
notes are reliable.
Zafar Ali: I am not getting it. If something fails. What makes this LSP so
permanent that it will not fail and you have to specify per hop behaviour?
Lou Berger: It’s a policy decision of the operator of where to place the
PLRs. It's not that it cannot fail it's just that they have chosen not to
protect it.
Jie Dong: Provides more control of backup LSPs.
Curtis Villamizar:
Some of the links may be in the same building in adjacent racks for instance.
These tend not to fail quite as often. Some vendors have reasonably good
redundancy in the control plane. Most equipment also has reasonably good
redundancy in the fabric. There is a little less requirement for node
protection, so I see the value in this.
Lou Berger: The point with segment recovery is that the SEROs could be
used to indicate the PLRS points. It's not either or. It's using SEROs to
support RFC4090 style protection.
Jie Dong: So using SEROs with RFC4090 for protection?
Lou Berger: Yes, it's not precluded. It may not be fully documented in
the RFC and in your document could cover this. Now with my Chair hat on, I am
not sure why you are bringing this to CCAMP versus MPLS?
Jie Dong: There is some relevance to other draft presented per-hop
configuration. So we present this here.
Lou Berger: I would like to hear from Loa and George on this.
George Swallow: This belongs in MPLS
(Unknown from NTT): I do not see much benefit for this. It does not save
many resources, and it increases the operational burden for FRR deployment.
Jie Dong: Without enhancement every FRR node perform
as a PLR, every node needs to establish and maintain. In some scenarios this is
unnecessary. This reduces resource and bandwidth cost. In some nodes you just
need local protection.
George Swallow: The biggest complaint from our users on RSVP-TE seems to
be the difficulty to configure it. From the MPLS WG Chair perspective, I would
like to hear a demand from people who deploy RSVP-TE that this is something
they really need.
Lou Berger: Makes sense. We look
forward to seeing this in the MPLS WG.
28 – Signaling
RSVP-TE P2MP LSPs in an Inter-domain Environment
Presenter: Zafar Ali
Lou Berger: P2MP was done in the MPLS WG, RFC5151
was done here. The document does not mention RFC5151. Given this, it seems the
document belongs in the MPLS WG.
Zafar Ali: I do not have any particular preference. I think its useful
information for CCAMP.
Lou Berger: I think a document that extends RFC5151 to P2MP would be an
interesting document to discuss here. In its current form your current document
is interesting and thank you for presenting, please take it to the MPLS WG.
Zafar Ali: We will update it and discuss with MPLS chairs.
29 – RSVP
Extensions for Multi-Topology Support
Presenter: Quintin Zhao
Lou Berger: As before. Why CCAMP and not the MPLS WG? Procedurally this is
MPLS. The objects were defined by MPLS and should be modified in the MPLS WG.
(Unless the WG chairs say do the work in CCAMP.)
(Unknown): For the requirement you need a description of not just the
IGP to topology. For standards track it's not worth having options due to
interoperability. For option 2 have you consider the implementation.
Quintin Zhao: The applicability should be discussed with SPs and we will
define requirements from these discussions. The options question, option 1 is
simple to implement. The concern we have is table space which is limited for
large number of topologies.
Igor Bryskin: This is a logical compliment for multi-instance solutions
discussed in OSPF. You need to identify the topology you are working on. Why
not introduce a separate object that identifies the technology. The important
thing is using multiple topologies to identify the topology.
Lou Berger: Thank you for the presentation. We look forward to seeing
this work in the MPLS WG.