CCAMP
First Session
Wednesday, March 30, 2011 (09:00-11:30)
- Please see the slides for CCAMP status
updates.
Adrian
Farrel: Speaking as AD I would appreciate another
LC on MIB [draft-ietf-ccamp-gmpls-ted-mib]; please also a
give heads up to the IGP WGs.
3. draft-ietf-ccamp-lmp-behavior-negotiation-02
Sasha: [slide 3] Format of BEHAVIOR_CONFIG bottom bullet. You cannot say
it must not be ignored. If you do not ignore it, then defining some behavior is
mandatory.
Lou Berger: We need to review the
naming convention. Perhaps just change the name of the field.
Someone requested further information at a previous meeting. Please address
that comment also. Seeing as the document is getting close to LC.
Lou
Berger: [To WG] please take a look at the document
and if anyone has some comment please send comments to the list.
4.
draft-ietf-ccamp-wson-impairments-05
Lou
Berger: The last hold up was based on the PCE
co-chair comments. If the PCE co-chairs are onboard we can move forward.
Julien Meuric: This was mentioned
yesterday during the PCE WG. We need to consider where the information is to be
stored. I propose we discuss this offline.
Lou Berger: This is an informatational document.
Eve Varma: Would the stabilization
be liaised back to Question 6?
Deborah Brungard: Yes, Q6 and Q12.
5.
draft-ietf-ccamp-wson-signaling-01
Fei Zhang: [5th slide]
For Option 2 for using this one, Label set should be defined to upstream. [RFC3473]
From upstream label set uses path message? Now you want to use the RESV
message.
Giovanni Martinelli: No.
Lou Berger: Can you walk us through
option 2. We need to understand option 2 better.
Giovanni Martinelli: There are two
proposals; the first expands the label set addresses the bidirectional issue
but uses the same wavelength, the second proposal, compared to the previous
text some extension is needed. There was a previous draft that discusses the usage of the two
objects. Instead of the upstream, label you use the upstream label set. Then
with a single signaling attempt you attempt one.
Lou Berger: So to summarize, the
final allocation occurs on the RESV instead of the PATH. So the upstream allocation
label is not selected until you get the RESV. There is an implication on the
allocation model.
Giovanni Martinelli: Yes.
Lou Berger: Are you advocating
Option 1 or 2?
Giovanni Martinelli: We are asking
for WG feedback.
Lou Berger: [Informal Poll] Who believes it's important to look option two? A few hands. Who believes it's not important to look option
two? No hands. Important to give something to the WG in order
to get WG feedback. Maybe update the old draft, or create a new one.
Giovanni Martinelli: Ok, maybe we
just talk on the list.
Malcolm Betts: Totally different
topic. Two unidirectional LSPs, typically at the physical layer, you want the
two to co-routed?
Lou Berger: This has always been
possible with GMPLS.
Malcolm Betts: Just a quick informal
update on Question 12. We need to look at application codes. We may need to
carry the application code. We are having another meeting in
6.
draft-ietf-ccamp-wson-info-11
Igor Bryskin: How do you use pool
and blocks in path computation? Can you put them in separate blocks?
Greg Bernstein: No.
Igor Bryskin: Let’s assume that all
the resources are identical in the blocks. This applies to optical impairments,
reachability. Let's consider two LSPs and the block appears in the path as a
sub object
Greg Bernstein: Now you're
describing signaling issue? We do not address the signaling yet, but we're
working on it.
Igor Bryskin: Suppose it shows as a
label in the path. The node selects resource from the block and uses it, is
that correct?
Greg Bernstein: Yes.
Igor Bryskin: Suppose you have two connections and you use
resources from the same block, how do you avoid confusion of the resources of
the LSPs.
Greg Bernstein: How do I manage
signaling restart among the peers and understand a particular resource in a
node that needs to be used. This was discussed in the signaling draft. This was
a sub-piece, like an associated piece which looks like an ERO at a particular
node.
Lou Berger: This was addressed in
the Otani label RFC [6205]. The document contains a field that indicates node
specific information. This can be used to identify the ITU grid value and local
node resources.
Igor Bryskin: This does not resolve
a RESV issue? What happens if a node is rebooted? Nothing points back to this
resource.
Lou Berger: Do you have the old
signaling message, if the nodes not using the node-specific bits, then it’s
a bad implementation. The labels have bits for identification of unique
resources mapped into resource block for advertisement.
Igor Bryskin: Maybe you put this in
the setup ERO.
Lou Berger: That was the attempt of
the node allocated bits in the label.
Adrian Farrel: Is anyone interested
in IS-IS for this? We do have a guiding principle that we try to get extensions
for both protocols. I understand if no one interested, then it’s hard to get
document out, but if you are interested in using IS-IS for GMPLS then I
encourage you to bring out the document before it lags too far behind.
Lou Berger: There is a lack of
interest in IS-IS.
Acee Lindem: We did not choose to
have a new top level because it was not available. It made sense to have a
separate top-level. There is a restriction on the node attributes that there
can only be one per node. We are looking at removing that for a lot of reasons.
Lou Berger: Remember at the last
IETF someone (Acee?) raised the question of LSA size (64k) and that sometimes
it was better to keep LSA size within an MTU, either way we need to accommodate
both those limits. Did you figure out what the best encoding was to address
that restriction? [OSPF documents, not the general encoding documents]
Greg Bernstein: I am not an OSPF
expert; but we always had the option of using multiple LSA instances. Our
assessment was we had enough mechanisms to stay under those limits.
Lou Berger: Is not clear to me if
OSPF can handle this, maybe you need a scaling section.
Acee Lindem: Also include frequency
of updates.
Pierre Peloso: Regarding the
multiple instances, can you document this case in the draft?
Acee Lindem: Quite simple really,
the information can be inserted into separate LSAs optical resource
computations (not TE) you can use concatenated LSAs.
Lou Berger: You also have to deal
with synchronization.
Acee Lindem: Yes, and it's not
possible if you're missing a piece.
Greg Bernstein: The main reason for
updating is to create (???)
Lou Berger: Please document any
issues with multiple instances and synchronization.
Pierre Peloso: It is more on the
specific way that applies to the specific extensions. How this would be
implemented. How it is explained in the documents.
Acee Lindem: If it’s abnormal to
split it. You can go over the MTU size and let IP split and assemble it.
Lou Berger: One nit, on having a
duplicate BNF and not having a reference. Having a reference to BNF is useful.
You should point to where the BNF is described [info model draft].
Igor Bryskin: It is possible to
split across LSAs. If you want to split switching matrix, each part can update
each piece of the matrix without touching anything else.
Greg Bernstein: Thanks.
7.
draft-ietf-ccamp-general-constraint-encode-04
8.
draft-ietf-ccamp-rwa-wson-encode-11
9.
draft-ietf-ccamp-wson-signal-compatibility-ospf-04
10 OSPF-TE Extensions
for WSON-specific Network Element Constraints
Igor
Bryskin: The previous presentation. Greg did not
mention resource group. Can you define what you mean by resource group?
Pierre Peloso: A resource group is a set of resource
blocks That all share the same
connectivity constraints.
Igor Bryskin: How about optical
impairments?
Pierre Peloso: We are not concerned
about optical impairments.
Igor Bryskin: Acceptable power, etc.
Pierre Peloso: If we want to be
future proof, then maybe.
Igor Bryskin: I would suggest
expanding resource group and include impairments. This needs to be broad.
Pierre Peloso: This is why we have
shared ingress/egress wavelength. The accessibility is described by different
TLVs.
Deborah Brungard: Igor, we were
careful to scope these documents so we do not include impairments.
Igor Bryskin: Right, all I am
suggesting is that we do not have to be too narrow because we can avoid
redefining items in the future. Resources that are mutually dependent, they
share the same properties. Some switches are contention or contention less,
once a frequency is assigned cannot be used elsewhere. It would make sense to
advertise this group.
Pierre Peloso: Do you assume that
impairments are from the same device.
Igor Bryskin: I have launching
power, acceptable noise. The path computation must need to know how to tune
different generators.
Lou Berger: Igor has mentioned that
we should be more flexible with regards to interfaces. We have the notion of
flexibility and generality in the current documents [WSON versus Generic]. Can
you talk about the split?
Pierre Peloso: With regards to
modification 2, instead of having a link set we are using a mixed set and
resources group ID. If I were to implement the solution today I would take the
resource group IDs and link identifiers. I can keep a link set. I rely on the
LSA, link and local identifier. I will refer to link to check my connectivity
matrix. In this solution the split does not change. This fits in with the
generic document.
Lou Berger: If we decide to go in
this direction we need more specificity. What about modification 1? Does it
change the split?
Pierre Peloso: No impact on the
split.
Greg Bernstein: Any new
functionality out of these changes? Option two changes the split; it changes
the pools that were WDM specific without giving me additional functionality.
That’s changing a decision, modification number 1, you have resource sets this
allows grouping but I am not sure on the added features you would gain. This is done at the info draft not the
encoding draft; the encoding draft may require a lot more modifications.
Consider resource groups and links are two different things and need to be
separated.
Young Lee: When you mix, you need to
provide a delineation factor between link-set and label-set? I see no new
functionality added and I am not sure this is even feasible. If you feel that
something is broken with the current draft you should indicate what the issues
are. I am not sure, it’s up to the WG to invest whole new ways of doing things
Lou Berger: [Slide 5 - reduction of
elements] do you [Young Lee] accept the analysis or disagree?
Young Lee: Not clear, depends on
resource blocks and transparent nodes are not applicable.
Pierre Peloso: Good points,
regarding delineation. I do not understand why this prevents the algorithm from
working. Some of the interfaces are linked to external links. Regarding Greg’s
points, the question of the split between generic and specific [WSON], I am not
sure how this solution breaks it.
Lou Berger: For me, ISCD is a good
example of a single object, in includes a generic part and the opportunity for a
technology specific part. This is what I would call an example split between
generic and technology specific.
Young Lee: This breaks that. These
are two different properties. I do not how you can delineate. If you are saying
something is broken, we can fix it.
Lou Berger: The comment is it’s not
broken, it’s sub-optimal. We do this already in ISCD. Specificity in the
proposal is required in order to really understand what is being proposed.
Julien Meuric: ISCD is a good
example. When you substantiated inside that generic structure I feel it is in
line with your ISCD.
Greg Bernstein: When you mix up
linked set with. Label set. That’s why we separate it.
Lou Berger: Are we interested in
looking at this further. Is this a direction the WG would like to investigate,
or not investigate? [POLL] A significant number of people would like to hear
more. Pierre, you need to create a
document for discussion. Do this quickly please as this is holding up the
documents.
Greg Bernstein: This has been
holding up the documents for quite some time. We need to quickly establish this
is a valid issue.
Lou Berger: Agreed. There is
interest in working group in continuing to look at the issue, but we need to
resolve this quickly.
12 WSON Wavelength
Property Information
Deborah
Brungard: For clarification there is no definition
of wavelength service in ITU, for the premise of SLA verification.
Malcolm Betts: I was going to cover
that Deborah. Also what’s the difference between this and restoration priority
on LSP?
Moustafa Kattan: This is more WSON
specific.
Malcolm Betts: Why is that
different? For instance I have 10 LSP is that I want to recover one of those is
has a higher priority, what's the difference?
Moustafa Kattan: Good point, we will
look at this.
Lou Berger: I agree we have
semantics for prioritization. Maybe you are asking to include label level
advertisements; we do not have allocated priority. This could go to the OSPF
encoding document also good input for general constraints model. Get with the
editors of those documents to discuss include that one piece [priority].
Eve Varma: I was going to ask the
previous speakers, how is this related to OC/WDM layer from OTN.
Moustafa Kattan: It is independent;
the restoration would happen on any wavelength regardless of traffic type.
Eve Varma: When you discuss managed
objects you need to consider how this fits into the standardized data plane.
Igor Bryskin: Wavelength path
computation to support pre-emption you obviously need to know lambda channel
priority available. To use priority reservation of restoration is trickier, if
the link is cut when services have been generated from different nodes, it is
difficult to prioritize which services should be restored first. You have
created scenarios to justify your advertising of priorities for wavelengths,
you do not need this pre-emption provides priorities, even without restoration.
Existing priorities can be used to set up a reservation priority.
Moustafa Kattan: Yes, but if you
have a directionless node and a fiber cut you could restore around this
location.
Deborah Brungard: Let’s move this to
the list.
Malcolm Betts: This discussion is
scaring me.
13 A framework for
Black Link Management and Control
Malcolm
Betts: I was alarmed at title.
Ruediger Kunze: Yes, once you read
the abstract the document it make sense.
Malcolm Betts: I did read it and you
raise some important management points, at the control plane and management
plane. Maybe we need to step back and understand the protocol neutral module.
We also need to consider application codes. I encourage you to bring this into
the ITU to get the equipment work done. We are meeting in Chicago in June, we
can progress this then.
Kam Lam: With what Malcolm said,
once the functional equipment model is defined we can talk about management and
control. In the management area we need to start with a management requirements
first, then the protocol neutral information module for management. Then we can
talk about specific management protocol, such as SNMP, COR BA, etc. I also see
there is a companion document.
Deborah Brungard: Kam, can we
continue this conversation during the next presentation? [Yes]. I agree the
title it very confusing. You need to update. You need alignment with ITU
technology as well. We deal with control plane for standard data plane
interfaces and not proprietary interfaces.
Eve Varma: I was going to clarify
control plane, you are referring control of parameters of receive and transmit
which is different from path setup/teardown. This needs to be further
clarified, you also need to tie in Application Codes (Q6.) aspect.
14 A SNMP MIB to
manage the optical parameters characteristic of a DWDM Black-Link
Malcolm Betts: Repeat of comments
from last contribution. We need to look at the equipment model first in the
ITU. One thought that occurred to me is the signaling aspects; this is
analogous to the OAM configuration.
Lou Berger: I agree with those
comments.
Kam Lam: We need to understand the
parameter, is it the optical channel? This needs further study, and then we can
decide how to fit this into the protocol independent management model. The SNMP
MIB extension will be a lot easier, just like RFC5591 (?).
Lou Berger: Asking the AD [Adrian
Farrel], where should OAM control MIBS end up?
Missed Name [DT]:
Should this be done in ITU or portion shared with IETF?
Deborah Brungard: CCAMP follows ITU
data plane, if there is a gap you should identify that in SG15. Then we can address it here, we only point to data
plane standards.
Malcolm Betts: Thanks, I agree.
Adrian Farrel: It is important to
get the data plane specified by the people that own the data plane, before we
move ahead [within the IETF].
Gabriele Galimberti: will it be
helpful to update in late July [IETF81] what was discussed at the ITU?
Adrian Farrel: Yes.
Missed Name [DT]:
We have well defined application codes.
15 Framework for
GMPLS and path computation support of sub-wavelength switching optical networks
Lou Berger: We like experimental.
Without a standard data-plane we can only consider experimental.
Igor Bryskin: Sub-lambda is
important; the only thing is what is missing now. Why do we need this work?
Lou Berger: Can we take this
offline. Take the questions to the list
16 Updates to ASON
Routing for OSPFv2 Protocols (RFC 5787bis)
Lou Berger: We like the progress on
this. In private conversation, we were told this could be done quickly.
Assuming the group here feels this is a good. [Poll] Good showing. We would
like to see the update with the requirements table, we will issue a poll.
Deborah Brungard: Please note it
does not have to be polished it is just a foundation.
17 Applicability of
GMPLS UNI
[Slide 3]
Lou Berger: That first bullet is false [slide 3 - UNI Address space].
Deborah Brungard: The abbreviation
needs to be explicit. You should refer to exactly what you're stating.
Lou Berger: This point is often
confused. In the details you specified correctly, however the slide bullet is
incorrect.
Adrian Farrel: The working group
chairs are confused and should read RFC4208 CN is a node not a network.
[End of slides]
Nurit Sprecher: There are many scenarios
that need to be fixed and updated. You also mention this is an applicability
document of the GMPLS UNI, but the UNI that I remember refers to not just an
overlay model. This is much wider than an applicability document. I also have
some additional comments on the protection model that places restrictions on
the core network. More work is needed.
Curtis
Villamizar: I think to be useful to have a
deployment survey of GMPLS UNI and ASON call connection work.
Lou Berger: Are volunteering to do
the work?
Curtis Villamizar: Yes, it would be
very easy.
Julien Meuric: It like the draft
presentation it reminds me of when I had to explain similar items in my own
company. I like the connection with Black Link control as well. Do you see
yourself expanding this document to cover UNI to black link applicability?
Fatai Zhang: Yes, we can consider
this.
Deborah Brungard: The address part
needs to be cleared up, especially in your examples where you combine IPv4 and
IPv6 on a link. There has been confusion in the industry and this document
doesn't help. As an operator if you're using the UNI with a proprietary control
plane management plane then RFC4208 supports this, say you may want to include
that scenario as well.
Fatai Zhang: By examining RFC4208 I
think we need to work with the editors and discuss the restrictions. This is to
avoid description confusions.
Lou Berger: As part of the cleanup,
keep in mind the protocols across the UNI and how they are used across the
core. The existing UNI only discusses what's going on between EN and CN [across
the UNI], and not how the UNI is supported across the core of the network. You
should consider separating those two pieces and clearly delineate what is
within the scope of the UNI and what is within the scope of the core network to
support the UNI.
Igor Bryskin: I agree with what you
[Lou] said. UNI allows independent address spaces client and core networks,
this does not say how you can do that. For instance it would be useful to have
considerations as to what you would use between clients and core network based
on the UNI.
Fatai Zhang: We discussed deployment
considerations not specifications.
Lou Berger: The UNI makes no
restrictions as to what happens in the core.
Fatai Zhang: Maybe I need to copy
text from RFC4208. It says “it must share address space”.
Lou Berger: “on the link”.
George Swallow: I wrote the
document. It is a restriction of IP, you could use either IPv4 or IPv6. It has
to be a routable address. So you need to use the same address cross the link.
Within the draft there are two options, the first is the core network has one
addressing plan and all the UNI endpoints have an address from the same space.
The second option is a VPN service, a set of interfaces can then share.
Igor Bryskin: To George, would it be
worth having a document that describes how you can create VPNs both for routing
and signaling perspective?
Lou Berger: Yes, they’re called:
L1VPN, L2VPN and L3VPN.
George Swallow: This is an old
document and there may be a need to update it, but not based on suggestions
here.
Missed Name [DT]:
I would like to thank the authors are doing this work considering the amount of
time the technology has been out there. It is a good thing to have the
applicability and considerations discussed. I would also second Nurit; you
should consider other network models not just overlay.
Fatai Zhang: We will add more models
and scenarios.
CCAMP Second Session
Thursday, March 31, 2011 (09:00-11:30)
1. Administrivia
- Lou Berger provided a reminder on
presentation etiquette and asked people to consider that their allotted time
should also include their Q&A section.
18 GMPLS RSVP-TE
extensions for OAM Configuration
draft-ietf-ccamp-oam-configuration-fwk
draft-ietf-ccamp-rsvp-te-eth-oam-ext
draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext
draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext
Lou Berger: there was some
discussion at and from IETF 79, specifically a split of some sort although I am
not sure if that was needed. Was there any conclusion? You had also had an
action to review the latest MPLS-TP requirements.
Attila Takacs: the discussion was
framework or extensions, the outcome being we changed the title. The MPLS-TP
requirements are covered, although one item not covered is the MIB
configuration and what parameters are required. We can address this, if needed,
at some future point.
Deborah Brungard: how is the SDH
OTN, is that stable?
Attila Takacs: this does still need
to be covered we may need extensions. The plan is to discuss this before the
next meeting and prepare for LC.
Deborah Brungard: there is a concern
with basic framework document, that there is something that you may want to
move into this document, from one of the other more generic documents. We were
wondering how close the OTN and TP are to being stable. We would like to avoid
moving any additional items into the generic document
Attila Takacs: there are no
functions that should be moved. I feel this document covers all general items.
Deborah Brungard: [Poll] how many
people have read the documents? [Results] how many feel the documents ready for
Last Call? [Results] do any of the MPLS-TP folks have any objections or
questions?
Lou Berger: please do the
update, we can then see where we stand and decide which documents to move
forward together, or separate them.
Attila Takacs: yes, keeping as set
[all four documents] seemed good.
Lou Berger: title is fine, but the
draft [file] name is a little misleading.
19 Usage of The
RSVP Association Object
Julien Meuric: PCE chair hat on. I
know how painful it is for multiple documents for a small process or extension.
If you believe it would be better split and it’s not too much work then split
usage and extension.
Lou Berger: the biggest issue is splitting
the document, its stable and we could quickly have two documents.
Igor Bryskin: to have a separate
document on usage is a good idea. We have a few use cases already. Another use
case I received is nested LSPs and dynamic FAs.
Lou Berger: so two things. 1. You
would like the split. 2. You have a new application. If you have a new
application, please review the next version and see if it covers your
application.
Ping Pan: I like having two
documents, one for usage and one for extensions.
Deborah Brungard: Does anyone oppose the split? No.
Lou Berger: ok, I will split. The
Informational (usage) document can be LC quickly. The second document will be
extensions and I think we need feedback, because we had a big change recently,
before progressing.
20 RSVP-TE
Extensions to Establish Associated Bidirectional LSP
Lou
Berger: any questions? No questions are fine. The
requirements of this document come from TP. This is identified as needed
extension and is within scope of the WG. One question for group, is the draft a
suitable foundation? I see a clear number of hands showing support, with no one
opposed.
Lou Berger: a technical
question, upstream TSPEC instead of a new TSPEC. It would be good to have
Attila’s input on compatibility with asymmetric BW rfc/bis.
Attila Takacs: I'm not entirely sure
that we can use the same fields this case.
Lou Berger: I think this is also
question for existing implementations. As to whether or not they would get
confused by having the upstream TSPEC, in a path message that does not contain
the upstream label. The BNF definition requires the TSPEC present if the label
is also present. So what would happen to an existing implementation receives
path message, which contains the TSPEC but not the label.
Attila Takacs: for this use case we
may need a different field. I will need to check and comment on the list.
Lou
Berger: Yes, let’s follow-up on the list.
21 Framework for GMPLS and PCE Control of G.709 OTN
Lou
Berger: one minor comment
that there are some individual drafts that have some good content, which you
may want to blend into this document. I will point these drafts out later in
our session.
Rajan Rao: I think the link bundling
scenarios should be covered
Fatai Zhang: for link bundling FA
approach, based on network planning, we need to continue discussions as we do
not have agreement or consensus.
Rajan Rao: for link bundling we need
to capture those scenarios and clarify.
Fatai Zhang: the document discusses
the link bundling capability, but not the details of mechanisms of how it
should be supported. There are multiple approaches that treat link bundling
differently.
Rajan Rao: so we need to have link
bundling requirement?
Fatai Zhang: it's already in the
document; we just do not describe how it is done.
Lou Berger: do you believe they have
text in existing drafts that is relevant?
Rajan Rao: it's probably only
partially there.
Lou Berger: I suggest you propose
text, send to list and we can debate if it’s in scope.
Julien
Meuric: there is a PCE section and with my PCE
chair hat on, you mention RFC5440 (base protocol), would you please reference
the PCE GMPLS extension for consistency.
Fatai Zhang: good point.
Xihua Fu: just a suggestion that
this framework document, you could use the first number of the timeslot which
the service occupies as the TPN number.
Fatai Zhang: I do not understand.
Oh, this was discussed in IETF 79, you cannot do this ODU2 into ODU3 we cannot
use first number to identify TPN information. Signaling draft describes the
issue in more detail.
Lou Berger: this is framework
document, so do not [unnecessarily] constrain or even describe a solution.
22 Information model
for G.709 OTN
Rajan
Rao: the text in the document should that be a
requirement or information?
Sergio Belotti: the intent of
document is to align with requirements in framework and what information is to
be considered.
Rajan Rao: with regards to timeslot
granularity you will not know until the first service arrives.
Malcolm Betts: the timeslot
negotiation is described in G709. As soon as you activate the link, the nodes
negotiate and decide on 1.25G or 2.5G time slots. There is nothing the control
plane can do about it.
Rajan Rao: which field indicates
this, MSI?
Malcolm Betts: no, it is negotiated
before that. It's described in G709.
Rajan Rao: the payload type as part
of MSI structure, which is used for service up and what is the timeslot
granularity. The real question I have is, where there is a disparity between
two ends of TE link, is the requirement that states “what should the node do?”, should they go-ahead and advertise the ISCDs? Or should
they wait until they figure out which timeslot granularity to use.
Sergio Belotti: we can discuss your
doubts off-line.
Lou Berger: Malcolm mentioned in
G709 the auto-negotiation is required and occurs as the link comes up. If this
is the case then the nodes are aware of what to advertise properly to routing.
We do not need to discuss how that auto-negotiation occurs in this set of
documents, as long as the document reflects accurately what is occurring at
G709 and what actions are taken based this. So please take a look at the G.709
documents make sure your document accurately reflects what is happening during
negotiation and how this is advertised to routing.
Sergio Belotti: ok.
Fata Zhang: can this doc be accepted
as a WG document?
Lou Berger: how many think this info
is useful to work on G709 info module, in general? Yes, no? The WG clearly thinks
it needs such a document. How many thinks a good foundation for the WG’s
activities. A good number.
How many think it we need to wait. Just
one. There is clearly overwhelming
support to take this forward, so we’ll take it to the list.
23 TE Extensions to
OSPF for GMPLS Control of Evolving G.709 OTN Networks
Igor
Bryskin: do you advertise switching limitations. So
basically you have three signals, of specific links.
Daniele Ceccarelli: advertisers are
interface based.
Igor Bryskin: but you may have
switching limitations, a specific switching type but only on a specific links.
You assume you can switch to any link on this node that supports a capability.
Daniele
Ceccarelli: This is an implicit constraint.
Igor Bryskin: no, you can build a
switch with different colors. In this case you can switch between interfaces
but not between the cards.
Rajan Rao: your question is, what are you going to advertise based on switch fabric
limitations?
Igor Bryskin: right.
Rajan Rao: a few methods exist. 1.
If they support LMP it’s easy you advertise node switching capability. 2. Use a
management system.
Igor Bryskin: this is internal node
capability, not ends of link. This is a general problem.
Lou Berger: a couple of items, our
intent to make a split in WSON between generic and specific, was
exactly to address this type of case. So we have a way of advertising
constraints including node constraints in a generic fashion. So the hope is
that the WSON work is generic enough to cover this type scenario. The second
point, what you described is not covered in the framework document at all. If
you believe this is a requirement please propose some text for the framework,
and then we can discuss its currently in scope. As a chair I’m not saying yes
or no, simply stating that you need to propose it for WG discussion.
Igor Bryskin: it could also be based
on signal type. WSON may have different switching limitations; it may be per
lambda based.
Lou Berger: yes this is why we have
technology specific and generic parts.
Igor Bryskin: also why do you need
payload information? Why would you constrain a particular path computation to a
specific payload?
Daniele Ceccarelli: are you
referring to the link component parts?
Igor Bryskin: IMCD, GPID.
Daniele Ceccarelli: at the moment it
has nothing to do with what is being carried.
Lou Berger: maybe you’re using the
wrong field. We do not currently have path computation based on
GPID. You should review it.
Daniele Ceccarelli: the scope of
that field is just to indicate the granularity.
Igor Bryskin: I disagree. The
hierarchy is a big question on whether you should advertise in some
hierarchical method for building a network, from top to bottom and bottom top.
I think you should cover a simpler case, single stage provisioning, and if this
proves to be necessary for on demand link creation for lower connections, that
would be fine. You simply do not need to constrain path computation on the
payload.
Daniele Ceccarelli: What do you mean
payload? The lower order ODU, what is being carried over it?
Igor Bryskin: I am saying the GPID
information cannot be used for path computation.
Lou Berger: When you document this
there should be no reference to GPID.
Julien Meuric: if you really feel
something missing you need to define and explain what’s needed. It’s not
obvious to me.
Daniele Ceccarelli: let's talk about
multiplexing hierarchy for the moment, but something new is needed then we can
discuss it later.
Lou Berger: as you document this
keep in mind separately documenting single layer path computation, and what's
needed for dynamic FA creation. In the past we have separately documented these
things as there are differences with vendor offerings. This precludes
implementations that only do the one without the other. But note, I'm not
saying the information must go to different objects.
Daniele Ceccarelli: this approach
could work we just have to make sure there is a
connection between the document.
Eve Varma: I was going to say that
you do this after you have the complete solution. So you know it's coherent and
it works, they can be organized such better understood. This used to make sure
protocol does not place limitations and constraints on types of networks that
can be built.
Lou Berger: I am open to this, we
just want to avoid getting confused about what functions we have to have.
Having separate documents helps eases conversations and avoids confusion. I
defer to authors of the document how they best want to present information.
Eve Varma: I was talking subsections
in the same document, not separate documents. I would be concerned if this work
was split into separate documents. In the past we had situation where if you
had an ODU service, you can only carry on infrastructure at that layer. So the
transport network infrastructure was constrained, we should avoid this kind of
thing occurring as we move forward.
Lou Berger: I completely agree we
cannot limit data plane capability based on a control plane constraint. I was
just saying that the part relevant to dynamic FA creation could be separated
out. So this is a little different to what you're stating.
Sergio Belotti: the problem is when
we started updating the OTN routing document, and taking into consideration
multistage multiplexing capability, we faced separating the single stage
solution from the document. We decided to have a single document with separate
sections which discuss the two solutions, so in principle this has already been
explained in the framework and information model. Our thoughts were it was
better to have one document, with two separate sections.
Lou Berger: ok.
Rajan Rao: I agree with Lou’s
comments.
Julien Meuric: of course we do not
want control plane to limit node capabilities. For deployment I do not think
corner cases should drive solution. Homogenous deployments can do the job, and
then have additional extensions for corner cases. Trying to solve everything
initially causes complexities.
Lou Berger: very happy to see the
work converging, we look forward to future updates.
Rajan Rao: shall we take document as
WG document?
Lou Berger: we do not have a
document to take forward. Once we have the document it is fine to ask the
question again. Also it is perfectly okay to have to have multiple solutions in
single document. You can then state to the working group where we don't have
consensus, and this can be discussed within the working group.
Fei
Zhang: I am confused with GPID term, as mentioned
on mailing list the usage is different. The label indicates multiplexing
hierarchy.
Lou Berger: we covered same
discussion in routing. We should use same term we discussed earlier and there
is an action for the authors to come up with new name.
Cyril Margaria: it is not clear to
me that this optimization is worth it. Which scenario would you want to
restrict the usage? This feels complicated; it works only between certain
points. What justifies this optimization?
Rajan Rao: a
typical case would be: Node A support switching at the ODU one layer, but the
interface does not support this. The interface at ODU 1 has to go into ODU 2, to go into ODU 3. At all the nodes
you need to remove ODU 1 from ODU 2. [Daniel
King: did I miss a comment?]
Cyril Margaria: if I follow this, it
does seem a general case. So if I have G709 equipment, how often will I see
this restriction?
Rajan Rao: this is not a corner
case, this is a possibility.
Cyril Margaria: okay I think we can
discuss this more off-line.
Lou Berger: follow-on question. In
this case you have a single LSP that covers ODU 2 to ODU 3, as well as ODU 1 to
ODU 2. Let's say that you want to send another ODU 1 over ODU 2, what do you
do?
Rajan Rao: we signal the same thing.
Lou Berger: how do you indicate that
it's reused?
Rajan Rao: it will specify which ODU
I want to use, and it will get reused.
Lou Berger: this is an interesting
optimization of the hierarchies. What you're proposing is what we use FA [H-LSP]
for. I think the question that [Cyril mentioned] is this something we want
optimized, is a good question.
Rajan Rao: this is specifically for
point to point links.
Lou Berger: the description doesn't
limit that scenario.
Rajan Rao: it cannot go multi-hop.
It's meant for point to point links with multiplexing restrictions.
Igor Bryskin: so in this scenario
node A and B are adjacent in ODU 1 and ODU 2. Now you want to switch ODU 1, but
this is not possible unless you create ODU 2. Why does routing have to know
about this? Why not just advertise the link between node A and Node B, why is
this a problem of routing and signaling?
Rajan Rao: we need to advertise a
specific link can switch ODU1 and ODU 2, when signaling I need to single two
stages.
Igor Bryskin: why? You create ODU 2
locally, and then within the ODU 2 you allocate ODU 1. Then the next node will
do the same thing.
Rajan Rao: you are assuming the
operator will pre-establish ODU 2s.
Lou Berger: good discussion, but we
are way over. We look forward to more discussions in the future.
25 GMPLS Signaling
Extensions for G.709
Igor Bryskin: I agree with what
you’re saying. You should also consider virtual FAs; take away commitment of
resources until they are necessary. You would not run out of fat pipe resources
to meet small service requests.
Deborah Brungard: We need more
discussion on the list, especially between meetings. A few points, seemsstill missing scenarios in the framework document;
this is for both signaling and routing. We need more information to help with
the discussion of solutions. On your request for the chairs to decide, it’s not
a chair decision, it needs to be a consensus view of the framework document.
Also do we need to support the case of multistage multiplexing point-to-point,
or is this a corner case? Lastly if a port card supports one timeslot
granularity for one layer, assume will supportfor all
layers? We can also liaise to ITU to help us with this type of question
(equipment modeling).
Lou Berger: If you have a function
that’s not in framework please propose framework text to the list.
26 Signaling
Extensions for the evolving G.709 Optical Transport Networks Control
27 GMPLS-based
Hierarchy LSP creation in MRN/MLN
Lou
Berger: this draft and the next draft are very
similar. Can you work together to come up with a single document?
Fatai Zhang: this draft is generic,
I'm not sure if the next draft is generic.
Lou Berger: it would be good if you
talk to them.
Lou
Berger: both drafts describe background material on
function, which should be in framework document. Please also see if you can
work together on a combined draft. It would be much easier to make a joint
document a WG draft.
29 GMPLS extensions
to communicate latency as a traffic engineering performance metric
Acee
Lindem: what are the units for base numbers,
latency etc. Is it 32 bit integer, floating point number, etc.?
Xihua Fu: still to be decided.
Lou Berger: I made a private comment
regarding the express path draft which was presented in RTG and other WG’s this
week., and which had latency being passed as a
parameter. You also seem to have the same requirements. Our AD, do you have an
opinion on where this work should take place?
Adrian Farrel: I do not like to see
protocol extensions for things that do not describe what is being measured,
what units, how to combine, hop-by-hop, etc. I think we need to back off and
talk to ops ADs.
Lou Berger: I’d also like to suggest
we discuss the model of advertisement in the Routing WG first. Remember the
ARPANET meltdown?
Adrian Farrel: the authors need send
me email to remind me to talk to Ops ADs so we can nail down the work.
30 RSVP-TE
extensions for dynamic hostname traversing OSPF routing areas
Igor
Bryskin: I am glad Acee is here, this should be
solved in Routing not in Signaling.
Lou Berger: RFC5642 can fix the problem.
Acee Lindem: Scoping of routing
information LSA allows this to be solved. The only advantage of this is every
router in the domain would have to get router information LSAs. You would
choose what scope you want or if you want to limit to a specific area or AS
wide. Actually it is RFC 4970 that states that the flooding scope of the OSPF
RI (Route Information) LSA is a local policy decision.
31 RSVP-TE
Extensions for Configuration SRLG of an FA
Igor
Bryskin: two things, what happens after you
establish an LSP and someone adds an SRLG on a transit link?
Oscar Gonzalez de Dios: then you
have to recollect it.
Igor
Bryskin: but this is nontrivial. This is a general
problem, how you propagate modified information along the path.
Deborah Brungard: Igor, I also
agree, I was also going to raise the operational concerns and scalability. This
is an FA; you may have protection switching at a server layer. It is very
difficult to coordinate the identifiers for multiple layers. We need more
information on the operational aspects of this.
Igor Bryskin: I understand exactly
the motivation; we have the same issue to provide SRLG information to the
higher layer. My second question is what happens if you assign nothing to the
link, you still need to provide information to the higher layer. If you had two
FAs sharing the same link and you have no SRLGs assigned to the link?
Oscar Gonzalez de Dios: nothing.
Igor Bryskin: you need to provide something
at least the link ID.
Deborah Brungard: okay we are
running out of time, please discuss further on the list.
32 Supporting
Shared Mesh Protection in MPLS-TP Networks
Lou Berger: This work belongs in the MPLS
WG group as it is a data plane/OAM definition.