IETF-76 CCAMP Meeting Minutes
First Session
Wednesday: 1300-1500 (1pm-3pm) Afternoon Session I
Slides
Administrivia
WG status, RFCs,
drafts, milestones, charter, errata
ITU-T/OIF Report
Framework for
GMPLS and PCE Control of Wavelength Switched Optical Networks
(WSON)
Routing and
Wavelength Assignment Information Model for Wavelength Switched Optical
Networks
Routing and
Wavelength Assignment Information Encoding for Wavelength Switched Optical
Networks
WSON Signal
Characteristics and Network Element Compatibility Constraints for GMPLS
Signaling
Extensions for Wavelength Switched Optical Networks
OSPF Enhancement
for Signal and Network Element Compatibility for Wavelength Switched Optical
Networks
A Framework for
the Control and Measurement of Wavelength Switched Optical Networks (WSON) with
Impairments
OSPF Extensions
in Support of RWA in WSONs
Framework for
GMPLS and PCE Control of G.709 Optical Transport Networks
Traffic
Engineering Extensions to OSPF for GMPLS Control of Evolutive G.709 OTN
GMPLS Signaling
Extensions for the Evolving G.709 OTN Control
Agenda
Administrivia
Presented by CCAMP Chairs
- No agenda change.
WG status, RFCs, drafts, milestones, charter, errata
Presented by CCAMP Chairs
- Co-chairs
are making better use of our web tools.
- CCAMP
supplemental pages have been moved to Trac, see http://tools.ietf.org/wg/ccamp/trac/wiki.
- Trac is
being used to track document issues and status, see http://tools.ietf.org/wg/ccamp/ and http://tools.ietf.org/wg/ccamp/trac/report/3.
- Both the
Wiki and Trac are open and can be modified. Login is required, any edits will
be tracked.
- VCAT Support (draft-ietf-ccamp-gmpls-vcat-lcas-07.txt) is ready for
Last Call.
- Two documents are not on the agenda this
week: draft-ietf-ccamp-gmpls-g-694-lambda-labels-04.txt and
draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02.txt
Lou Berger: Do the authors
have any comments on these drafts?
Wataru Imajuku
(Co-author of draft-ietf-ccamp-ethernet-gmpls-provider-reqs-02): I apologize for the delay. Three of the two authors have no
intention of progressing. I have to step down as well. We are searching for
someone to take over the document.
Lou Berger: We appreciate the work
and effort from the authors. If there are people interested in joining as
authors or editors, please contact the authors or chairs.
- Several Communications sent/received. Four ITU Liaisons, assorted OIF
Liaisons, MEF and IEEE communications will be sent when ready. Please only use
the mailing list to submit comments.
- ASON list has been closed by AD due to
lack of activity.
- Errata 1: RFC 4872 – Editorial bug, no
discussion or objections. The plan is to ask the AD to resolve the errata.
- Errata 2: RFC 4207 (LMP) - How many
<TRACE> objects may be present on a <TraceMonitor
Message>? The BNF in section 4.1.1 currently implies just one. But the text
could be interpreted to many more than one. This requires an editorial fix as
per the discussion on the mailing list.
ITU-T/OIF Report
Presented by Lyndon Ong
- SG15 Liaison on OTNT Work Plan, a
description of work in various organizations.
Deborah
Brungard: We have cycled this document several
times.
Lyndon Ong: This in an updated version.
- WP2 Liaison on Lambda Switch Capable
Equipment
Deborah
Brungard: Regarding G.697, this is the reference
document for CCAMP’s proposal for the labels.
Lyndon Ong: Ok.
- OIF Liaisons
Lou
Berger: On your OIF slide, where you mentioned
because the ASON was experimental, no code points were assigned. There is no
issue, because of experimental protocol status, it just not been assigned.
Early assignment is possible, but was never requested.
Lyndon Ong: In previous versions of
the document code points had been suggested.
Lou Berger: Some authors include
suggested values, the IANA section will mention what is necessary and what IANA
request will be made.
Lyndon Ong: I think the document
mentioned that code points should be experimental among the group of
implementing, as opposed to IANA request.
Lou Berger: I am not sure what is
going on there.
Adrian Farrel: The OSPF registries
explicitly say if you have experimental document assignments will not be made
from the registry. What the document does say is that people experimenting
should get together and use the experimental ranges that they are going to use.
Lou Berger: I am quite surprised
that the OSPF registry does not allow experimental assignments – my mistake.
Adrian Farrel: I think they are
worried about experiments being performed in the Internet. The ADs are looking
at this, but we are where we are.
Framework for GMPLS and PCE Control of Wavelength
Switched Optical Networks
(WSON)
Presented by Greg Bernstein
Routing and Wavelength Assignment Information Model for
Wavelength Switched Optical Networks
Presented by Greg Bernstein
Routing and Wavelength Assignment Information Encoding for
Wavelength Switched Optical Networks
Presented by Greg Bernstein
- The previous three documents presented by
Greg Bernstein are WG documents.
Lou
Berger: We had some offline discussions regarding
these (three WG documents) documents. Can we review these?
Young Lee: We had some offline
discussions between the working group chairs and the editors of the documents.
We agreed to put back signal compatibility into the RWA framework. In the
information model and encoding drafts we need to state which pieces are
generally applicable and which are WSON specific. Is
that ok?
Lou Berger: That’s fine, I just wanted to make sure the working group knows
what the plans are for the three working group documents.
Greg Bernstein: So, we are not going
to LC these documents just yet. We have some new content to add.
WSON Signal Characteristics and Network Element
Compatibility Constraints for GMPLS Presented by Greg Bernstein
Greg
Bernstein: We are looking to merge most of this
content into the framework document.
Signaling Extensions for Wavelength Switched Optical
Networks
Presented by Greg Bernstein
Lou
Berger: Is it likely that this work will be
impacted by the other document reorganizations?
Greg Bernstein: No, not really. The
encoding mechanisms may change, but the need will remain.
Lou Berger: I would feel more
comfortable if we deferred the question [WG document request] once you complete
the reorganization of the other drafts first.
Greg Bernstein: Okay. We do want
feedback on the encoding issue, signaling and restart.
Lou Berger: People can still discuss
this on the mailing list even if it is an individual submission.
OSPF Enhancement for Signal and Network Element
Compatibility for Wavelength Switched Optical Networks
Presented by Young Lee
Young Lee: We request that
this document becomes a working group document.
Lou Berger: Who has read the
document?
Show of hands – a good
number
Lou Berger: Who would
adopt this document?
Support – about the same number
Against – very few
Lou Berger: Those present
clearly feel this document is a good basis for activity in this area. We will
confirm on the list.
A Framework for the Control and Measurement of Wavelength
Switched Optical Networks (WSON) with Impairments
Presented by Greg Bernstein
- Next Steps/Issues
Greg
Bernstein: There was some feedback from the ITU. I
need to prepare some text and submit to the list.
Deborah Brungard: The ITU feedback was based on various ITU discussions and
agreements among the different questions involved. It came to us [CCAMP] as a
clarification.
Greg Bernstein: I was not there but
I guess various parties discussed it.
OSPF Extensions in Support of RWA in WSONs
Presented by Fatai Zhang
Fatai Zhang: We request this draft becomes a working group document.
Lou
Berger: Given the earlier discussions with the info
and encoding document, it makes sense to see those updates and match this
document. At that point we should be ready to look at the request for this to
be a come a working group document.
Lou
Berger: We are moving from the WSON portion of the
CCAMP session to OTN.
Framework for GMPLS and PCE Control of G.709 Optical
Transport Networks
Presented by Fatai Zhang
Xihua
Fu: In terms of G.709 the interworking between 2.5 and 1.25 could be an
automatic adaption. This means that coordination is necessary between the end
links. If you want to correlate the tributary slots between two ends we can use
the IGP database. I am not sure it's necessary to introduce the automatic
discovery function.
Fatai Zhang: I had discussions with the G.709 editor and he mentioned there is
no explicit description of how to discover the tributary slot modes for both
ends of the link. We need to discuss this more with ITU experts.
Xihua Fu: There is no discovery in the data plane.
Deborah
Brungard: In G.709, you need to know what's on
each side. There’s no automation for interworking. We need to do something,
maybe LMP, good to discuss on the CCAMP mailing list.
Deborah
Brungard: Another item regarding this draft. We
need to stay in synch with the ITU. One thing that came up in the ITU liaison,
Q12 is not using the layering approach for the ODUs, but looking at a single
layer, we need to be careful not to progress our work too much, if any change
precludes this approach.
Fatai Zhang: For ODUk and ODUflex the topology and presentation maybe the same model.
For the traffic parameters it may be different.
Eve Varma: Communication is a good
idea. For example the time slot differences, it would be mandatory for the
equipment to back down if the connecting equipment only supported 2.5. There is
no auto-negotiation procedure in G.709, but I believe there is some expectation
(to be confirmed by Q9) in the equipment specification there will be some
process. This needs to be confirmed, but it may be that we do not need to do
anything in the control plane. Also for WSON we are communicating with Q6, I
would suggest communicating with Q9 as well.
Traffic Engineering Extensions to OSPF for GMPLS Control
of Evolutive G.709 OTN Presented by Daniele Ceccarelli
No Questions.
GMPLS Signaling Extensions for the Evolving G.709 OTN
Control
Presented by Fatai Zhang
Lou Berger: First comment,
not specific to document but generic to the working group activity with the
ITU. I think it's important that we do not get ahead of what's being defined in
the ITU for the data plane. We can define the setup and control of the data
plane, but should not be doing anything that is ahead of that data plane
definition.
The second
comment, there are a number of things in your draft that would be suitable to
the framework document. It would be good to move those items there.
Eve Varma: I was going to
make the same comments. In this case it's not getting ahead of the standard.
Julien Meuric: I am a bit confused,
with the respect to the different presentations. In the previous presentations
Danielle was suggesting another switch cap for the new OTN. In the case of
backward compatibility scenarios do you have LSPS using two different switch
caps?
Fatai Zhang: For previous draft
it's for OSPF extension, this draft refers to signaling.
Julien Meuric: In terms of path
computation when you provision the LSP you have to rely on the TED that’s
populated from the IGP. I am a bit confused how you handle backward
compatibility. Considering some of the authors are on both drafts I think you
should be clear in the documents on how you handle this.
Lou Berger: It would also be good if
the framework document was also clear on that issue as well.
GMPLS Signaling Extensions for Evolutive OTNs control
Presented by Xihua Fu
Malcolm Bets: I have
problems with this proposal. I see that you want to use different ODU, it seems that you have to understand the link before
getting the topology.
Xihua Fu: We know we can carry the tributaries, of course we should know the
tributary slot size of the far end.
Malcolm Bets: So it’s automatically
discovered?
Xihua Fu: The IGP is independent of the automatic discovery.
Malcolm Bets: The other point is
around the tributary slots, tributary slots are only relevant per link. Trying
to talk in terms of switching tributary slots is wrong,
you need to talk in terms of the payload.
Deborah
Brungard: ODUflex just
stabilized this September. We are out of time. Let's take this discussion to
the mailing list.
IETF-76 CCAMP Meeting Minutes
Second Session
Thursday: 0900-1130 Morning Session I
Slides
OAM Configuration
Framework and Technology Specific Extensions
RSVP-TE
extensions for MPLS-TP OAM Configuration
GMPLS RSVP-TE
Recovery Extension for data plane initiated reversion and protection timer signalling
On the
association of GMPLS Recovery LSPs
LMP Behavior
Negotiation
LMP Test Messages
Extensions for Evolutive OTN
LMP extensions
for G.709 Optical Transport Networks
Encoding of
Attributes of LSP intermediate hops using RSVP-TE
MT>1 support
over Bundled Links
Signaling for
Inverse Multiplexing Schemes via GMPLS using RSVP-TE
ASON routing
implementation and testing
ASON routing extensions
Draft-liu-mpls-rsvp-te-gr-frr-00
Support for
RSVP-TE in L3VPNs
Explicit Control
of Region Boundary for PCE-Based Inter-Layer
Open Charter
Discussion
Agenda
No Agenda
changes
OAM Configuration Framework and Technology Specific
Extensions
Presented by Attila Takacs
Loa
Andersson: One concern, regarding TLVs and TLV
structure. I think the framework draft defines the structure for TLV OAM
configuration. Then it spills into the technology specific document. I have
been discussing this with a number of people. I have three opinions: 1) Top
level TLV and then which type of OAM we are discussing, 2) Similar [to option
1] but the flag field is dependent on the technology (16 bits per technology),
3) All TLVs. Either way we need to have a discussion on this and quickly.
Attila
Takacs: We need to see if there is room for
optimization. When we started we had different assumptions. As the work evolved
we added functionality. We plan to address these issues in the next version of
the document.
Lou Berger: Generalization is good.
This is the control plane, not the data plane. So you do not have to be too
concerned with the number of bits. You do not want to define something that
does not have enough bits for the foreseeable future.
Greg Bernstein: The ERO processing,
where you have a per-hop type ERO. That sounds familiar to what we [WSON] would
like to use when configuring some of the equipment. This says OAM, is there
anything that would preclude this from being used for configuration.
Lou Berger: It’s a separate draft
[draft-kern-ccamp-rsvpte-hop-attributes-00] that is discussed later in this
session.
- draft-kern-ccamp-rsvp-te-sdh-otn-oam-ext-01
Lou
Berger: Who has read the document?
Show of hands – a reasonable number
Lou
Berger: Any concerns
on the control set, OAM functions being controlled? Good, no comments. Who would adopt this document?
Support – about the same number
Lou
Berger: Does anyone
think this is not a good start? No.
Ok, this looks
like good consensus, we will confirm on the list.
RSVP-TE extensions
for MPLS-TP OAM Configuration
Presented by Elisa Bellagamba
Deborah Brungard: Any
questions or comments?
George Swallow: Since the OAM in
MPLS-TP has wider applicability. I am wondering why we are constraining this
for just MPLS-TP and not use it in a wider scope.
Loa Andersson: I agree. This is part
of the general MPLS-TP project, we should discuss this in the general context of
MPLS but I want to preserve it as part of MPLS-TP. I do not see an issue.
Lou Berger: So what you're saying is
that you want to see MPLS-TP in the name, but not in the description?
Loa Andersson: I would like to see
MPLS-TP in the document name.
Lou Berger: From a content
perspective the document should not be limited.
George Swallow: I have a technical
comment as well. I would like to transmit timers for BFD and the receivers. I
want to see negotiation for both times.
Lou Berger: I agree, this should not
be limited in scope to just MPLS-TP.
George Swallow: I am totally fine
with the file name. Also maybe the abstract should mention this is applicable
to all MPLS.
Lou Berger: I think the document
needs to track Attila's document [draft-ietf-ccamp-oam-configuration-fwk]. It’s
a little early for WG status, once those issues are settled,
I don’t see a problem [to poll the WG].
Malcolm Betts: You're talking about
setting parameters. Do you have acknowledgements as well to confirm the
settings were implemented?
Elisa Bellagamba: Yes for instance, for timer values, the egress nodes
will acknowledge the request.
George Swallow: As any FYI, if you
set the BFFD timers all to 0 that would be a NACK.
Attila Takacs: Currently we are utilizing the LSP attributes object.
There is the possibility to have this condition. It's not specifically written
in the document.
Lou Berger: One additional comment
on the use of the RESV. We have had some offline discussion regarding the
issues of P2MP with LSP attributes coming back. Hopefully we will see a fix to
this before the next IETF.
GMPLS RSVP-TE Recovery Extension for data plane initiated
reversion and protection timer signalling
Presented by Attila Takacs
Deborah Brungard: Is
revertive and non-revertive protection included in this?
Attila Takacs: Yes. [DK:I think there may have been a
little more but I could not hear the rest].
Dmitri Papadimitriou:
Do you also plan to negotiate the values?
Attila Takacs: No.
Dmitri Papadimitriou:
So you assume they are consistent?
Attila Takacs: Yes, but it might be useful to perform a negotiation,
but currently its not
included in the document.
Deborah Brungard: Who has read the draft?
Not many
Lou Berger: Of those who
have not read the draft, who thinks this is an interesting function to have?
Deborah Brungard: Please read the
draft and we will discuss on the list.
On the association
of GMPLS Recovery LSPs
Presented by Lou Berger
Lou Berger: After IETF 75,
we didn’t have any technical comments, but we did have a comment from Dimitri
Papadimitriou saying that he would prefer to see this captured as a BIS in RFC
4872 and RFC 4873. My question as an author would be where we go from here: a)
Do a BIS, b) take this document [draft-berger-ccamp-assoc-info-00] and have it as a formal output of
the working group as informational, or c) something entirely different?
Dmitri Papadimitriou:
Starting with the BIS, we need to know what the changes are. We need to be
clear what the starting point is for making a BIS document. This was not
concluded from the previous [IETF 75] meeting. Everything is available from the
two emails to Lou on this subject. We use that as a starting point.
Lou Berger: I don’t disagree that an
option is doing BIS, although I think we need to do a BIS on RFC 4872 and RFC
4873. That is an option for proceeding.
Dmitri Papadimitriou:
The delta that you want to include in RFC 4872 is more information but the
procedures are defined. We need more documentation. In order to prevent
misinterpretation of processing, but the policy is included. In the RFC 4873
BIS, what's missing is the processing when you are receiving an association ID
related to the end-to-end protection and a segment protection. The suggestion
would be to start with one, the missing procedures.
Lou Berger: If we are going to do a BIS on one then we should do them together. The BIS path
is a viable alternative.
Adrian Farrel: Two things. In case
someone should worry, doing BIS is easy, you just need
someone to edit the document. The working group can choose to do that or not, but
it's not process heavy. The second item, since this is about association, there
is work in the transport working group about sharing
resource reservations in RSVP. The proposal is to use the association object on
a RESV to achieve that. You may or not want to fold that work into this, but it
is something to consider.
Lou Berger: If we do a BIS we should take the association object out of both
documents and put it into its own document.
Dmitri Papadimitriou:
RFC 4873 defines a new resource sharing mechanism; this is something that might
be useful outside of segment protection. If someone looks at segment protection
and they define a generalized way of resource sharing between multiple paths
they may not be aware it is part of this [RFC 4873] document.
Lou Berger: So the fundamental
question for the working group. Are there people willing to write the BIS?
Dmitri Papadimitriou:
You can put me as the author [RFC 4873 BIS]. Please give me your text.
Lou Berger: I am happy to
contribute.
David McWalter: I would be
interested in working on this as well. From
what I heard today, perhaps the clearest ways of doing this is keeping your
[draft-berger-ccamp-assoc-info-00] document and do the BIS and have another
document.
Lou Berger: I think your proposing
another alternative. Keep the informational document, do the BIS and then
capture the generic association object in a new draft.
Dmitri Papadimitriou:
Let's not confuse the audience. It's already generically usable as defined in
the current documents.
Lou Berger: Right, but you do not
have a standalone document. So to implement just the association object you’d
implement part of the document.
Dmitri Papadimitriou:
There is an entry that allows you to define the types that you want to make use
of. It is generic.
Lou Berger: Agreed. So where would
we like to go.
Deborah Brungard: Ok, let's have a show of hands. Should we do a BIS?
Not a
significant number.
Lou Berger: I am ok with
Dimitri having another IETF to get a BIS together. If we do not have the BIS
then this document [draft-berger-ccamp-assoc-info-00] should be taken through
the working group and formal last call and pushed through as an informational
document.
LMP Behavior
Negotiation
Presented by Dan Li
No comments.
Deborah Brungard: Who has
read the draft?
A small number.
Deborah Brungard: Any
concerns?
None.
Lou Berger: Is this
worthwhile functionality?
A small number.
Lou Berger: Personally I
think this document fixes a hole in the base specification. Let's give it some
time for people to review and comment on it.
LMP Test Messages
Extensions for Evolutive OTN
Presented by Daniele Ceccarelli
- OTN
control framework ID
Lou Berger: The last point
is good. You should align with the framework ID. I don’t think LMP is mentioned
in the framework ID. Bringing LMP into the framework,
makes senses. (Please contribute generic / high level text to the framework.)
LMP extensions for
G.709 Optical Transport Networks
Presented by Fatai Zhang
Lou Berger: Same comment
as on the previous document. (Please contribute generic / high level text to
the framework.) As the framework
document evolves, this document should follow.
Encoding of
Attributes of LSP intermediate hops using RSVP-TE
Presented by Attila Takacs
Greg
Bernstein: This looks really good. We had some
discussions on list. We like your proposal. One question from the list, does
this have an impact on restart? If we put attributes in this, would that impact
restarts?
Lou Berger: You can
make anything work. EROs will be handled in this case, which is the narrow
question. A broader question is what is the right place to put hop by hop
processing? We have LSP attributes, which are really intended for end-to-end.
We don’t have anything for immediate hops, other than EROs and SEROs. So where
is the right place to carry a hop-by-hop semantic? We should have that
discussion.
Julien Meuric: This is technically
interesting, from an operationally view do you have use cases to fit this
feature? Does it really deserve a specific extension and have documented the
problems you are solving?
Attila Takacs: The main use is for OAM
configuration. It's interesting for the WSON work as well. I think these are
the two use cases now.
Julien Meuric: If you can provide
some details [use cases]. I would be happy.
Attila Takacs: I think you can find this in a
separate draft. The encoding draft
points to this functionality.
Lou Berger: If you look at the
previous draft it's really simple. It (the use case) is MIP addressing at the
control plane. To me that’s the use case. We have MIP addressing for OAM, it
seems reasonable to say we need it for the control plane also.
Adrian Farrel: RFC 4420 included the
RRO attributes TLV. At the time we did not see a use case for putting it in the
ERO, so we did not. My concern is how much data. The RRO TLV is bit flags.
Looking at OAM control there is the potential for putting in substantial data.
Maybe in cases where there are multiple MIPS per node, then multiple hops and
addresses, may impact scaling of an ERO. On the other hand it's nice to have
the symmetry with the RRO to reflect the data back so you build an ERO that you
can send out.
Attila Takacs: Obviously if you configure
something using mid-points it would require more information.
Lou Berger: What are you thinking
about response semantics?
Attila Takacs: I think it might useful to say
configuration was successful.
Lou Berger: We are moving beyond the
spirit of RRO and ERO. We need to look at using some new objects, so we do not
overload RRO and ERO. Now we are looking to use it for mid-point signaling and
I think we really need to look at using some new objects. You still also have a
problem that some RROs might not make it back to the ingress. This could be due
to policy reasons or message overflow.
Attila Takacs: Currently is not clear if we
need the reporting. We also consider if this is the right use of the objects
and the semantics and what the value is.
Lou Berger: As Adrian says, multiple
address scaling may be an issue.
Attila Takacs: Yes.
Lou Berger: We need to be careful on
what we point into the RRO and ERO. We know we have an issue with LSP
attributes.
Attila Takacs: What's clear is this
functionality is useful how we do it needs discussion.
Dmitri
Papadimitriou:
My first point is, if the information is not as you expect would you reject the
LSP establishment? What is the impact on the error rate of the establishment?
We need to consider the more information for LSP establishment, the higher
increase in rejection. My second point is what the overhead is for this. The
ERO was a sequence of hops and we had some problems to extend the ERO to
include information beyond the topology information. My third point is there
are objects for determining which path is used. They are not being used to
determine which configuration to use on the interface.
Lou Berger: Dimitri makes a good
architectural point. ERO fundamentally was meant to be data path related. We
started going down this slippery slope of using ERO and RRO for things that are
not related to the data path. Maybe this is not the right thing to do.
[Chair hat on] We have largely been discussing a general issue, only one
comment was really on this document and asked "is this really
necessary?" I think it would be good to convince the working group that
this is necessary from a functional standpoint. Then we can discuss the
technical aspects.
MT>1 support over
Bundled Links
Presented by Jonathan Sadler
Rajan
Rao?: Regarding scaling in the core network. Is the suggestion to resize
bandwidth in core network? Or is the expectation the edge network has prior
knowledge of the expected bandwidth.
Jonathan
Sadler: When you get to the core border, the
border would signal the outer LSP [what you are nesting the end-to-end sessions
into]. It's possible that particular path is established and has the capacity
to meet the additional demands that maybe requested. In this case it would
resize the MT to expand the capacity. This is similar to what can be done in a packet
world already.
Rajan Rao?: Your not
precluding the resizing.
Jonathan
Sadler: No.
Julien Meuric: In the case where a
single RSVP session over multiple components links, what happens with recovery
if I lose a single component link?
Jonathan
Sadler: If we are
talking about link [component] failure, then indeed that traffic could be moved
to another component in the same bundle. It still meets the requirement of the
end-to-end ERO. Signaling could deal with the transition of traffic. Julien
Meuric: So you would extend the signaling to move part of the traffic
within a single RSVP session? It sounds like a huge gap from the existing RSVP
specifications. Jonathan Sadler: I would say it could be
done border to border using a make-before-break mechanism. So I do not think
significant change is required.
Julien Meuric: Not sure I agree.
Lou Berger: I think it's interesting
you start on generic class of problem, end-to-end, core and aggregation. Then
the document transitions into how bundling is to be extended. There are lots of
issues here, some we have not begun to talk about. If you want to change how
bundling works it's an interesting discussion but it’s a pretty radical change.
Bundling in past was really routing database optimization. Now you’re turning bundling
into an MPLS LAG. It's interesting but certainly not what bundling is. It
impacts signaling behavior so that needs be separated out.
Jonathan Sadler: The intention was not have an MPLS LAG but more of a
TDM lag.
Lou Berger: It’s a change to generic
bundling behavior. If you're going to do this you should not do it in a TDM
way, but make it generic.
Jonathan Sadler: This can be just as applicable to other technologies.
Lyndon Ong: We recognize this is a
significant change to RSVP. This is the right group to discuss it and
understand the problems associated with doing it. I don’t know of any
alternative mechanism for performing this control.
Lou
Berger: Bundling was
actually done in MPLS {working group]. So we will need to coordinate with them
as well.
Signaling for
Inverse Multiplexing Schemes via GMPLS using RSVP-TE
Present by Jonathan Sadler
Rajan Rao?: Is this applicable to both
core routed VCAT members and diversely routed VCAT members.
Jonathan
Sadler: The underlying
members can setup any way the underlying layer wants to setup those members. If
it wants to use co-signaling and everything ends up on the same path, or use
co-routing, or all independent sessions, this is separate from the mechanism
itself. So it could be used in any of those cases. It also allows for differing
underlying protection mechanisms. There is no dependency on the signaling
between the layers.
Rajan Rao?: Essentially if you have n-VCAT
members, you need n+1 LSPs.
Jonathan
Sadler: This could be done thru one LSP or ten
LSPs. Plus one for the inverse multiplex itself.
No name: Most inverse multiplexing technologies define the minimum number
of components below which the group becomes unusable. I have not read the draft
or seen this reflected in the presentation.
Jonathan
Sadler: This is a thought that’s occurred to me as
well. It’s an area for growth in this document.
Deborah
Brungard: We already have a generalized mechanism for supporting VCAT. Can
you say why we need additional mechanisms?
Jonathan Sadler: First off this is dealing
with any inverse multiplexing technology, not specific to VCAT. The existing
method has issues with the business relationship. This has been pointed out in
incoming (communication from OIF).
Deborah Brungard: I think you need
to describe why. You should discuss existing methods and then show what is not
supported.
Lou Berger: If you're going to
propose adding functionality, it's good to build it on the existing toolkit. If
the toolkit is inadequate then try to extend it, if it still cannot be used
then we need to understand why.
ASON routing
implementation and testing ASON routing extensions
Presented by Lyndon Ong
Lou Berger: Is there any
plan to shift over to what this group has produced?
Lyndon Ong: It depends. We were
waiting to see what happened with the extensions that were defined and
submitted to this group. At the moment it depends on the participants. If these
were standards track extensions that were approved. Since they are not
standards track, it’s a little more difficult to convince people to move to
them.
Lou Berger: One issue with standards
track is lack of implementations. If we have implementations of an experimental
RFC, it's much easier to take that, without changes, and move it to standards
track.
-
Code Points
With regards
to code points, we are working this with our AD. We do have a Wiki page with
temporary code points and values.
Dmitri Papadimitriou:
A point of clarification on the code point assignments. When we decided to move
to experimental we found that the assignment of code points was not possible
for these documents.
Lou Berger: We are working this
issue.
Dmitri Papadimitriou:
Have you tested what’s in the document? Why are there differences? There are
significant differences with ICD. If there are changes of requirements, e.g.,
multi-layer, they can be addressed in a future revision.
Deborah Brungard: These
questions will be addressed to some degree in the next presentation. Dimitri’s comment
is (valid) this document has been a working group document since 2006 and has
been there and has been decided with the OSPF WG. Why didn’t you use what is defined in the
document?
Lyndon Ong: This is a
chicken and egg problem. Some of the
testing precedes the working group efforts.
It was not an intentional divergence.
Lou Berger: (Cuts Lyndon
short.) I’m sorry we’re out of time on this topic. Its
clear there is history here. At this point we have a document that will come
out of the editor queue as experimental. The best way to get a proposed
standard on this topic is to take the experiment, run it, and come back with
implementation experience. The best answer would be no technical changes are
required. We can then reissue the document to a proposed standard. If there are
issues, we can resolve them. We hope
this experiment takes place so we can move to PS. We have a comment from out
AD.
Adrian Farrel: No AD
comment, just what Lou said.
Deborah Brungard: As you
know, any extensions to working group produced RFCs must follow the GMPLS
change process.
- Out of time
Lyndon Ong: One word on
the second presentation. The next draft
provides more detail on the local connection type and layered scoped
attributes, as was presented at the previous meeting. We very much appreciate people looking at the
draft and commenting.
Lou Berger: Discussion on
the list would be great.
Draft-liu-mpls-rsvp-te-gr-frr-00
Presented by Autumn Liu
Lou Berger: Thank you for
the update on the interesting work that is going on in the MPLS working group.
Future discussion will take place in the MPLS WG.
Support for RSVP-TE
in L3VPNs
Presented by Tomoki Murai
Lou Berger: Thank you.
This is not CCAMP work. You will need to talk to the L3VPN and MPLS co-chairs
to identify the relevant working group.
Explicit Control of
Region Boundary for PCE-Based Inter-Layer
Presented by Xihua Fu
Lou Berger: Once the work is
stabilized, you will need to split these into CCAMP and PCE drafts in order to
progress them.
- Charter
Update
Deborah Brungard: As per
the last meeting [IETF 75] a charter update is needed. The slides detail the
proposed changes.
Eve Varma: When we talk about data
plane technologies and WSON. We really mean the control plane view of data
plane technologies. When put this in the context of data plane technologies it
creates some confusion. Maybe we should use things like optical transport
networking and packet transport networking to avoid this.
Deborah Brungard: We will take the
suggestion onboard.
- Proposed language
Malcolm
Bets: We should look carefully at the words
"path configuration". We run into cases where we do not want to just
set the path up. We also want to configure things along the path as well. We
saw the drafts on configuration of OAM, as we start to look at WSON there are
also configuration parameters there as well. Maybe this should be mentioned
specifically as well.
Lou Berger:
That’s a good suggestion, if we have some suggestions on language we would like
to hear it, via the list [preferred] or directly to the chairs.
Chairs: This
discussion will continue on the WG mailing list.