CCAMP
Minutes for IETF 87
http://tools.ietf.org/wg/ccamp/agenda
First Session
TUESDAY, July 30, 2013
1700-1830 Afternoon Session
III
Room: Potsdam 3
Presentation Start Time Duration Information
0 17:00 10 Title: Administrivia & WG Status
Draft:
Presenter: Chairs
Fatai
Zhang: After this meeting we
plan to update [draft-ietf-ccamp-otn-g709-info-model] and
[draft-ietf-ccamp-gmpls-g709-framework] based on AD (Adrian Farrel) review.
Comments requested on non-presented
WG drafts status:
- draft-ietf-ccamp-rsvp-te-srlg-collect
Oscar
Gonzalez de Dios: The
document is stable. There is one functionality (knowing if a RRO suboject is
incomplete or has been edited) that needs to be made generic (there was a
comment from Lou during IETF 86th). A mail was sent on 4th of July with several
options to make the functionality generic. A new mail to the CCAMP list will be
sent this with the options. Feedback is requested from the CCAMP list.
- draft-ietf-ccamp-rsvp-te-li-lb:
Daniele
Ceccarelli: No changes from
last meeting
1 -
draft-ietf-ccamp-lsp-attribute-ro-02
1 17:10
8 Title: LSP Attribute in ERO
Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-02
Presenter: Cyril Margaria
Lou
Berger: I suspect you think
that you addressed Adrian's (Farrel) comment from last meeting with the
changes. I suggest you check with him either privately or on the list to
confirm. In any case send a note to the list.
2 -
draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06
2 17:18
8 Title: RSVP-TE Extensions for Associated
Bidirectional LSPs
Draft: :http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06
Presenter:
Matt Hartley
Lou
Berger: I think we can move
rapidly towards Last Call.
Matt
Hartley: Splendid.
3 -
draft-ietf-ccamp-te-metric-recording-02
3 17:26
8 Title: RSVP-TE extension for recording TE Metric
of a LSP
Draft: http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-02
Presenter: George Swallow
Oscar
Gonzalez de Dios: Regarding
IANA requests Collision with IANA assignment. We need to align on temporary
assignments to avoid collisions.
George
Swallow: That is what the
second bullet is about.
Oscar
Gonzalez de Dios: Yes, the
temporary registry is not updated.
Daniele
Ceccarelli: How about we
merge the drafts to minimize the number of drafts to read?
George
Swallow: We initially had
this plan, but we wanted to avoid holding up the other draft. Since one of them has dependencies on others
while the other has not.
Lou
Berger: Regarding IANA
assignments, are you having similar issues in MPLS? (Re: collision of temporary
assignments values). We used to have the wiki which has not been touched for a
long time.
George
Swallow: I fully support it.
It would save a lot of headache and WG chairs time.
Lou
Berger: Perhaps we need to
find someone from the MPLS WG that contributes to that wiki and if you’re
willing to help keep that wiki updated please let us know and we’ll have a
couple of focal point for that.
Daniel
King: We used to do that on
the MPLS wiki but our AD suggested to stop.
Lou
Berger: To be clear it's not
temporary assignment it is just a temporary registry, it should not be used as
a way to ensure that documents do no collide and avoid implementation issues values
will not changes but just to suggest assignments non
colliding with each other. We will discuss this with Adrian Farrel. Do we have
someone who will take responsibility for the CCAMP page?
Oscar Gonzalez de Dios: I
volunteer.
Lou
Berger: We think it would be
a good idea to resurrect the wiki
Adrian
Farrel: Different times with
respect to RFC4020. (Early allocation). People wanted
to implement and start interoperability. Now that we support early allocation
which gives a codepoint for 2 years I don't think we need allocations outside
IANA. What happens if we screw up that registry?
George
Swallow: We will caveat the
request.
Adrian
Farrel: Why not go that
extra bit further and request an early allocation. We should talk in more
details chairs and ADs.
Loa
Andersson: Suggestion: ask
the WG chairs if the draft is stable enough to start development, then request an early allocation.
Adrian
Farrel: I suggest that if I
am uneasy with this the IESG may also have issues. We can take this discussion
offline (with CCAMP and MPLS chairs).
Loa
Andersson: Suggestion: ask
the WG chairs if the draft is stable enough to start development, then request an early allocation.
Lou
Berger: Drafts can be
considered that stable once they become WG documents.
4 -
draft-ietf-ccamp-lsp-diversity-02
4 17:34
8 Title: RSVP-TE LSP Route Diversity using Exclude
Routes
Draft:
http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-02
Presenter: George Swallow
Fatai
Zhang: I understand the
motivation, but I have an issue with the complexity of the solution. Why not
use existing solution like path-key?
George
Swallow: The operator may
not be using PCE. or may not permit for security
reasons to let the client nodes speak with the serve PCE. We did discuss the
solution early on before this document became a WG document.
Fatai
Zhang: In the case of UNI we
can take the Path Key to the UNI-C and the UNI-C computes the second path to be
diverse wrt the first path. It’s very easy to do
that.
Deborah
Brungard: Make sure you read
the document and trigger discussion on the list, not wait for the meeting.
5 -
draft-ali-ccamp-rsvp-te-include-route-04
5 17:42 6 Title: Include Routes - Extension to RSVP-TE
Draft:
http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-04
Presenter: George Swallow
Khuzema Pithewan: There are elements (constraints)
influencing a section or complete path of an LSP, these need to be managed.
George
Swallow: If you cannot meet
all the existing constraints, as well as meet diverse objective, then an error
will be issued. This is described in the document.
George
Swallow: The draft says that
if changes occur you’ll be notified with an error message saying that you no
longer have the diversity you asked for but we don’t want the network to
automatically re-groom things based on those changes.
Lou
Berger: another XRO might be
present and you need to consider making it explicit in the draft.
George
Swallow: what I was saying
is that if the constraints can’t be met you receive an error message. That’s
already there.
Adrian
Farrel: Suggest that you
rename subobject. The sub-object, as there might be
confusion between I want to use this LSP as a hop and I want to follow the same
path.
George
Swallow: An easy change, do
you have any suggestion?
Lou
Berger:
"Inclusion"?
Adrian
Farrel: Inclusion could be
risky for stitching reasons. Follow the same path or something like that.
George
Swallow: "Follow the
breadcrumb"? Ok, we (authors) will discuss.
6 -
draft-ali-ccamp-lsp-inquiry-00
6 17:48 5 Title:
RSVP-TE Extension for Label Switched Path (LSP) Inquiry
Draft:
http://tools.ietf.org/html/draft-ali-ccamp-lsp-inquiry-00
Presenter:
George Swallow
Lou
Berger: Off course reusing
existing mechanisms is good, if you manage to reuse also existing terminology
its better.
George
Swallow: Yes.
Khuzema Pithewan: This will affect existing services and
require a maintenance window.
George
Swallow: This is signaled
from the IP plane, so we assume that you are in a maintenance window.
Dieter
Beller: You are considering
technologies where you need to tear down an LSP before you can establish an LSP
using an optimized path but there are technologies out there that allow soft
set setting up of resources. A temporary protection (SNCP for instance) that do
not require to tear down an LSP before setting up the new one. Are you
envisaging to cover also covering those technologies
in this draft?
George
Swallow: We see this being
used for shared mesh protection in optical environments.
Dieter
Beller: I'm talking about
technologies that in tens of ms are able to tear down
an LSP and setup the protecting one.
George
Swallow: The main goal is
covering optical networks.
Xian
Zhang: I don't follow the
motivation for the second type of inquiry. What is its usage? Have you
considered using calls? Calls can help you check the availability without
committing resources.
George
Swallow: I'm not familiar
with that particular mechanism.
Lou
Berger: Not sure how it
would help, “Calls” is about the end points.
7 - draft-ali-ccamp-rc-objective-function-metric-bound-03
7 17:53 5
Title: RSVP-TE Extension for
Signaling Objective Function and Metric Bound
Draft:
http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-03
>Presenter: George Swallow
Lou
Berger: [poll] How many people think it's a useful function? (a reasonable number) How many read? (about
the same, maybe little less) How many think this is a good foundation? (Slightly
less than before) Any comments on why not supportive?
Cyril
Margaria: Mechanisms defined
in hop encoding could be used for this kind of information.
Oscar
Gonzalez de Dios: Not only
in this draft but in others you add path computation constraints like
include/exclude things. When path computation is done in the middle of the
network one may want to pass all the path computation constraints in RSVP-TE.
However, in the proposal, you are duplicating PCEP objects.
Lou
Berger: we generally follow
the approach that we can distribute path computation. and all the info is
available at every point [along an LSP].
Oscar
Gonzalez de Dios: Not what I
meant. I mean that if there is already a complete syntax to express path
computation constraints, inclusions/exclusions, etc,
why not reuse it?
Lou
Berger: Can you make this
suggestion on the list?
Fatai
Zhang: Not sure about the
value of this draft. We are making the signaling too complex. We should let the
path computation do the path computation and the signaling just do the cross
connections.
George
Swallow: we had this
discussion a lot of time ago.
8 -
draft-long-ccamp-rsvp-te-bandwidth-availability-01
8 17:58 5 Title:
RSVP-TE Signaling Extension for Bandwidth availability
Draft:
http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availability-01
Presenter:
Min Ye
Lou
Berger: See the TSV WG
[Tunnel Congestion I-D?],Multi T-SPEC document], there
could be overlap with your draft. You should see if there’s a way to combine
with them.
Khuzema Pithewan: Do you mean that one particular hop you
might end up using multiple links to satisfy a bandwidth request.?
9 - draft-long-ccamp-ospf-availability-extension-00
9 18:03 5 Title:
OSPF Routing Extension for links with variable discrete bandwidth
>Draft:
http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension-00
>Presenter: Min Ye
Matt
Hartley: Should this be an
OSPF WG draft?
Lou
Berger: in the past we
agreed with the OSPF chairs that it is possible to make OSPF changes in CCAMP. Same for ISIS.
10 -
draft-dhody-ccamp-rsvp-te-domain-subobjects-02
10 18:08 7 Title:
Domain Subobjects for Resource ReserVation Protocol – Traffic Engineering (RSVP-TE)
Draft:
http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02
Presenter:
Dhruv Dhody
Deborah
Brungard: [Poll] How many
think this would be useful? [a reasonable number], How
many have read [slightly more] Take to the list and get discussion.
11 -
draft-gmggm-ccamp-gencons-snmp-mib-02
11 18:15
5 Title: A SNMP MIB to manage GMPLS with General
Constraints Support
>Draft:
http://tools.ietf.org/html/draft-gmggm-ccamp-gencons-snmp-mib-02
>Presenter: Giovanni Martinelli
Lou
Berger: I think this
document is timed well in relation to the WSON work. (Which will
soon be in last call).
Fatai
Zhang: General comment. When
do we need MIB drafts? any time that we define
signaling or routing extensions? Do we need it in this case? Some MIB drafts
are on the CCAMP page and are not updated for years.
Lou
Berger: We are contribution
driven.
Deborah
Brungard: In previous years
we recommended to have MIB companion documents. Some people use SNMP as
management interface, some others use different management protocols.
Adrian
Farrel: You are not required
to write MIB modules. You are required to discuss how you manage the networks
in which your network may be managed protocols are running.
12 -
draft-martinelli-ccamp-wson-iv-info-02
12 18:20
5 Title: Information Model for WSONs with
Impairments Validation
Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-02
Presenter:
Giovanni Martinelli
Dieter
Beller: Considering we do
not have data plane interop, interoperability and a
computation capability to compute paths end-to-end, and validate them, I find
this work a little early? bit premature.
Giovanni
Martinelli: What do you mean
that there is no data plane compatibility? The answer from ITU-T folks was that
there could be some multivendor case. and the single
vendor scenario only applies to the nonlinear case.
Dieter
Beller: From the discussion
in Orlando a transponder from vendor A and a transponder from vendor B would
not necessarily interoperate. So it is not currently capable, so is too soon
for a development of an information model too soon? .
Giovanni
Martinelli: The compatibility
will come, we cannot make any public statement yet.
The information model doesn’t include any formula. There are some parameters
that no one cares how are computed.
Dieter
Beller: We are supposed to
develop standard that provides interoperability
Giovanni
Martinelli: Yes. At the at control plane level.
Deborah
Brungard: I suggest to talk with Q6 guys. They are having an interim meeting in
Nurnberg, to help define.
13 - draft-martinelli-ccamp-wson-iv-encode-02
13 18:25 5 Title:
Information Encoding for WSON with Impairments Validation
Draft:
http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-02
Presenter:
Giovanni Martinelli
No comments.
Adjourn
18:30
Second Session
WEDNESDAY, July 31,
2013
1300-1500
Room: Potsdam 1
0 -
Administrivia & WG Status
Presentation Start Time Duration Information
0 13:00 5 Title: Administrivia
Draft:
Presenter: Chairs
14 -
draft-ogrcetal-ccamp-flexi-grid-fwk-03
14 13:05 8
Title: Framework and
Requirements for GMPLS based control of Flexi-grid DWDM networks
Draft:
http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-03
Presenter: Oscar Gonzalez de Dios
Deborah Brungard: We have
a lot of liaisons from ITU-T. Has G.872 been updated? Has it been consented?
Malcolm Betts: G.872
has been consented.
Deborah Brungard: Has it been sent to the CCAMP?
Malcolm Betts: I think
it is worth sending a specific Liaison to Q6 about the non-integer values of N
and M.
Lou Berger: [Poll] How many think this is a useful work? (good
representation) How many have read the document? (same)
How many think this is a good foundation for WG work? (same
number) Good support. Will confirm on the list.
15 -
draft-zhang-ccamp-flexible-grid-rsvp-te-ext-02
15 13:13 8
Title: RSVP-TE Signaling
Extensions in support of Flexible Grid
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-02
Presenter: Xian Zhang
Giovanni Martinelli: What happens if the LSP needs to be
resized? (i.e., N and M change.)
Xian Zhang: You need
to change N and M, but the label changes hop by hop anyway.
Lou Berger: The
document is in an early stage of development. [Poll] How many have read? (Reasonable but less than framework document.) How many support? (Same number.) We may
poll before the next meeting, assuming adoption of the framework
document.
Iftekar Hussain: We have
not been speaking about solutions yet. It seems that this document isn't as
well developed. Does it make sense to adopt it?
Lou Berger: We
can adopt documents at different level of maturity. It shouldn’t be assumed
that once the document is adopted the technical issues are solved. Remember
that adoption is the start of the WG's technical work, not a statement that a
documented solution is completely correct. If you feel the document is not
ready or heading in the wrong direction, then you should bring any comments to
the list.
Iftekar Hussain: I was
asking because there are other solution documents as well.
Lou Berger: Bring
them forward, please.
Giovanni Martinelli: WG can judge if the document is
suitable, but it may be early. Solutions are quite below in the list of
documents. Before we need framework, encoding, info model
etc.
Lou Berger: So you
feel adopting the document is premature?
Giovanni Martinelli: Yes.
16 - draft-zhang-ccamp-flexible-grid-ospf-ext-02
16 13:21 8
Title: GMPLS OSPF-TE
Extensions in support of Flexible Grid DWDM Networks
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-02
Presenter: Ramon Casellas
Lou Berger: [poll]
how many have read? (same as previous doc). How many
have reservations? (one). Say at the mic.
Cyril Margaria: A bit too early to make it a wg document
Lou Berger: Specific technical issues?
Cyril Margaria: no.
Lou Berger: Okay,
then please review and send specific comments to the list.
Lou Berger: General
comment. Please take advantage of the list to raise comments and objections,
lack of discussion may be misconstrued as concurrence or disinterest. If you
have alternate proposals put them into a draft and discuss them on the
list.
Fatai Zhang: We could
adopt the framework and label drafts and then speak about signaling and routing.
Lou Berger: Can you
make this suggestion on the list once the result of the framework adoption poll
is known?
17 -
draft-galikunze-ccamp-g-698-2-snmp-mib-03
17 13:29 7
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-03
Presenter: Gabriele Galimberti
18 -
draft-galikunze-ccamp-opt-imp-snmp-mib-00
18 13:36 7
Title: An SNMP MIB extension
to RFC3591 to manage optical interface parameters of DWDM applications
Draft: http://tools.ietf.org/html/draft-galikunze-ccamp-opt-imp-snmp-mib-00
Presenter: Gabriele Galimberti
Gert Grammel: Are these
two drafts covering the same content of the one we discussed in Orlando?
Gabriele Galimberti: One is covering what is in the ITU-T
recommendation and the other one what is not there. They are complimentary.
Deborah Brungard: [Poll] How many have read the documents? [Not too many]
Question 6 will have this as a discussion topic at the October meeting. Hopefully
we will see a Liaison to help us progress these documents.
19 -
draft-dharinigert-ccamp-g-698-2-lmp-03
draft-dharinigert-ccamp-opt-imp-lmp-00
19 13:43 8
Title: Extension to the LMP
for DWDM Optical Line Systems to manage optical parameters of DWDM applications
Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-03
http://tools.ietf.org/html/draft-dharinigert-ccamp-opt-imp-lmp-00
Presenter: Gert Grammel
Deborah Brungard: You have
split the document and this second one is covering the proprietary parameters
based on G.698.2, but we understood from the Q6 folks that the application
codes where selected based on a parameters selection that would allow
interoperability, so if you not use the application codes, the set of
parameters you are defining is enough to provide interoperability?
Gert Grammel: We
consider a combination of both. If it is a standard application code then it is
interoperable. Since the semantic of non standard
application codes is not defined, all the parameters that you can find in
G.698.2 need to be known to ensure that two application codes
interoperate.
Deborah Brungard: It would
be good to take it to Q6 to understand whether it is sufficient. [Poll] How
many have read the document? (more people than MIB
docs)
Lou Berger: [Poll] How many think this is a useful functionality? (less than above)
[polling the documents separately]: Is
draft-dharinigert-ccamp-opt-imp-lmp-00 useful? (same
number, medium) Poll for 698.2 lmp (same
number except one person).
Adrian Farrel: Since
many people are suddenly interested in LMP, I’ve just been contacted by someone
in KARP WG (security for routing protocols WG) there is a draft coming out
about security issues and potential fixes for LMP. They are crying for
help.
20 -
draft-ceccadedios-ccamp-overlay-use-cases-01
20 13:51 7
Title: Use cases for operating
networks in the overlay model context
Draft: http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-01
Presenter: Daniele Ceccarelli
(single
presentation for next)
21 -
draft-zhang-ccamp-gmpls-uni-app-04
21
13:58 8
Title: Applicability of Generalized Multiprotocol
Label Switching (GMPLS) User-Network Interface (UNI)
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-04
Presenter: Daniele Ceccarelli
Adrian Farrel: AD hat off - My name appears on applicability I-D, but not on the use cases. This is not an accident. If we were to go for option 1 I would have severe problems. I'm definitely an option 2 person, so I can be in favour of one document and opposed to the other. I don't think the ONI approach is good or desirable.
Daniele Ceccarelli: What do you oppose?
Adrian Farrel: I
don't like the mechanism proposed for sharing routing information. It's not
that I see the UNI definition as being you must, must not share routing
information, I just don't see that that's the way we should build networks.
Lou Berger: Do you
believe that sharing routing information between domains is not acceptable?
Adrian Farrel: No, in
fact I am working on a document that facilitates this
(draft-farrel-interconnected-te-info-exchange-01) and Daniele is one of the
co-authors. My issue is not the exchange of routing information but the
mechanisms used to exchange it.
Lou Berger: If you
were sitting at the overlay provider layer, do you think that what used to be
called L1VPN enhanced mode would be a reasonable thing to consider?
Adrian Farrel:
Architecturally or protocol wise? I should say yes and no. We did discuss
solutions, three options were discussed: 1. A common
IGP with sharing of information, 2. An IGP instance between layers and 3. Well
known inter-domain protocol between layers and I don’t like any of them.
Lou Berger: In
theory you support this, but you have an issue with solutions, both the ones in
the past and this one?
Adrian Farrel: Yes, The enhanced mode in L1VPN recognised there was function there, but didn't need to call it any other special type of interface. It was just two networks talking to each other.
Lou Berger: I had
hard times understanding what is the difference between ONI and L1VPN?
Adrian Farrel: My view
as a WG participant is that we need to step back and discuss the architecture,
then solution work.
Oscar
Gonzalez de Dios: When I began this work I wanted to discuss the use
cases and describe the architecture, rather than develop solutions.
Lou Berger: so maybe
we should step back and review the architecture. Actually we have other
documents that discuss the work.
Julien Meuric: [slide
UNI/ONI Use case] this feels like transport recovery mechanisms being pushed
into the packet layer.
Daniele Ceccarelli: The
intention was to demonstrate how it is possible mix the advantages of the two
layers
Deborah Brungard: I
suggest we break up the examples and post to the list and request feedback.
Lou Berger: Happy to
hear the authors are looking at taking a step back and revisiting their drafts.
When doing this please look at other individual drafts that may have related
text and work with those other authors. Also consider the differences
between UNI and ENNI, which operate in a single layer, and the concepts of
L1VPN basic and enhanced mode which can be leveraged for cross
client/server layers -- which is perhaps what's intended by ONI.
22 -
draft-ali-ccamp-gmpls-uni-error-notification-00
22 14:06 5 Title: Extensions to RSVP-TE for Error Notification
in GMPLS User-Network Interface (UNI)
Draft: http://tools.ietf.org/html/draft-ali-ccamp-gmpls-uni-error-notification-00
Presenter: Matt Hartley
Igor Bryskin: What happens if the path-error message is not
received?
Matt Hartley: The edge
node will not find out.
Igor Bryskin: Most of that solutions don't work. What you need is some reliable
mechanism.
Matt Hartley: This is
comment, not on my draft but the way GMPLS works in general. It'll work the way
RSVP-TE always works.
Lou Berger: This is [reliable
message delivery] a general issue with RSVP and beyond the scope of this document.
Cyril Margaria: This
mechanisms seems to apply to UNI, we need a general mechanism.
Lou Berger: This leads
to a question that I had, why is the general address mapping/hiding
mechanism defined RFC4208 insufficient?
Matt Hartley: will
have to look at that
Adrian Farrel: The
question I sent on the mailing list is that what you want to define is already
there in RFC4783
Matt Hartley: If you
can send this comment to the list I can review and comment.
Deborah Brungard: Are you
looking at segment protection in the core?
Lou Berger: What you
are looking for is a single error value?
Matt Hartley: Yes. It seems it's
going to be a short draft.
23 -
draft-fedyk-ccamp-uni-extensions-02
23 14:11 8 Title: UNI Extensions for Diversity and Latency
Support
Draft:
http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02
Presenter: Dieter Beller
Lou Berger: [slide -
relationships with prior work] Do you think that your document is related to
Daniele's [draft-ceccadedios-ccamp-overlay-use-cases]
presentation?
Dieter Beller: Yes.
Lou Berger: I
suggest you take advantage of the time this week and see how these documents
fit together. And then update the documents/WG accordingly.
24 -
draft-beeram-ccamp-melg-01
24 14:19 8
Title: Mutually Exclusive Link
Group (MELG)
Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-01
Presenter: Vishnu Pavan Beeram
Lou Berger: [slide -
4] A clarification question, is this a virtual TE link, or an actual TE link?
Vishnu Pavan Beeram: A
virtual TE link
Lou Berger: Based on
existing work (RFCs), there is no distinction between virtual TE link and
an actual TE link in the client topology. This is a significant change.
Vishnu Pavan Beeram: We can
make a note of this in the document.
George Swallow: At what
point would you advertise mutual exclusivity, do you wait until it is setup? If
this is the direction, how many do you advertise, why not include this in the
draft.
Vishnu Pavan Beeram: My co-author would be keen to answer that.
Igor Bryskin: Basically we looked at this. Due to the nature
dynamic, we want to expand the concept of SRLG and treat it as Share Resource
Link Group. So for a diverse computation there is no difference, but when you advertise
the available BW on each priority level. This would help client path
computation, specifically for concurrent optimization. Why put this in a
separate draft; wider problem than MEL, dynamics aside we may want to advertise
when there is a change, and ignore all other links, this is to help
scalability. In general IETF wants to have single solutions but I think we need
multiple solutions for this area.
Deborah Brungard: [poll] how
many think this is interesting? (Not too many, try to raise interest.)
25 -
draft-rao-ccamp-mlnmrn-otn-ospfte-ext-02
25 14:27 8
Title: OSPF-TE extensions for
MLNMRN based on OTN
Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext-02
Presenter: Khuzema Pithewan
Lou Berger: Do you
require anything from signaling?
Khuzema Pithewan: yes,
maybe yes.
Fatai Zhang:
26 -
draft-zhang-ccamp-gmpls-h-lsp-mln-05 26 14:35 8
Title: GMPLS-based Hierarchy
LSP Creation in Multi-Region and Multi-Layer Networks
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05
Presenter: Xian Zhang
Khuzema Pithewan: Yes,
maybe. Once we compute the path, it involves multiple domains. The
signaling could be handled in multiple segments, but you need OSPF to handle
the first part.
Lou Berger: Ok, so you see where I
am going with regards to the next presentation. Can you make sure you guys are
aligned?
Khuzema Pithewan: Yes, thank
you.
Lou Berger: Do you
need anything from routing to make the signaling work?
Xian Zhang: The typical scenario is
multi-domain, so no need for routing work.
Lou Berger: So if I understand you
response, no because everyone will use PCE?
Xian Zhang: No, Cyril can help me
clarify.
Cyril Margaria: You
don't know where you originate.
Lou Berger: Even though
this says MLN, you are scoping this to MRN?
Cyril Margaria: No, we don't need IGP extensions.
Lou Berger: I do not
understand, can you discuss with the previous authors and see if anything needs
to be aligned?
Khuzema Pithewan: If you
are in a single domain with multi-regions, you definitely need routing
extensions to compute a path across layer transitions.
Lou Berger: Please
review RFC6107 as some of these mechanisms may already be described.
27 -
draft-gandhi-ccamp-gmpls-restoration-lsp-01
27 14:43 5
Title: RSVP-TE Extensions For Signaling GMPLS Restoration LSP
Draft: http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-01
Presenter: Gabriele Galimberti
Igor Bryskin: Why are you requesting feedbacks if 2 years ago we
presented a similar draft and there was no interest?
Lou Berger: Igor are you willing to work on a BCP with the authors on how we
do this. I think we agree that mechanisms exist but we need to document how
they might be used. We do not have time to discuss, so let’s take this offline.
Cyril Margaria:
This new protection type seems to be about policy at the ingress node, rather
than intermediate nodes.
Lou Berger: Ok, let’s take this to
the list, I did not understand that [last comment].
28 -
draft-helvoort-ccamp-fs-priority-00
28 14:48 7
Title: Update Forced Switch
Priority
Draft: http://tools.ietf.org/html/draft-helvoort-ccamp-fs-priority-00
Presenter: Huub van Helvoort
Lou Berger: You
mentioned on the list that this draft was in response to a message that I sent.
The message stated that a combined change was needed to RFC4427 and RFC6372,
but this draft only covers RFC4427. Also I was mistaken in my statement with
regards to RFC4427, as it doesn't state relative priorities. That is
stated only in RFC6372. There are other discussions on this topic going on (in
the MPLS WG), and this draft should be taken forward in a manner consistent
with those discussions.
George Swallow: We [MPLS
WG] have been working on a way forward for [Protection and Restoration] PSC.
This does not seem to reflect these discussions.
Lou Berger: Rather than getting into
discussion of the specific proposal here, let’s look at the larger problem and
discussions.
29 -
draft-zhang-ccamp-rsvpte-ber-measure-00
29 14:55 5 Title: RSVP-TE Extensions for Bit Error Rate
(BER) Measurement
Draft: http://tools.ietf.org/html/draft-zhang-ccamp-rsvpte-ber-measure-00
Presenter: Zhenbin Li
Lou Berger:
Apologies but we are out of time. Please summarise the draft to the list. We
appreciate your time and preparing the slide and again apologies for running
out of time. The slides are on record for the WG session.
Adjourn