CCAMP Meeting Agenda
78th IETF Meeting
Maastricht, July 2010
Agenda Slides: http://tools.ietf.org/wg/ccamp/agenda
First
Session
Tuesday, July 27, 2010. 1300-1500 Afternoon Session I
Changes to the agenda:
- Talks 6 (draft-bernstein-ccamp-wson-signaling) and 7
(draft-zhang-ccamp-rwa-wson-routing-ospf) have been reversed.
- Talk 9 (draft-agraz-ccamp-wson-impairment-ospf) has been removed from the
agenda as the presenter was unable to attend.
- Talk 27 (draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext) has been moved from
session 2 to session 1 due to the additional slot now available.
See slides for detailed WG status update.
Greg Bernstein: We are ready for last call.
Lou Berger: Ok please send an “any
additional comments?” request to the mailing list. If you receive no responses
we can move to last call.
draft-ietf-ccamp-rwa-wson-encode-04
Greg Bernstein:
We are preparing the document for last call.
Lou Berger: We can expect one more
technical change? [Refining the encoding to 1 bit instead of 16]
Greg Bernstein: Yes.
Igor Bryskin: Regarding the shared
transponder, this may be tunable or non-tunable. If I am computing a primary
and a recovery path for a single service, how can we avoid the primary and
recovery path sharing the same resources?
Greg Bernstein: So you mean link and
node disjoint? Resource blocks are indentified but I'm not sure if you would
have enough visibility [externally for a something like a PCE when computing a
disjoint path]. This may be useful but
we would need to make sure we have control of this information for signaling.
Igor Bryskin: Not necessarily, it
depends on the explicitly of the path.
Greg Bernstein: When I create the
LSP I'm not sure if I can specify this. We wanted to have additional control
over resources it sounds like this is a good example.
Igor Bryskin: Additionally, maybe I
want to specify a specific transponder I want to use out of a pool of resources
for a particular service. So there should be a way to constrain path
computation as well as signal this.
Lou Berger: Does this question also
apply to your first presentation [RWA information model]?
Greg Bernstein: It has the concept
of a resource.
Lou Berger: Consider this is your
first comment before last call and please address accordingly.
Julian
Meuric: I feel that encoding resources is dependent on the info model. Do
you feel it's a little early to close those documents [RWA information model]
without implementation feedback and discussion and improved IGPs?
Greg Bernstein: The information
model document is more abstract and more related to informational. The encoding
draft is a more valid for your point.
draft-ietf-ccamp-general-constraint-encode-02
No comments.
draft-ietf-ccamp-wson-signal-compatibility-ospf-00
No comments.
draft-bernstein-ccamp-wson-signaling-06
Lou Berger:
How many have read the document?
Poll result: Sparse response.
Lou Berger: How many think this
should be the foundation for our work?
Poll result: Same sparse response.
Lou Berger: Does anyone have any
questions or issues at this time?
Poll result: No.
Lou Berger: One technical comment
with my chair hat off. I think we need to consider a specific mechanism to
optimize bi-directional allocation. We know from previous work bi-directional
allocation can be supported using existing mechanisms.
draft-zhang-ccamp-rwa-wson-routing-ospf-03
Lou Berger:
Good changes [see final slide “Next Steps”], particularly on name changes and
alignment with general constraints encoding.
draft-ietf-ccamp-wson-impairments-02
Deborah
Brungard: The work has been
progressing, let’s review and see if we are ready for LC before the next IETF
[79].
draft-agraz-ccamp-wson-impairment-ospf-00
The presenter was unable to attend and present this talk.
draft-li-ccamp-lmp-behavior-negotiation-01
Lou Berger:
Would a link be aware if it was an MPLS-TP or OTN link? Why do we need to
signal this?
Dan Li: For specific technology
types you may need additional support.
Lou Berger: So you are saying that this would support new
future technology? With my co-chair hat off, anything that goes there [New
C-Type bit vector] should reference a function
from an existing RFC or draft. Additionally what will you do when you run out
of bits, maybe this needs to be more extensible? This needs to be addressed in
draft.
Dan Li: With the existing solution
we still have several reserved fields. We think this is enough for future
function.
Julian Meuric: I was also wondering
what architecture flags were going to be used. In GMPLS we already have PSC, et
al. This additional mechanism needs further elaboration as to why it's
necessary. Besides this, I think this is an interesting feature.
Dan Li: If the bit is set to zero
there is no new function. If the bit is set to 1, then there is a new function.
Eve Varma: This is an interesting
feature I have one question for clarification. In RFC4204 there is one config
object. So it would be possible to put multiple config objects in LMP messages.
Do you foresee any backwards compatibility issues?
Lou Berger: The document should have
a compatibility section. Does this document have a compatibility section?
Dan Li: Yes.
Lou Berger: OK, that question [from
Eve] should be addressed in that [compatibility] section. If not, it needs be
added. If my memory is correct, then LMP should support this.
Deborah Brungard: OK, how many read the draft?
Poll result: Some hands.
Deborah Brungard: We did previously discuss having this functionality. How many
people feel this is a good document to use as our base?
Poll result: Similar number of hands.
Deborah Brungard: Good. Let’s take this to the list.
No Comments.
draft-malis-ccamp-rfc5787bis-00
Julian Meuric:
I am glad to see the changes made for consistency and with existing RFCs. My
concern is when I read it gives me a headache because of the ASON specific
vocabulary. The appendix does look to define ASON concepts. Can you make the
document more readable for IETF folks?
Lyndon Ong: I approached the
document from the ASON perspective. If [IETF] people can identify and propose
changes and provide text it would be helpful.
Lou Berger: Good comment to take
back to Acee [OSPF working group co-chair]. I think he is the right person to
take the lead on that.
Deborah Brungard: This work was originally done based on ITU
requirements. When you simplified [from RFC5787] what you felt was needed, I
think we still need the link to the ASON requirements. There are several sections
and text which have been removed. We want to avoid Liaisons discussing
requirements that we did not meet. It's important that you identify this
upfront. So we can avoid Liaisons requesting why we no longer meet
requirements.
Lyndon Ong: That's a good point. We
did let AC run with the OSPF section. We need to insert an explanation of what
is or is not in the document based on existing requirements.
Deborah Brungard: I think there may need to be an assessment on why
you no longer need to support a requirement. If there is no technical change or
issue, then why is the requirement no longer necessary? We should also remember
that not every implementation will support all functions. Lyndon Ong: The intention was to make it clear that you can relax a
requirement.
Dimitri Papadimitriou: I am unclear.
What is needed? What I hear today is that we now no longer need discovery and
which routers are capable of performing this function, it's puzzling. Of course
if you remove requirements, you will simplify the document.
Lou Berger: We have to meet the
requirements of ASON based on the requirements RFC we created. This is the
first draft, we have now identified to the authors that we still need to fully
meet the requirements. Let’s wait for the next version to see how those are
addressed. Anything that’s omitted or not satisfied will need to have
additional discussion to clarify why it was no longer needed.
Lyndon Ong: We may have over
simplified the first draft. These are all good comments.
Malcolm Betts: I know it’s the first
draft; maybe some informal discussion needs to take place between Question 14
and Question 12 at the upcoming [October] interim meeting would be beneficial.
For instance the election of the speaker was a requirement; this can be clarified
quickly.
Deborah Brungard: It’s important to be clear on what requirements have
been removed and it must be clear why.
Lou Berger: If you change
requirements, we may need to do a BIS on our requirements document as well. So
we can keep both the requirements and solution documents inline as we cannot
have a solutions document that does not match the requirements document.
Lyndon Ong: This is not an approved
[working group] document, it's an individual document.
Deborah Brungard: We would have to do a BIS on the requirements, so
you need to discuss this with Question 12if you want to simplify.
Rob Rennison: I am trying to get an
understanding of ASON routing. You have this experimental RFC 5787, am I
correct in assuming the requirements from ASON changed significantly which
prompted you to create this BIS document? Why the significant change?
Lyndon Ong: As you mentioned RFC
5787 is experimental. We are taking the experimental and moving to standards
track. There are number of items involved, including simplifications on the
hierarchy section. By doing this we may have moved away from the original
requirements so this needs to be checked.
Rob Rennison: So the fundamental
ASON requirements did not change.
Lyndon Ong: No.
Rob Rennison: Ok, I understand the background.
Lou Berger: From the process
perspective these requirements have not changed. If the requirements have
changed then the ITU need to tell us.
draft-roch-ccamp-reqts-auto-adj-01
No comments.
draft-ong-gmpls-ason-routing-exper-02
Igor Bryskin:
Do you think the same logic applies to OTN or not?
Lyndon Ong: Same applies: multistage
multiplexing, ODUflex, etc.
Julian Meuric: For SDH, due to
deployments that existing I am concerned. I would favor the original way.
Eve Varma: I was going to make the
same point [agreeing with Lyndon Ong’s point].
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-03
Moved from Session 2.
No comments.
CCAMP
Meeting Minutes
78th IETF Meeting
Maastricht, July 2010
Second Session
Wednesday July 28, 2010.
1300-1500 Afternoon Session
draft-ietf-ccamp-gmpls-g709-framework-01
Lou Berger:
Good to see progression of this draft.
The OTN requirements are being captured and it seems we also have new
ones [including VCAT for certain signal types]. It's important that the
framework document focuses on requirements and not solutions.
Fatai Zhang: Yes, thanks.
draft-bccg-ccamp-otn-g709-info-model-01
Lou Berger:
It is very good to present what information is being passed, is it your intent
to also document how the information is represented in the routing protocols?
Sergio Belotti: The encoding is out of scope of this document. We will provide a
separate document detailing the encoding solution.
Lou Berger: This seems like a
reasonable split but you already have some encoding information in this
document. So you may want to keep this document a little cleaner and keep
encoding information in your encoding document.
Sergio Belotti: OK.
draft-ceccarelli-ccamp-gmpls-ospf-g709-02
Curtis Villamizar:
We had a recent meeting [last night] and I assume these slides were prepared
before that meeting. I believe we agreed that we would not use the
encapsulation described [slide 3]?
Daniele Ceccarelli: Yes. These are
old slides.
Lou Berger: [Slide 7] Please note
that “consensus” refers to author consensus and not working group consensus.
Curtis Villamizar: For clarification
there was consensus on the requirements and not the encapsulation used in the
slides.
Lou Berger:
As the two documents move forward it will be interesting to see which parts of
the documents will be folded into the general framework document. We would like
to consolidate technology into a single solution set, as opposed to having multiple
separate documents.
Curtis Villamizar: We may have
missed a requirement in the G.709 framework, if there is a policy decision for
ODU selection for sub-lambda’s. I do not see how this is advertised.
Xihua Fu: If the operator decides to use multistage
multiplexing capability in the network. The current control plane and
management system can integrate path computation. If this capability can be
advertised for path competition it would be very useful.
Eve Varma: Re: Curtis. The
requirement that was added was a termination adaptation capability. This would
accommodate multistage multiplexing, but it's a more generic requirement.
Malcolm Betts: Yesterday when we
were talking offline we did not get to talking multistage multiplexing. So
there were requirements that were not discussed yesterday that need to be
included. Re: Eve’s comments, I am not in complete agreement. We need to give a
more topological view. Re: Lou’s comment, it does make sense to combine this
work [with the general framework document].
Deborah Brungard: These documents need to be updated to reflect
terminology discussed in G.709 and G.872.
Malcolm Betts: I have mixed feelings
on multistage muxing. When you deploy new elements in the field some will support
multistage muxing, some will not. From a protocol view we need to describe
multistage muxing anywhere it happens to be. From a network deployment
perspective it is suboptimal to randomly place this capability, you really need
to consider deployment locations during planning.
Lou Berger: Good I'm looking forward
to seeing that input folded into the framework document.
Lou Berger:
There has been significant discussion on the list regarding G.709 framework and
encoding. We decided to set aside some time in this session to discuss this
topic.
G.709 Discussion slides from Igor Bryskin
Jonathon Sadler:
Two comments. The first comment, Igor mentioned “in ITU typically you find a
separate control plane instance for each layer”. I would point out that this is
not a requirement from the ITU.
Igor Bryskin: All I said was it was
unusual.
Jonathon Sadler: The second comment
was regarding a virtual topology. I then immediately think VPN and I wonder why
the L1VPN work is not relevant instead. This does not require modification to
the switching capability.
Igor Bryskin: I use VPN as an
artificial separation of network resources. There is a natural separation of
resources if I'm using multiple layers.
However my WDM links do not belong to different VPNs.
Jonathon Sadler: So to be
specifically clear, you’re OTN virtual topology example [slide 2] looks like
separation in terms of how resources are used.
Igor Bryskin: It is, but it is a
separate layer.
Jonathon Sadler: The separation of
the layer is not the issue.
Deborah Brungard: Igor is referring to a VNT as described in RFC5339.
Igor Bryskin: Yes. I want to
constrain my resources to this triangle [slide 2]; I do not want clients to use
all my underlying OTN resources.
Jonathon Sadler: I understand it
doesn't necessarily mean you have to create a network hierarchy. I suggest you
do not use switching capability as a method of separation.
Lou Berger: From a high-level the
VNT is a construct to overlay on the data plane. This is an interesting
addition to the mix and I suggest we move the discussion to the list.
Malcolm Betts: Just to clarify, the
hard requirement in the ASON architecture is that it is possible to combine
control planes. In terms of multilayer and single layer for OTN, I can route
services across the same common resource pool. I do not think you need to
create a new VNT to achieve this.
Lou Berger: That is a good point.
VNT does not preclude shared bandwidth; it just means that if you are, you have
to advertise when there is a change.
Malcolm Betts: The problem is not
just with the amount of advertising that needs to be performed, you also need
to coordinate when capacity is used by a VNT.
Martin Visseurs: These will be ODU2
connections as an example in network. These ODU2s carry client services but the
question from Igor is will it be necessary to identify a set of links over
which ODU2s should be carried. I'm not sure if this is a specific requirement
from network operators.
Igor Bryskin: Building a VNT does
not require further advertisement. You just need to identify which links belong
to several VNTs.
Fatai Zhang: We know that for ODU
services we can cross multiple layers. [Scribe did not catch additional
comments]
Malcolm Betts: Based on Igor’s
example, it almost refers to multilevel multiplexing how this should be
represented. When we discuss topologies on how to advertise capability, as soon
as you activate capability you have created a new link between endpoints.
Igor Bryskin: I want to answer both
questions. VNT does not prohibit going from one VNT to another. To answer
Malcolm it’s not true that I have to advertise a new link.
Autumn Liu: When we discuss protocol
specific forms, these are important in the process but it’s not the end step.
draft-zhang-ccamp-gmpls-evolving-g709-05
Lou Berger:
Regarding your first bullet [slide 6]. Identify requirement that fit within the
information model. Make sure requirements are in the framework document. We also need to cover control-plane
requirements. Here is an opportunity to provide text for the document.
draft-zhang-ccamp-gmpls-h-lsp-mln-00
Lou Berger:
We thought this work was interesting; one of your examples was in line with
Igor’s points. This is generic so we like this solution.
Lyndon Ong: Fatai and I talked and
we saw a common problem with our hierarchy draft, he needs to indentify server
layer, we need to indentify client layer.
Lou Berger: Get together come up
with a solution.
draft-zhang-ccamp-srlg-fa-configuration-00
Xihua Fu:
You mention a number of scenarios but, in the ITEF, it should be single control
plane instance for multilayer multi-region environments. The SRLG information
can be collected from the IGP. My second comment, if you want to use signaling
to collect SRLG information, how do you refresh SRLG information from the FA?
Fatai Zhang: Regarding your first
comment, we may use single layer technology but it does not mean must.
Regarding your second comment, if there is a failure in the FA LSP it may need
to re-route and you will need to check signaling to create a backup LSP.
Cyril Margaria: If the ingress does
not have full IGP visibility. Does this problem also apply to a preplanned
shared restoration? I do not think this problem is solely applicable to SRLGs.
This should be more generic and not just for FA LSPs.
Fatai Zhang: This draft is generic
enough we don't specify where the procedure is applicable. How to advertise the
FA is out of scope of the draft
Cyril Margaria: My point is this is
not just applicable to multilayer. This is applicable to single layer if you do
not have full IGP visibility for the end-to-end path.
Fatai Zhang: Sorry I do not
understand the question.
Cyril Margaria: OK. We can take this
discussion off-line.
draft-fuxh-ccamp-multi-stage-multiplex-config-ospf-00
Lou Berger: Please work with framework authors to make sure the requirements
are there. Also work with the information model authors to see if you can bring
requirements to that document a well.
draft-fuxh-ccamp-multi-stage-multiplex-config-rsvp-00
No comments.
draft-xie-ccamp-elec-opt-network-info-ext-req-00
Deborah
Brungard: Have you looked at the
WSON work? WSON includes an optical part of G.709. You need to indentify gaps
and be framing this work to reference that work.
draft-berger-ccamp-attribute-bnf-00
Deborah Brungard:
Who has read the document? [a couple of hands raised].
Adrian Farrell: I was editor of RFC4420
which became RFC5420, which came out before we had P2MP LSPs; I think you have
captured the intent perfectly.
Additional time for discussion at the end of CCAMP
Session 2
Daniele Ceccarelli: [Scribe did
not hear the question]
Rob: As I understand things, if you signal a new LSP you can
advertise this as a new TE link and institute local policy to announce or not
announce. Your peer can then create his own topology based on what you have
announced. Within GMPLS you don't need multiple instances to achieve this.
Igor Bryskin: Regarding Danielle’s
question. In my low order role I can only accept ODU0; in my high order role I
can accept both ODU0 and ODU1s. The VNT and the actual layer are
indistinguishable. As you mentioned everything “is a bunch of resources”.
Ethernet is bandwidth but maybe we want to separate bandwidth and one way to do
this is to use topologies. For instance in MPLS we use RSVP-TE LSP's to
allocate bandwidth. That's another example of virtual topologies. Of course you
can advertise whatever you want; it's a local discovery issue and
administration.
Lou Berger: A new interesting topic is in
regard to encoding information. Are we reusing ISID or adding sub-TLVs and defining
technology specific information related to OTN, or throwing out the existing
sub-TLVs and defining new ones.
Jonathon Sadler: There is another
option to have both new and old. My concern with this is that there are devices
that use old encoding types and how to maintain backwards compatibility. A
separate sub-TLV may help this. But it does not mean that you're not using the
old one as well.
Lou Berger: That’s true if you use the
same switching capability and encoding types, or using multiple switching
capabilities, or existing switching capabilities and new encoding types. We
have multiple ways to demux data structures essentially. We need to decide
which ones we want to use and existing implementations. There was also quite a
bit of discussion regarding compactness versus verbose generic format. There
will be a trade off from taking our technology and refining it to fit in the
generalized framework.