[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Updated minutes - more comments please
Thanks to Richard and Dimitri for filling some gaps.
======
IETF-63 Paris August 2005
CCAMP Working Group
Minutes thanks to Deborah Brungard and Don Fedyk
------------------
1) Admin
Adrian reviewed slides of agenda
------------------
------------------
2) WG Status
Adrian reviewed draft status and milestones
------------------
------------------
3) ITU and OIF liaison report - Lyndon Ong
Reviewed slides
- Q14 Plan to share g7713 before goes for consent
- No signaling activities, routing they are waiting for our DT
response, next meeting in Chicago
- OIF activities
- OIF communication to IETF with identified issues from demo
------------------
Adrian: Understand that there is no urgency for responding
Will respond as quickly as possible, will post on mailing list.
Lyndon: These are results of the demo so there is no dependence but
they are important.
Dimitri: Were these issues identified before or after demo?
Lyndon: Some before, some after.
Dimitri: Why not asked over the list for those before?
Lyndon: Some of the issues were, like the encoding.
The first issue was on an informal response. So we want a formal
response.
The other issues we made some implementation decisions so we want
to verify the decisions.
------------------
------------------
4) Interdomain RSVP - Arthi Ayyangar
Reviewed slides
- Hope to get comments before do next revision (soon) then hope to go
for last call
------------------
Dimitri: Do you plan to keep the examples in the document or as
appendix?
Arthi: Do you think it affects readability?
Dimitri: Prefer as appendix
Arthi: OK
Adrian: Is this an example or is it normative?
Arthi: The example only describes the overall working.
------------------
------------------
5) LSP stitching: Arthi Ayyangar
Reviewed slides
- Summarized discussion on list
- First point
- Are procedures required for both PSC and non-PSC LSPs?
- Discussion on list indicated yes
Adrian: Also from a control plane point of view it is better to
have a consistent behavior
- 2nd point
- Should allow stitching while traversing region boundaries?
Dimitri: I see no reason for this, why are we still discussing?
Adrian: I said yes on the list because of the last bullet on the
slide. Why disallow it?
Kireeti: I think yes also, why disallow it?
Dimitri: Why allow it?
Adrian: If we take it out of scope now, we may have to change later,
so why remove it now?
Yet we don't want to do it speculatively.
Igor: Question for kireeti: Can we stitch PSC1 with PSC2 LSP?
And we said while we could do this with a label stack, but we
shouldn't allow it as these LSPs were provisioned for a reason
as two different types (PSC1 and PSC2).
In the non-packet world this more clear. Use hierarchy and
adaptation.
Kireeti: Not so clear for me. PSC1 & PSC2 We understand but Non-PSC
we don't understand. For non PSC, we don't know where it
will go, e.g. wavelength switching. So why prevent it?
Igor: It is not complex but it is pointless.
Kireeti: You can always say no when you receive a request to stitch.
Arthi and Igor: No, you can't say no
Lou: What is the difference between stitching and hierarchical LSP.
The LSP on top (inner label) uses all the bandwidth of the one
below (outer label).
Adrian: The difference is if you add a label for the passenger LSP.
Arthi: It's not just label allocation it's resource allocation.
I'll address this later.
- Bidirectional LSPs and control of labels
- Current proposal resolves this by not sending a Label.
- 4 options: In Slides:
Lou: Minor suggestion; use a different C-type.
Call it Option 2 Prime.
Arthi: You can, but it is still an issue.
Adrian: You have to do special processing when you do stitching
anyway.
Arthi: You still have to implement the C-type.
Kireeti: You don't have to allocate a special label.
Adrian: Agree Point 4: Need to provide end-to-end bidirectional
service. For example for mpls/gmpls migration. Need to
stitch two unidirectional LSPs in the middle.
Arthi: Or could do 2nd part of (4). This is not really any changes
Just need stronger description on what we are doing
Personally like a sending label that is ignored.
Adrian: Who likes this 2nd part?
- Send any label and have receiver ignore it
# Some show of hands
Adrian: Anyone prefer one of the other solutions?
# (No one?)
Adrian: Seems a preference for this 2nd option, will take to list
Lou: Clear to make the change. Change the text to Must.
Dimitri: Can you make clear on the stitching for bidirectionality
Arthi: Should it be required for non PSC?
Lou: Anyone that supports stitching MUST support the procedures if
they support stitching.
Arthi: But if you are not following this document.
You could be doing data plane stitching and not control
plane stitching.
Lou: If it is outside the standard then it is out of scope. If you
follow the document you MUST follow the procedures.
------------------
------------------
6) Per-Domain-Paths - JP Vasseur
Would like to get feedback on last issue on slides.
------------------
Adrian: I think the use of IP reachability information is important.
The WG must make a conscious decision.
JP: This I-D is only describing reachability outside of domain
Adrian: We should say so more clearly
Dimitri: I sent feedback. We should cover this question.
Not sure if part of this document. This is a problem in several
documents.
If we have IP reachability, but don't know switching
capability, then it's not sure if we can make the connection.
This an issue when have a mixture of switching capabilities.
Igor: When we compute path, we consider TE resources, not IP
reachability. Should not rely on knowing reachability.
Once you have a mix of terminating points this is a real issue.
Adrian: We need to have a global solution.
Igor: You want to compute path consider the resources TE resource
reachability of destination. Not to rely on the IP but have
static information that you can reach the path.
JP: Just want to rely on IP reachability to reach next domain, and then
let next domain decide if it can satisfy the request.
Igor: OK - maybe could do aggregation rules
You can have a static TE entry.
JP: But we don't have information on resources
Janis ??: Agree that if we are separating data and control plane, this
will not work
Adrian: Specifying what information to use for path computation is not
covered anywhere. It is part of the algorithm, but not part of
the protocol. CSPF can use any information including IP
reachability or the weather.
Arthi: So how do we find next hop? How do you get to the next domain?
Adrian: If we don't do this process inside the domain, why do we have
to have a way to get out of the domain?
JP: So we should remove next hop?
Arthi: Does not make sense. How to do crankback?
Kireeti: OK - we need to consider further
------------------
------------------
7) Addresses in GMPLS networks - Richard Rabbat
Reviewed slides
------------------
Arthi: why you are proposing as a std track?
Adrian: This decision was a result of a loose poll based on
whether this advises, recommends or mandates.
Arthi: Can we do again the poll
Adrian: We can, who prefers:
# BCP - some show of hands
# Stds track - less show of hands
Arthi: My concern is that it is good to have this document, but
it is using items from other docs and making some changes
Have to change the Musts and Shoulds.
Adrian: If text is repeating the same must/should from another document
then it should be deleted.
If this is new must/should language then it should be std track
Need to clarify definitions. If you are Restating with same
values, its BCP. If you change values it is Standards updating
an existing RFC or a new Standards track document.
Arthi: Then this should be std track as it is already doing it
Lou: It is bringing together many items - would suggest informational
Could be informational. I did not vote because I was waiting for
informational.
Adrian: Who wants informational?
# almost same show of hands as BCP
Lou: If it's implementation then BCP, but if bringing together info,
then informational
The document is putting recommendations on implementing.
Is it just for building and deploying?
Or is it Defining a new field or procedure?
Adrian: OK we should discuss more
Dimitri: I thought the same - it is bringing together experience on
using addresses, not saying how to do, and not covering
future issues. So I have issue with 9.3 which is not based
on experience
Adrian: The WG needs to decide how want to do
Kireeti: We will discuss with ADs and take to list
Arthi: For example, for the FA it says a MUST for how to use, but it
doesn't say what to do for static case, so doesn't cover all
cases
Richard: This is an oversight. we'll correct it in the next revision
to say that we're talking about the dynamic case.
Yakov: Slide #3. Why the decision on FA LSP, this is a change to the
protocol.
Richard: You don't know it is a FA LSP. How do you know that it is to
be advertised back?
John Drake: It is covered in RFC3477.
Lou: That is unnumbered interfaces.
Adrian: Numbered FA LSPs need a way to indicate to the egress that
they will be used as FAs. Compare with unnumbered LSPs that
have a special object.
Arthi: What is the point of changing it to 0?
Kireeti: Let's discuss on the list
------------------
------------------
8) GMPLS/ASON Lexicography - Igor Bryskin
Reviewed slides
------------------
Igor: If anyone is interested in furthering ason-gmpls convergence,
talk to Adrian or myself to help
Richard: What is your objective?
Igor: Have consensus in the group and expand the dictionary.
Richard: Saw in one the drafts on ASON there is an appendix.
With ASON terms. Should we integrate the ason-gmpls
documents' reference terms into this document?
Dimitri: No, that work was for CCAMP people to understand ASON.
This is a different purpose
Igor: Agree. This is for ITU people to understand GMPLS
------------------
------------------
9) ASON routing evaluation - Dimitri Papadimitriou
Reviewed slides
------------------
Adrian: Who from DT is in the room?
# Dimitri and Lyndon
Adrian: Thanks for work.
Does the DT think this is ready for last call?
Lyndon: Yes. Just some minor editing
Adrian: Anyone object to last call
# None
Alex: Doesn't WG need to read this first
Adrian: Yes, need to read it for last call
OK take to list for last call
------------------
------------------
10) ASON signaling - Dimitri Papadimitriou
Reviewed slides
------------------
Dimitri: The community that wants to use this document needs it
to be recognized as an RFC, it is important to finish
Alex: Any technical issues on this or the last document that need to
discuss now?
Dimitri: Only this item on simultaneous call/connection signaling
Alex: Please summarize the technical issues.
Please focus the time in the meeting to raise and discuss
open issues
Lyndon: Will you liaison to SG15 before last call?
Kireeti: Yes
Steve Trowbridge: Should also include specific changes against g7713.2
Adrian: What is the intention?
Steve: Should be for alignment, should not have two normative versions
of ASON signaling
Adrian: ITU already has versions .1, .2, .3
Steve: State how it differs from .2 version
Adrian: OK. This is GMPLS. 7713.2 is not GMPLS.
We can do a comparative analysis.
Principal difference is call/connection piggybacking
Lyndon: Is this UNI/ENNI/INNI?
Dimitri: The document states clearly this if you read it
Answer is all three
Alex: Are the technical issues complete? It would be much better if we
have the technical summary. Not just say this work is ready or
work is stable.
Adrian: We owe the WG status.
Kireeti: Dimitri, can you start the liaison?
Dimitri: OK
------------------
------------------
11) CCAMP Work Plan
Kireeti reviewed the slide on options what to do
- We have pretty much cleared the documents in our queue,
and we are reviewing the charter to update
------------------
Alex: - I have 12 documents submitted to me, 10 docs in id list.
- Documents are done when finished also IESG review, I don't
expect to wait for this though before going on to new items.
Alex reviewed slide on potential new work
- Inter domain OK
- Layer 2 switching: where is this?
Kireeti: We will have a discussion on where to put it
Alex continues:
- L1VPN New WG
- doesn't seem any objection, should prioritize and timeline
- Are these Milestones or Work items?
Kireeti:
- Could do milestones, but defining work items is easier
- For example, MPLS/GMPLS interworking is implicit in the charter
but not specifically covered.
Alex: Can identify high priority items now
Adrian: - We already asked the working group and this is on the first
slide.
- There are six items shown on the slide
Alex: Six items that need some work. Is that too much?
Adrian:
- Not all things are the same size.
- Interoperability issues are already on the plate.
- Layer 2 switching Moderate size thing.
- MPLS/GMPLS migration moderate size.
- Second slide shows recent new topics. Maybe take on new items.
- Signaling Issues:
- Routing issues
- GMPLS OAM requirements.
Alex: These items are also important
Kireeti: Should look at pipelining work as we already started first
slide. It all depends on how long it takes to do charter.
We have been waiting now for more than a year
Alex: Can prioritize and identify if can spin off work to a new,
separate working group.
Just like Layer 1 VPN that uses GMPLS.
Take out other lumps and put in other WGs?
Chairs should identify items.
Adrian: We can discuss which could spin off, though we need to decide,
and not delay, as many items are already being worked on.
Bijan Jabbari: When I look at what is being implemented by vendors
there is a mismatch with what this group is doing.
Perhaps should look at short term.
Alex: Yes my thoughts should look at 1 year to 2 years.
Bijan: Not really clear what is being implemented
Bijan: I work with Academia and industry, and the answer is not clear.
You see implementations but you don't see deployments.
Business reasons etc. New way of thinking that takes time.
Alex: When go for standard track, do need implementation
Kireeti: Also need deployments, and that takes time
JP: Regarding the item on "input to PCE requirements".
Not sure if need this input
Adrian: Explain history is that CCAMP made a commitment to assist PCE
Could agree to remove this commitment
Alex: Yes we should discuss more in both groups. Don't want to make
commitment to remove this before discussing it.
If we have consensus maybe we don't need the document.
JP: On advertisement of TE/GMPLS capabilities, we have implemented
and deployed in 5 large service providers, so would like to
expedite this
Lou: Slide Back to Slide3:
For the item on charter - missing is ASON.
What do we do about alignment, and that we have two versions of
RSVP? There is only one version of GMPLS, what do we need to do?
What steps that we need to take as a WG?
Alex: ASON is on our charter
Lou: It's on charter - we have completed our documents.
We can send to SG15, but what do we do from there to align GMPLS and
ASON solutions?
Adrian: Added it to slides
Richard: On recent new topics - do we know what is in-charter currently?
Alex: It is up to chairs:
Adrian: If it is in the scope of the charter, we will do milestones
There will be discussion on the list.
Dimitri: Why is "deployment considerations" considered marginal?
If you want feedback, how can this be classified as marginal?
Please prioritize and please discuss.
Adrian: This is from the community view gathered on the list last year
Dimitri: Then how will we have deployment
Kireeti: You can do canvassing to get people to discuss.
We will take back to the list to do a poll again
------------------
------------------
12) GMPLS for Ethernet - Dimitri Papadimitriou
Reviewed slides
Define a set of scenarios:
4 Scenarios
-Aggregation
-Metro
-Unified? Core
-Transport
Dimitri asked if interest to do this work
------------------
Don Fedyk: We still don't know what is actually meant by GMPLS
Ethernet. The document does not go far enough today
with enough detail. The document is too open ended and
we don't know what exactly is being specified. I asked
for more detailed specification.
Dimitri: <Nodded>
Ali Sajassi: Ethernet differs from other data planes as it's not point
to point. Do you want to keep it as in the perspective of
IEEE?
Other comments: you want to replace existing Ethernet
control plane with GMPLS: again how will you do multipoint?
Shortest path may overlap with issues discussed in TRILL.
How are you going to coordinate with other WGs?
Loa: Not speaking for the DT as we didn't discuss it: I have experience
running a medium/large scale Ethernet network as a point-to-point
network (unified/core). It would be very applicable to add a gmpls
control plane.
Note that if we can't do it as a standard we (deployers) will do
it ourselves. It is pretty straight forward.
Ali: I can see for point to point, it's for multipoint that I see it
will have issues
Dimitri: OK. Can you input specifics? This said these questions are
relevant but the scope (of the document) has been restricted
to point-to-point. The issues on how we coordinate and
potentially overlap with other working groups must also be
addressed (implicitly: if we decide to move forward with this
item.)
Richard Spencer: Can you confirm that using GMPLS in enterprise is out
of scope?
Dimitri: As no one has expressed interest I would say it is out of scope
Richard S: Will there be any changes to Ethernet control/data plane?
What would be the potential difficulties?
Have a discussion with the IEEE and see where they would be
impacted.
Dimitri: I can not say what will be the solution chosen, we already
suggested we work with IEEE to assess impact
Richard S: I see little value for aggregation.
I don't see in metro why a provider would want to use this
instead of VPLS
Dimitri: I have replied to some of the issues you are currently raising
on the list. If further clarification required we should
discuss them on the list.
Kireeti: We will not change the Ethernet data plane here. If we conclude
it may need to be changed, we will liaise to IEEE and get their
agreement.
CCAMP is focused on core tunneling technologies, though we
don't say how you will use them - metro or core - I would like
us to continue not to be specific for access or core. If
there is anything specifically different for access, then need
to add to charter.
Lyndon: There is a lot of interest in other groups (ITU, OIF, MEF).
I think there is interest. Where people are uncertain is how.
Need to look at more on supporting pt to pt or multipt.
Don O'Conner: How does this differ from l2vpn?
Dimitri: As explained in the introduction of the problem statement
document it differs from the forwarding which is not based
on packet header (as in MPLS) but based on the Layer-2 frame
header.
Kireeti: L2VPON charter is different. L2VPN sets up vpns.
This work is on signaling and routing in Ethernet networks.
Tom Nadeau: Is this in the scope of CCAMP today?
Adrian: Yes this is in the scope as a core network.
GMPLS handles packet transport networks.
Maybe this is could be a new working group.
Note, however, that changes to the data plane are not in
scope for CCAMP and would require action by other SDOs,
in this case IEEE.
Tom: Seems similar to TRILL.
Adrian: Yes. Need to determine if there is overlap. Perhaps this work
should go there. Alternatively, perhaps this work goes in a new
WG.
Dimitri: Some of these items such as the difference with TRILL have
been discussed on the mailing list.
Loa: Trill is in campus networks.
Alex: For structuring this work, we need to be very clear what data path
modifications need to be done. Should communicate with IEEE
liaison, preferably before BOF.
TRILL working group is a specific example.
Dimitri: What would be the way to contact the IEEE to do this?
Is there a liaison with IEEE that we can make use of?
Alex: We have an established liaison relationship with IEEE.
Dimitri: OK, we will enter in contact with the liaison representative.
Kireeti: First need to decide if we need a change in the data plane.
Then talk to the IEEE.
Adrian: Also need to tell IEEE what we plan to do, no matter how we do
it.
<Marcus? Michael?> Smith: There are limits to the use of VLAN-ID.
There are only 4K of them. Will you use this as the label?
Adrian: We haven't decided anything about how forwarding will occur yet
Dinesh Mohan: I haven't heard yet that there is planned a change to the
data plane. Need to understand better.
Should look at this as a new control plane using existing
data plane.
It would be nice to have the GMPLS Control plane but is
there no intent to change the control plane? The basic
assumption is that you have a different control plane
then that should be the assumption.
This is fine to explore, but the starting point is not to
modify the data plane.
Adrian: When we control SDH we did not mess with the data plane. We
should not be modifying the transport technology.
Monique Morrow: Echo what Alex said, any modification we need to talk
to the IEEE.
Dimitri: OK, but we are not talking in the context that there is a
change to data plane.
Ali: Trill and this are using ISIS. Trill plan to change the data
plane.
Kireeti: Please stop, take to list.
Ali: Several vendors offer Ethernet switches that offer point to
point using MPLS control plane supporting millions of
connections.
Yakov: How? Could you tell me whether they carry a label?
Ali: Yes. They are MPLS switches
Yakov: So it is a router, an LSR , that you can call an Ethernet
switch and you are done?
Adrian: That is indeed a suggestion.
Don O'C: Ethernet is connectionless and now GMPLS is connection-
oriented, so this is different.
This is redefining Ethernet to make it connection oriented.
Is that the intent?
Is this making VLAN tags look like GMPLS labels?
Adrian: Again, this has not been discussed
Loa: From experience, we don't want to remove VLAN tags. Need something
else. And the chairs said to the design team not to do that, yet
80% of CCAMP are already assuming this is what we want to do.
Adrian: Design team job is done - Thanks.
We need now for the WG to discuss.
------------------
Time is over. Other drafts that we didn't get to discuss, take to list.