85th IETF -- CCAMP Minutes
>
First Session
>
MONDAY, November 5, 2012
>
900 - 1130 Morning Session I
>
Room Name: Grand Ballroom D
>
Minute
takers: Dan King, Daniele Ceccarelli
CCAMP Minutes Session 1
>
Presentation Start Time Duration
Information
> 0 9:00 15
Title: Administrivia & WG
Status
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-0.pdf
> Presenter: Chairs (Lou Berger)
Lou Berger: Deborah Brungard (CCAMP co-chair) had to
cancel her attendance at the last minute due to Hurricane Sandy.
Adrian Farrel: Please note IPR
disclosures should be made often and early.
Lou Berger: A couple of agenda
changes. One presentation removed today. One removed from tomorrow.
Lou Berger: We had a recent issue
with a draft that the RFC-Editors were reviewing. It had a mismatch between the
number of authors listed in the front page and at the back. Ultimately fewer
than five is not a problem.
Adrian Farrel: RFC-Editors are looking
for front-page names to match the authors section. They [RFC Editors] have a
preferred maximum of five [authors]. The
mailing list “RFC-Interest” does provide some background on the current
thinking.
Lou Berger: My experience is a
reasonable limit, if they chose five I am not saying that is good or bad.
Adrian Farrel: We are going to have
a joint meeting on Friday (in Orlando at IETF85)
afternoon with the ITU-T SG15 Q6 members.
Lou Berger: This meeting is still
being discussed and will be announced once confirmed.
Julien Meuric: In
April you have a GMPLS E-NNI milestone. Is it going to be called E-NNI, has it
already been decided or it can be changed?
Lou Berger: The name can be changed
to match WG progress and will be changed as needed.
>
1 9:15 10
Title: RSVP-TE Extensions for
Collecting SRLG Information
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-srlg-collect-01
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-1.pdf
> Presenter: Óscar González de
Dios
Lou Berger: For
clarification. Your proposal includes both (LSP_ATTRIBUTES and
LSP_REQUIRED_ATTRIBUTES) to collect SRLG information, correct?
Óscar González de Dios: Yes.
George Swallow: The text is not
there yet, it's a proposal. The SRLG collection draft I will be presenting has
both.
Khuzema Pithewan: A
question on the use cases. When are we going to need this functionality?
Lou Berger: We already agreed this
is a function we will be supporting.
Khuzema Pithewan:
What are the use cases; do you have a pointer to framework?
Lou Berger: This is a mechanisms
document, we don't require use cases. Do you have a use case in mind?
Khuzema Pithewan:
Yes
Lou Berger: I do not see a reason
that the draft could not include use cases, so please send your use case to the
authors or the WG list.
Adrian Farrel: Do you intend to make
this work multi-AS? I do not understand how this supports multi-AS. You will
need an AS identifier.
Oscar González de Dios: The document
requires the SRLG to be unified among different ASs.
Julien Meuric: As a
multi-AS provider, you can have scenarios were you do not need to encode the AS
number, but your comment is fair.
Zafar Ali: The metric collection draft [draft-ali-ccamp-te-metric-recording]
has use cases that could be used.
Lou Berger: A question on the
partial recording. It is already supported [RFC3209]). There is no flag to say
when that policy is applied. Why introducing it is this case? You need to make
a general extension that applies to all cases.
Oscar González de Dios: Do you think
we need to make this general functionality?
Lou Berger: [With contributor hat
on] Either it should be a general RRO function or not
done at all.
Oscar González de Dios: Ok we will
take this to the list.
>
2 9:25 10
Title: Update from OTN/G.709
Working Group Last Call
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-g709-framework-09
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-04
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-03
> Draft: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-04
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-2.pdf
> Presenter: Daniele Ceccarelli
Lou Berger: Please authors,
you need to provide IPR statements, if you have not already disclosed. The last
two documents require review and update of conformance (RFC2119) language. A
proposed standard RFC needs 3 things: (1) a narrative discussing what is being
done; (2) then informative text describing how it’s being done, and (3) RFC2119
conformance language telling implementers and testers what needs to be done to
conform to the document. A (final) technical comment, error codes in signaling document
needs to be looked at. A timer mismatch for crankback
for instance.
>
3 9:35 10
Title: Link Management Protocol
(LMP) extensions for G.709 Optical Transport Networks
> Draft: http://tools.ietf.org/html/draft-cecczhang-ccamp-gmpls-g709v3-lmp-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-3.pdf
> Presenter: Xian Zhang
Lou Berger: [Poll] How many have
read the document? [A small number, ~10]
[Poll]
How many think this is important functionality (even if haven’t read the
document)? [About 1/2 the prior number.]
[Poll]
How many have read the document and think it’s *not* useful? [No hands.]
Lou Berger: Interesting but mixed
feedback.
Julien Meuric: There are three
concepts in the document, so looking at it as a whole is a bit difficult.
Perhaps the answers would be different if asking about each separately.
Xian Zhang: Maybe the lack
of interest is due to the fact that LMP is optional in GMPLS?
Lou Berger: Perhaps, at
this point the document should continue as individual document and see if more
interest is generated. The discussion should continue on the list.
> 4 9:45 10
Title: Multi-layer implications
in GMPLS controlled networks
>
Draft: http://tools.ietf.org/html/draft-bcg-ccamp-gmpls-ml-implications-03
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-4.pdf
> Presenter: Dimitri Papadimitriou
Rajan Rao: With regards to
example 1. What kind of LSP is it? Is the intent to have an end to end LSC LSP?
Dimitri Papadimitriou: The intention
is to create an LSC LSP.
Rajan Rao: Why
there is the need to use an IACD?
Dimitri Papadimitriou: The ISCD
objective is to advertise capability to regenerate (Example 1).
Curtis Villamizar: In that example
[1] you are using the regeneration capabilities. The next slide [example 2] is
not really a LSC LSP from Node A to Node D.
Dimitri Papadimitriou: This is a
different scenario. This is showing an add-drop multiplexor, injecting packet.
Curtis Villamizar:
It is a PSC LSP. In any case you are making a new layer.
Lou Berger: This is an interesting
topic. We have some issues that need to be addressed. Please continue
discussing during the week, offline or on the mailing list. Please keep in mind
that while the talk here has been about routing, we also have signaling
implications.
>
5 9:55 10
Title: OSPF-TE extensions for
MLN-MRN based on OTN
> Draft: http://tools.ietf.org/html/draft-rao-ccamp-otn-mlnmrn-ospfte-ext-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-5.pdf
> Presenter: Rajan Rao/Khuzema Pithewan
Daniele Ceccarelli: One comment. Why
are just considering OTN?
Rajan Rao: First
slide, if you look at the OTN encoding, we encode everything on one encoding
type.
Daniele Ceccarelli:
I agree that the new definition of the OTN ISCD perfectly fits with multi-layer
networks, but it should be extended to make it generic and cover the case of
any hierarchy over any hierarchy.
Rajan Rao: Sure,
maybe SDH. That is a valid point.
Khuzema Pithewan: This
proposal talks about the upper layer and lower being OTN. We do not need to
identify a specific layer.
Daniele Ceccarelli:
It’s not clear why we should just cover OTN. Why not SDH over SSON?
Rajan Rao: Do you
have use cases?
Lou Berger: We are a little over
time on this topic, but we can continue it on the list. It’s not clear if the
previous documents are solving the same problem. We should see if there is some
commonality. Anything we can do to reach agreement on what problem the draft(s)
are trying to solve will help the process. I suggest discussing this on the
list.
>
6 10:05 10
Title: Expressing LSP attribute
in ERO
> Draft: http://tools.ietf.org/html/draft-margaria-ccamp-lsp-attribute-ero-01
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-6.pdf
> Presenter: Cyril Margaria
Adrian Farrel: Having been an
author of other LSP Attributes I am having a problem with the use case for
this.
Cyril Margaria:
We have a use case.
Adrian Farrel: Document needs text
and context. I am not saying this is a bad idea; I need the document to say why
it is a good idea.
Lou Berger: Just a few references to
the documents that will use this.
Cyril Margaria:
Ok.
Jon Hardwick: A good idea to extend to the RRO, see Oscar’s SRLG collection
draft for requirement and use case.
Lou Berger: You are suggesting something
slightly different, are you suggesting that we combine the function to have an
RRO with larger object and deprecating the existing RRO?
Jon Hardwick: I am not talking about deprecating the
existing RRO. This new object would capture hop information.
Lou Berger: Your point of having a
single function is a good one that we should think about. Are we optimising the
wrong way for a special case? How often are we really going to have objects
that are larger than an ERO? If it’s common, than going down the current path
makes sense. If uncommon, than maybe we
should deal with it as a special case within the ERO. Should we look at a
fragmentation approach?
Cyril Margaria:
In Vancouver (IETF 84) we did discuss the fragmentation approach. However
fragmenting an object across multiple sub-objects was not ideal.
Lou Berger: Agreed, but it’s very
rare perhaps we should just take the approach with less correlation. [Comment
as a contributor]
Lou Berger: Switching to high level
questions:
[poll] How many think functionality
is necessary? [An okay number]
[poll] How many people think the approach being taken is the
right one?
[Almost the same number]
[poll] Should this document be the foundation of the
WG? [Almost the same number – as question 1]
[poll] How many think we should wait for the work to be more
mature?
[A small number, almost half and half]
>
7 10:15 10
Title: RSVP-TE extension for
recording TE Metric of a LSP
> Draft: http://tools.ietf.org/html/draft-ali-ccamp-te-metric-recording-03.txt
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-7.pdf
> Presenter: George Swallow
Lou Berger: [poll] How many think the functionality is needed? [A good number]
[poll] How many have read the draft? [About
the same number.]
[poll] How many think it is a good foundation? [Almost
the same number]
Lou Berger: Good indication of
support, let’s take this to the list. Two comments, the flags for modification
or partial is general capability so look at to see if a general solution makes
sense.
George Swallow: Those flags are not
in the draft but the attributes are.
Lou Berger: That makes it easier to
poll for the document. The other comment is that we need to let the other
working groups know the progress of the document.
>
8 10:25 10
Title: RSVP-TE Extensions for
Signaling GMPLS Restoration LSP
> Draft: http://tools.ietf.org/id/draft-gandhi-ccamp-gmpls-restoration-lsp-00.txt
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-8.pdf
> Presenter: Zafar Ali
Igor Bryskin: What you
described can be done with existing mechanisms [make-before-break].
Zafar Ali: This is an explicit indication
for the egress node. [Slide 7] this shows how the egress knows what protection
is used and allows coordination with the ingress node.
Igor Bryskin:
Why does the egress nodes need to have this info?
Zafar Ali: This allows ingress to associate
the LSPs.
Igor Bryskin:
When you do make-before-break you have exactly the same situation.
Lou Berger: Another the way of saying
this, consider the case when you're adding a protection path not because of a
failure but just because you want to add a path. Once you address this case you
also solve your case.
Igor Bryskin: Exactly true. Association
objects and existing IDs are sufficient.
Zafar Ali: I will take this offline with
Igor.
Dimitri Papadimitriou: Do we want to
keep the nominal path in dynamic restoration? Can you have a look at RFC4872
and state what cases are not addressed by the make-before-break and see if
we’re talking about a BCP or new cases?
Lou Berger: You have enough
information and feedback to discuss some use cases and explore offline. We have
a number of good comments please take them to the list.
>
9 10:35 10
Title: RSVP-TE Recovery
Extension for data plane initiated reversion, protection timer and SNC options
signalling
> Draft: http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-07
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-9.pdf
> Presenter: Zafar Ali
Cyril Margaria: In the SNC mode
you address segment monitoring but this may require a TCM level, but it seems
missing?
Zafar Ali: If you feel there is the need for
additional parameters we can discuss offline.
Lou Berger: Many things changed
since the draft was last time presented, in particular the WG OAM documents.
Please see if you can realign with those documents. If you can make an argument
that there is no alignment necessary, that’s fine but you should take a look.
Dimitri Papadimitriou: With regards
to the initial version from Attila, the question about setting up to the timers
was not progressed. I need to try to remember why. It was related to the type
of protection schemes supported, do we also need signaling to advertise to the
other end? We never determined if putting this information in the signaling was
a good thing. Having feedback on this would be good; as a cornerstone of this
work is should an object be carrying timing information for setting up these
protection schemes.
Zafar Ali: A use-case is OTN protection
schemes.
Lou Berger: Also triggering some
memories, the question (when we last discussed) came down to if the information
was managed per-LSP or on a per-device basis.
Dimitri Papadimitriou: Not saying
which was best, just saying it needs to be looked at.
>
10 10:45 10
Title: RSVP-TE Extensions for
Lock Instruct and Loopback in MPLS Transport Profile
> Draft: http://tools.ietf.org/html/draft-dong-ccamp-rsvp-te-mpls-tp-li-lb-04
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-10.pdf
> Presenter: Mach Chen
Lou Berger: There was a
comment at the last meeting. Is this scoped to -TP only?
Mach Chen: No, there is scope for
other scenarios.
Lou Berger: If the answer was yes, a
mechanism already exists and the answer would have been go
use that mechanism. If not, the document should read as if it applies to any
technology and this is not the case. I would suggest changing narrative text so
it applies to GMPLS, rather than just MPLS-TP terminology. Go generalise your
document, replace -TP specific terms with GMPLs terms then bring it back for
further discussion.
Mach Chen: Ok.
George Swallow: Something that isn’t
documented anywhere is the interaction between locking an active path and protection
switching? If you’re using end-to-end OAM you need lockout coordination. What are
your assumptions, doing this in the control plane will be a lot slower [versus
data plane].
Lou Berger: That is already
discussed in RFC4872/3. That discussion may be beyond the scope of this
document.
Greg Mirsky:
Lou you are accurate, however that RFC6535 only defines operations related to ACh channels. Are you saying that TP control is through OAM
and not signaling?
Lou Berger: I appreciate that Mach
said this applies to all GMPLS controlled technologies and not -TP only, so we
don’t have to address that particular question. There is a general feeling to
not define duplicative mechanisms. If was just TP scoped, I’d be inclined to
say use the existing mechanisms. Since the stated scope is beyond TP, we don't
have to get into that -TP specific argument.
>
11 10:55 0
Title: Multi-domain network
integration framework in the context of overlay model
> Draft: http://tools.ietf.org/html/draft-many-ccamp-gmpls-overlay-model-01
> Presenter: Daniele Ceccarelli
[Draft
not presented]
>
12 10:55 10
Title: Generalized
Multiprotocol Label Switching (GMPLS) External Network to Network Interface (E-NNI):
Virtual link Enhancements for the overlay model
> Draft: http://tools.ietf.org/html/draft-beeram-ccamp-gmpls-enni-01
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-12.pdf
> Presenter: Igor Bryskin
Khuzema Pithewan: What are the switching
capabilities?
Igor Bryskin:
It could PSC, MPLS, WDM, anything.
Khuzema Pithewan: Is
this an inter-layer issue?
Igor Bryskin:
If a user selects this link, it is a virtual link, so it could be hierarchy of
links, real links, but they have the same attributes of the virtual link advertized.
Khuzema Pithewan:
What about F to A (slide 4)
Igor Bryskin:
It could be anything, PSC for example. The only requirement is that the control
plane is separated from the data plane. If you look at the use cases in the draft
these are good examples.
Dimitri Papadimitriou: Did you look
at VNT (Virtual Network Topologies). What has changed not to use existing
mechanisms?
Igor Bryskin:
We speak about overlay model and not a peer model. it
could be an existing layer, there is not a conversation from the virtual link
to a "real" link.
Dimitri Papadimitriou: See RFC6001.
Igor Bryskin:
If we advertised a link it may have SRLGs.
Dimitri Papadimitriou: It may SRLG
but it could be other properties.
Igor Bryskin:
This draft is not a signaling mechanism, it is a model.
Don Fedyk:
We should define what's in the UNI model and then progress the ID as WG.
Igor Bryskin:
We need to identify the label on the CP interface.
Snigdho Bardalai:
this doc describes overlay network. You made assumptions that there is a link
between overlay and core network, it can be also a node. Did you cover that
case also?
Igor Bryskin:
It is covered. It is all about domain separation.
Kam Lam: You need to clarify client and the
case of multiple server layers.
Igor Bryskin:
The client is not aware of server layers. It is just about the client having
layer that he wants to work at. The work is about virtualization layers into a
client layer domain.
Lou Berger: A good discussion, but
we’re over time, please send comments to list. I will send my comments as well.
>
13 11:05 10
Title: Layer 1 VPN Enhanced
Mode - Overlay Extension Service Model
> Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-l1vpn-extnd-overlay-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-13.pdf> Presenter: Don Fedyk
Snigdho Bardalai: Not clear to me
which use cases this document is covering. If you have multiple UNIs not
converging at the client node and you still want to have them diverse. Is this
case covered?
Don Fedyk:
Yes. We would support diversity for that.
Snigdho Bardalai: So
the SRLG information would have to be configured somehow?
Don Fedyk:
Yes, say statically configured. It is discussed in the draft.
Khuzema Pithewan:
How does the second mechanism, path affinity identifier, works? If path from CE
3 is established to CE 4, which is dual homed and the first LSP is created then
the next PE would need to know how the second LSP was related and needed to be
disjointed.
Don Fedyk:
The way we dealt with customer and provider addresses was to use IGP
extensions. To be diverse, you need knowledge. It could be dynamic or static.
Lou Berger: As he [Khuzema Pithewan] mentioned
similar function exists in other documents. Why is this only applicable to
L1VPN?
Don Fedyk:
Yes, we want to review this. We think we can apply to other cases.
Lou Berger: Why not strip L1VPN context,
this could be just as applicable as those other extensions?
Don Fedyk:
We are looking to change the name and review the references to L1VPN.
Second Session
>
TUESDAY, November 6, 2012
>
1700-1830 Afternoon Session III
>
Room Name: Grand Ballroom D
> Presentation Start Time
Duration Information
> 0 17:00 5 Title: Administrivia
> Draft:
>
Presenter: Chairs
Lou Berger:
Based on the private response to the chair’s question on implementation of the
WSON documents, the chairs see no reason to change the intended publication
status/track of the WSON documents.
Julien Meuric: Can you comment
on the order of magnitude of support, how many implementations?
Lou Berger:
More than 1. If anyone is interested in putting together an implementation
survey, please feel free. Such a survey is necessary when moving to the next
standards level.
> 15 17:05
15 Title: Status update on WSON &
Signaling Extensions for Wavelength Switched Optical Networks
>
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-03
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-15.pdf
>
Presenter: Giovanni Martinelli
Lou Berger: If
you didn’t put in the common object, what solution would you take?
Giovanni Martinelli: We need to figure out which
one. No preference.
Young Lee: We
have a WSON specific encoding but we decided to use the LSP-attribute encoding
and move aligned with draft-margaria. One question:
is it possible to refer to an individual draft during the last call?
Lou Berger: You
could but it’s a risky approach. Since this is a normative reference your
document could be published only after that. In case the referenced document
never made it, your document would be forever blocked. In this particular case,
since it’s a small document and if it is a WG document, it might catch up
quickly. The alternative is to use a new object dedicated to carry just this.
One thing that came out yesterday was the size of the information that might be
carried and it seems to be quite big.
Giovanni Martinelli: We need to add some text on
this. The amount of information could be big but in particular in the signaling
case it is likely to be much smaller (one resource block instead of the full
list).
Lou Berger: I
would like to synch with Deborah on the result of the discussion on the
individual document (draft-margaria) in order to poll
the WG for adopting the document. Anything to add on the
other document?
Young Lee: It’s very close to WG
last call. There are no pending issues except editorials.
Giovanni Martinelli: I have a couple of updates
planned.
Lou Berger: Ok
please provide an editorial pass to prepare for Last Call. Make sure you check
procedures and format compliance with RFC2119 which will help speed the Last
Call process.
> 16 17:20
10 Title: SNMP MIB to manage GMPLS with
General Constraints support & A SNMP MIB to manage GMPLS TED with WSON
specific support
>
Draft: http://tools.ietf.org/html/draft-gmggm-ccamp-gencons-snmp-mib-00
> Draft: http://tools.ietf.org/html/draft-gmggm-ccamp-wson-snmp-mib-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-16.pdf
>
Presenter: Gabriele Galimberti
Lou Berger:
MIBs are always something that are slow to follow functionality but are in the
scope of this WG. Contributors are really appreciated.
> 17 17:30 10 Title: Information
Model for Wavelength Switched Optical Networks (WSON) with Optical Impairments
Validation & Encoding for WSON Information Model with Impairments
Validation
>
Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-00
>
Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-17.pdf
>
Presenter: Giovanni Martinelli
Igor Bryskin: Excellent idea to extend the
connectivity matrix. I would like to further extend it with a vector of costs
(e.g. delay, SRLG) saying what does going from a link to another link imply.
The path computer could take these impairments into consideration and compute
diverse paths also inside the node (also optical feasible paths as well).
Giovanni Martinelli: Thanks for the comment
Kam Lam: If I correctly
remember we decided in Vancouver to progress the work with the ITU application
codes, so we don’t have to deal with these parameters individually, am I right?
Lou Berger: I
think those are separate discussions. The work on impairments had not started
yet and with the original set of WSON works coming to a conclusion we can start
discussing this. These are individual documents, while the others are WG
documents so we as a WG have not decided to start this specific work. It’s just
a proposal.
Malcolm Betts: We
have had strong feedbacks from our friends in Q6 that the approach they are
taking on impairments is to define application codes, not to define individual
impairments and try to match every parameter, so they define application codes
that can be applied to receiver, transmitter and individual links. The other
thing we have done from an architectural point of view is to generalize that to
an application identifier so that there can be some proprietary extensions
(e.g. an identifier saying that this transmitter, this receiver and this link
can work together).
Lou Berger: How
does this work through transit nodes like ROADMS?
Malcolm Betts:
This is part of the link construction procedure, which is a non-trivial
exercise.
Lou Berger: I
think this is where the work is aimed.
Malcolm Betts: If
you want to select a path on the fly you need to have done a lot of
pre-computation to understand which application codes this path can support,
then what you’re looking for is a path that can support an application code
rather than try to figure out exactly what the impairments on a link are at the
time you’re trying to set it up. That’s some good material for discussion with
Q6 at our next meeting.
Igor Bryskin: How do I do end to end optical path
computation with impairments? It is a non-linear problem, wavelength and
inter-wavelength dependent. How is it possible to e.g. evaluate OSNR in the
path without full information and define where to put regeneration points?
Gert Grammel: Question
to Malcolm. A couple of meetings ago you said the black link is not switchable
at all, now it seems to me you are suggesting it is switchable. What’s the current
state?
Malcolm Betts: The
black link is an approach that is being defined by Q6 to define compatibility,
so the black link is not a thing is an approach. If I do path computation and
have all these links that meet an application code I can choose to activate one
of those links and know that if I connect it to compatible tx
and rx it is going to work and that does mean taking
into account all the other things that is expect to be on the fiber as well. In conclusion, no you can’t switch black
links but can use the concept to set up connections.
Gabriele Galimberti: We talk about pre-calculation
impairments, while here we want to address post-calculation ones,
we calculate the feasibility of a path when the path is identified, so we need
all the info.
Lou Berger: Reading
the docs I see you keep alignment with the ITU-T data plane definitions and that’s
good to see. This is definitely a topic to be discussed in Orlando.
Malcolm Betts: There
is a lot of sensitivity on black links and how can be used as it is not clear
what can be done with them.
> 18 17:40
10 Title: Framework for GMPLS based control
of Flexi-grid DWDM networks
>
Draft: http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-18.pdf
>
Presenter: Ramon Casellas
Lou Berger: When
you say (in the slides) that there was an agreement after IETF84 are you
referring to an output of the meeting or of offline meetings? Because it was
not agreed during the CCAMP sessions
Ramon Casellas: Offline meeting.
Gert Grammel: I
think media channels are pretty straightforward to be used with flexi-grid,
what I was wondering is whether there is a correspondence in the ITU-T docs to
media channel or there is a different notion?
Lou Berger: This new terminology is coming straight from
the ITU-T.
Ramon Casellas: We would appreciate feedbacks on
the utilization of media channels and network media channels; setting up the
media channel as huge pipes and then setting up a network media channel is
worth it or could it be just enough to deal with one of the two entities?
Gert Grammel: My
concern is just related to terminology, just to avoid confusion.
Lou Berger: Generally,
in terms of what needs to be supported, if the data plane supports it you need
to cover it, otherwise don’t worry about it.
Ramon Casellas: The fact is that there is only
one level of switching at the lower layer but some people suggest it is better
to establish the media channel first and then the network media one.
Lou Berger: To me
it sounds like the old discussion on waveband.
Ramon Casellas: We’ll discuss more, including an
offline discussion tomorrow.
> 19 17:50
0 Title: RSVP-TE Extensions for GMPLS
control of Spectrum Switched Optical & OSPF extensions for support spectrum
sub-band allocation
>
Draft: http://tools.ietf.org/html/draft-wang-ccamp-gmpls-sson-rsvpte
>
Draft: http://tools.ietf.org/html/draft-wang-ccamp-flexigrid-wavelength-range-ospf
>
Presenter: Qilei Wang
> 20 17:50
10 Title: An SNMP MIB extension to RFC3591
to manage optical interface parameters of DWDM applications
>
Draft: http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-01
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-20.pdf
>
Presenter: Gabriele Galimberti
Lou Berger: The
third bullet in the final slide is very important. We need to make sure the
document is aligned with any new ITU-T recommendation in order to avoid
possible discussions.
Gabriele Galimberti: We reviewed it and believe it’s aligned, please all interested people review it also to see
if further readjustment is needed.
Lou Berger:
[poll] – How many have read the document? [A few]
–
[poll] – How many think this is a good
functionality to work on? [about the same].
Lou Berger: If
you think this is important functionality, please review and comment on the
list, even just to say that it’s useful work
> 21 18:00
10 Title: Extension to the Link Management
Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM)
Optical Line Systems to manage black-link optical interface parameters of
DWDM application
>
Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-01
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-21.pdf
>
Presenter: Gert Grammel
Lou Berger:
[poll] – How many think this is an
important function to have? [About the same as last document
– a few.]
[poll] – How many have read the document?
[Slightly more.]
[poll] – How many like the approach
proposed in this document? [same number]
[poll] – Anyone has reservations? [none].
Lou Berger: So
about the same result and response as the prior document: Please take a look
and comment, and if interested send comments to the list.
> 22 18:10
10 Title: Domain Subobjects
for Resource ReserVation Protocol - Traffic
Engineering (RSVP-TE)
>
Draft: http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-00
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-22.pdf
>
Presenter: Dhruv Dhody
Lou Berger: It
seems a pretty reasonable functionality. When you are going cross area, do you
have an area ID and an AS ID?
Dhruv Dhody:
Yes, you can include both or just one of them.
Lou Berger: It
could be useful to add some narrative to explicitly state that.
Ramon Casellas: We came to the CCAMP for the
encoding of the sub-objects, roles are specified in the PCE-P documents and
there is detailed text on this case.
Lou Berger: Does
this mean that you don’t see this being carried by RSVP-TE?
Dhruv Dhody: No,
It can be carried by RSVP-TE also. We’ll align the text in the two drafts.
Ravi
???: Policy
needs to be in place to cross domains. What about PATHKEY?
George Swallow:
Agree with you from a user point of view, but from a protocol point of view you
just say you can do these things.
> 23 18:20
10 Title: RSVP-TE LSP Route Diversity using
Exclude Routes
>
Draft: http://tools.ietf.org/html/draft-ali-ccamp-xro-lsp-subobject-02
> Slides: http://tools.ietf.org/agenda/85/slides/slides-85-ccamp-23.pdf
>
Presenter: George Swallow
Igor Bryskin: You can do all of this excluding links
and SRLGs. You have a draft to collect SRLGs, so you can peer
them.
George Swallow:
There is a WG draft to gather SRLG information. A UNI is a policy interface, we do not expect every deployment to have the
same trust level and not to open up their optical network to everyone.
Igor Bryskin: So you indicate which LSPs to exclude
from the path computation. You can do that only from the same node, right?
George Swallow: If
there was a PCE internal to the optical network and you had been informed (by
other means) yes, but without that functionality you are excluding yourself.
Igor Bryskin: There could be a situation in which
you create an LSP and then ask to go away from this LSP and the answer might be
“no”, if you do it simultaneously it doesn’t work, you
need to do it sequentially.
Rob Shakir: The LSPs are identified by RSVP
parameters, any interest in using an ID?
George Swallow: Managing
a new name space might be an issue.
Adrian Farrel: source
address, destination address and LSP ID should be sufficient
Lou Berger: Back
to Igor’s comment on why it this needed and your response being this just UNI,
this should apply also in the case of inter domain, maybe even inter-area in
some cases. In my personal read, I found it hard to parse the document
sometimes. I like the function but the text needs to be improved.
George Swallow: Is
that a requirement to fix to make it a WG document?
Lou Berger: That
was an individual comment.
Adrian Farrel: I
can remember when we closed the loop on the association object as an
alternative to this function.
Lou Berger: So
you would define a new association object type and that type would say: “don’t
match this association object”?
Adrian Farrel:
Yes, it is association, but for diversity.
Zafar Ali: XRO better
fits with this application because all the machines support XRO, if you do it
with the association you need to do more work.
Curtis Villazimar: For BRPC you are trying to
associate with an LSP that is from another ingress,
this is way I think the XRO works and the association object doesn’t.
Adrian Farrel:
Disagree.
Gert Grammel: Even
if the ingress is different, the originator is the UNI, so it should be a
single one.
Geroge Swallow: In one case is
the UNI, in the others isn’t. The point is that it is going somewhere we you
don’t have complete information.
Curtis Villazimar: Using BRPC and setting up two
different LSPs, when setting up the second you have collected SRLGs but for the
LSPs the mid-points have no association knowledge.
Lou Berger:
[poll] - How many think this is a useful piece of
function? [A good number]
[poll] - How many have read the document? [About
the same]
[poll] - How many think this is the right way to
go for the WG if we decide to support the function? [A little
more than half.]
[poll] - Does anyone want to express concern?
[No]
> Adjourn
18:30
>