Sixty-fifth IETF Dallas March 2006
FRIDAY, March 24, 2006
0900-1130 Morning Session I
RTG ccamp Common Control and Measurement Plane WG
CCAMP Working Group Meeting Report
Note takers: Deborah Brungard, Richard Rabbat
Chairs: Adrian Farrel, Kireeti Kompella
============================
0. Administrivia (chairs)
No changes to the agenda
================================================
1. WG status, RFCs, drafts, milestones (chairs)
Slides
Adrian: Over the next month, expect emails from chairs to ask to move private
drafts to WG drafts to fill milestones
If you're bringing new work, please first contribute to milestone work
Kireeti: Announced that he will be stepping down as chair, hopefully by next
IETF will have the next chair.
================================================
2. ITU-T and OIF progress report (Lyndon Ong)
Slides
Richard Rabbat: Is there work on LMP in G.7714.1?
Lyndon: No it doesn't conatin anything on LMP.
It's on use of J bytes for adjacency.
Next steps will be related to LMP type capabilities such
as Transport capability exchange
Jonathan Sadler: There was a revised verison G.7714 that has provided more
guidance on transport capability exchange, so you may want
to read to see how LMP fits
Dimitri Papadimitriou: What is under "new activities" for the OIF
Lyndon: Routing extensions, signaling for call diversity
Dimitri: How does OIF work with ENNI 1.0 and ENNI 2.0. in parallel?
Lyndon: UNI versions are to include other capablities
For E-NNI, 1.0 has basic services; 2.0 has more advanced services
One is routing, the other signaling
Jim Jones: As lyndon explained E-NNI 2.0 signaling lags behind UNI 2.0 and will be
updated to include capabilities and recent demos
Kireeti: What would make me happy is not to have extensions defined in IAs
Work has been done in the IETF. Instead, we will have objects in the specs and IAs
Putting the extensions in an informational appendix is still confusing, especially
as vendors have implemented them for demos
I would prefer that you just point to IETF so as extensions evolve in the IETF, you
stay coordinated
Jim: We [the OIF] don't think that differently
One of our goals is to align and converge.
We understand we are using experimental codepoints
The ENNI 1.0 IA captures requirements.
We think the OIF has a lot to offer and we will bring it to the IETF
Zafar Ali: What about your ties to the MEF?
Lyndon: MEF guys came to the last OIF meeting and that led to discussions on what
should be in the T-spec
Julien Meuric : Shouldn't you wait for CCAMP's GMPLS ASON work before you start GMPLS-ASON interworking?
Lyndon: Carrier members in OIF wanted to see interowrking. Perhaps because they feel there are
implementations of both
Richard: As kireeti noted there is confusion
Would it be possible to split the OIF document to differentiate the implementation for the
demo versus other routing work?
Adrian: As Zafar noted, this is not the OIF. That discussion is for the OIF
Dimitri: We should ask for a liaison from the OIF on E-NNI signaling
Adrian: As this work is not being done in a vacuum, clearly the OIF should ask for comments
well ahead of going for consent
=======================================================
3. Addressing Draft (Richard Rabbat)
Slides
- draft-ietf-ccamp-gmpls-addressing-03.txt
Zafar: I disagree with the proposed [by Dimitri] changes to the ERO options
These are all optional in the RFCs. As this reads it says that implementations
must use component ID
Dimitri: The point was not to mandate the use of Component ID
It is to say that it follows the Outgoing Link ID whenever Outgoing Link ID is used
This is the only usuage case we have to day
It's not mandating to have the Component Interface ID
It's to say it is only there for explicit egress control
Adrian: To restate what I heard Dimitri saying:
He says that the only time for Outgoing Interface Id is for explicit egress control
Zafir: Then I ask for clarification on incoming and outgoing interfaces
When two labels are to be included in the ERO, then they should follow the outgoing interface
Richard: I am happy with the text as currently written, but Dimitri is not
Lou Berger: What is that you are trying to do in the draft?
Richard: We are listing all the options
Adrian: This draft is trying to resolve interoperation difficulties
We want to have a list of what an implementation must be able to process
depending what another implementaiton sends
Lou: So the intention is to come up with a best pratice, not to redefine anything?
Adrian: We want to see if we can get a definitive list of what an implementaiton should be
capable of receiving
If we agree on a subset of the options listed then we could do a BCP or change the definitions
Depending on what the community wants
Lou: Looking at MPLS and EROs, over time the uses and requirements will change
So there is a danger that we may over restrict what can do later
So a BCP is OK, but to limit what can do, is dangerous
Lou: Have you explored what is operationally being done today
Richard: Yes, I saw the same problem as Dimitri says but the reverse
Some implementations don't know what to do with EROs they receive
Lou: So want to force people to change?
Richard: We need to achieve interoperability
Lou: To reduce options to improve interop is good but to change whats deployed in the field is not beneficial
Richard: I've seen implementations which can't do option 3 [See slides]
Lou: If they can't do whats required in the specs it's a nonconforming implementation
Dimitri: I want to remove these options, have already a list of options
Kireeti: I agree that Outgoing interface IDs are used to identify the link at the egress
Dimitri: When we have explicit label control, it was to check what was being used
Outgoing interface ID is not to be used exclusively but in combination with label or component ID
Kireeti: Even if what you say is true, the ERO is also hop-by-hop in the middle of the network
So can't take this out
Dimitri: We can keep it, but do we keep it as optional?
Ross Callon: Is there any confusion of having it there versus optional to implement?
Adrian: Yes there is possible confusion.
We can resolve this as optional for guy sending, but mandatory for the one receiving
Dimitri: On option 4 [see slides] the quesiton is whether to keep or not "optional"
Zafar: Suggest remove all text associated with link bundling until it has been done
Adrian: But it has been implemented already
Diego Caviglia : I'd be against removing option 4
Adrian: We need to understand that given the current state of implementations, to
achieve interop some one is going to feel pain. To deprecate ERO options or to force
support of ERO options
Kireeti: As Lou said, we're not ready to deprecate options yet
Adrian: We will move this discussion to the list, and I will do an informal survey
Adrian: We also need to resolve what status this I-D should have
I am now completely unable to choose if it is Standards Track or not
I'll sit with the ADs to understand what to do and the chairs will make the choice
=======================================================
4. Ethernet
4a. GELS activity, status and plans (Dimitri Papadimitriou)
Slides
Adrian: Are you planning to have a BOF in Montreal?
Dimitri: Yes
Adrian: What is the expected/hoped outcome?
Dimitri: To have well-focused work that defines the needed extensions and mechanisms
We kept the group separate because of the label issue
Compare with SONET when the control plane was completely decoupled from data plane
Adrian: For questions to Dimitri now, please recall that this is not a GELS BoF
Zafar: How much is MEF involved in this work?
Is there a standing liaison to work with them?
Dimitri: We don't have a relationship with MEF. We will interact with IEEE
Dave Allan: The statement that there are 2 solutions is misleading
From my perspective there are two different aspects
We have a data plane we have to configure
We are not raising interop issues
Don O'Connor: Link-local labels are not allowed by IEEE
They were proposed at the IEEE and voted down
Adrian: This is an important point, but it's a point for a GELS BoF
Don: We shouldn't have a BoF
Kireeti: That's a question for the ADs
And if the decision is not to have a BoF next time, we don't want to have a mini-BoF here in CCAMP
So a request to the ADs is to get a clear decision in Montreal to say:
- that we kill the work
- that we continue the work in GELS
= that we continue the work in an existing working group
4b. Ethernet TSpec (Dimitri)
Slides
draft-dimitri-mef-ethernet-traffic-parameters-00.txt
Dimitri: Is there a need for siganling multiple CoS per EVC?
Would require a combination for DS-TE
I won't do this work unless there is clear need
Adrian: We will keep this in CCAMP, irrespective of GELS status
Dimitri: It will be the 1st time we fill a TSpec with this kind of parameters
Note that this is being done for MEF and OIF, but they have different requirements
Lyndon: The OIF is happy to see this work move forward, and happy to leave protocol
definitions for this group
John Drake: Would this be better in the L1VPN working group?
Adrian: We'll talk to the L1VPN chairs
Dimitri: It depends if it's service related
=================================================================
5. Hierarchy bis - Signaled FAs (Kohei Shiomoto)
Slides
RFC 4206 (LSP Hierarchy)
draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt
Kohei: Asked the question about splitting the document?
- 4206 bis
- LSP advertisement and usage
- Target IGP instance
Dimitri: The document tries to address 4 problems
- Advertising dynamic FAs
This would result in an update to the rfc4046
- Do we want to have a generic trigger mechanism for FA?
- What is the policing that we are assuming for FAs?
In the past, single policy entity, it was implicit.
- Advertising into IP or MPLS. Is this related to signaling?
It may be more efficient to separate in 4 documents instead of combining them
Kireeti: When we did 4206, we didn't want to tackle the issue of advertising into a
separate instance of the control plane as that's a different problem with
routing adjacency.
The draft accordingly said that we were restricted to a single instance.
We did tackle the issue of dynamic FAs but not fully, and so there are questions
that arise from 4206.
Just because 4 different issues, doesn't mean we need to do separate documents
Kireeti: The other thing is that there is a relationship between this and the MRN work
If we come up and say that we need an update to the TLV for MRN, I don't want to do
the work twice
Since there is currently no implementation, this is the time to do it right
Zafar: You need just one way to communicate routing information.
Just a need to flood the adjacency
Kireeti: When you're in the same area, you have all the information you need to designate that
one of the links is an FA and the others are RA, what happens when the RA goes down?
Zafar and Kireeti disagreed
Zafar: In hierarchy we only dealt with unidirecitonal LSPs, these are bidriectional
Kireeti: Hierarchy draft didn't deal with unidirectional only
Adrian: What is not in 4046 is how to trigger FA advertisement
So this issue is for bidirectional LSPs
If we only have a unidirecitonal LSP then we don't need a trigger
That's what has led to this discussion
Take your disagreement to the list
Dimitri: As we have items fixed from 4046, use of same routing instance, and use of different
routing instances, do we want to have same mechanism?
May be further thought needed.
Kireeti: Yes, we want the same mechanism
============================================
6. ASON Solutions
6a. Call signaling (Adrian)
Slides
draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt
Adrian: will move this forward in the working group
No discussion
6b. Signaling applicability (Adrian)
Slides
Adrian: There is no draft for signaling applicability based on RFC 4139
This is a CCAMP responsibility
Looking for volunteers
6c. Routing solution (Dimitri)
Slides
draft-dimitri-ccamp-gmpls-ason-routing-sol-01.txt
Adrian: We need to consult with ITU as they provided requirements.
We need to stay linked with the IGP working groups so as not to cause confusion
Dimitri: Should this be a WG document?
Kireeti: I'd prefer to hear from the OSPF and ISIS WGs to ensure no issues
Use of the opaque LSA is not an issue but how to transport advertisement
info may be, so prefer to wait
Dimitri: I've sent a note to the chairs before the meeting. How can we get fast progress?
Kireeti: I will scare them
=======================================================
7. MPLS/GMPLS Migration (Kohei)
Slides
draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt
Kohei: Asked for draft to be WG draft
Loa Andersson: Support that this be working group document.
Please notify MPLS working group of what's going on as it is an overlapping document
Adrian: We started this process on Monday - we gave a presentation there
Zafir: One question, if we restrict deployment to only dual stack (gmpls and mpls)
would we even need this?
Adrian: I can show you offline that it is needed
Zafar: Why is the statement saying that phased approach is not recommended?
Kohei: We say that phased is OK, but show certain limitations in the context of codepoints
Zafir: Please just check again and see if appropriate
==============================================
8. VCAT/LCAS (Richard)
Slides
draft-bernstein-ccamp-gmpls-vcat-lcas-02.txt
Richard: ready for wg draft?
Adrian: I'm encouraged by all the vendor participants though feel this is not quite
stable and would prefer one more version
Dimitri: What do we need to advertise?
What type of info do we expect to change?
I could see multiple ways to support this depending on the info
Adrian: Yes that's why I feel it needs a bit more work
We need to know what we need to know
===============================================================================
9. Graceful Shutdown in GMPLS Traffic Engineering Networks (Zafar)
Slides
draft-ali-ccamp-mpls-graceful-shutdown-03.txt
Dimitri: Do we put all the admin status in advertising?
You are using a bit to indicate local maintenance required
This is being used in ISIS, but is it an attribute of a link this info
Do we want to do that?
Zafar: There are other applications of the link tlv
Dimitri: I'm still not clear on the use of that bit for the status of a link
I'll send mail on the list
Not sure if want to put this all there
Adrian: there's a bug in the quote. you can't use MAY, use MUST.
Adrian: There's a bug on one of the slide for the alternative procedure, probably in the draft too.
As you need to set bandwidth greater than zero, and if want to deal with backward compatibility,
it should be a "must" not a "may"
But then have two "must" procedures to do
So should limit to one "must" procedure
And since the one "must" for backward compatibility cannot be thrown our,
suggest trhowing out the other procedure
Zafar: OK
Dimitri: The same as when bringing a node down. No need for yet another mechanism to do that
===============================================================================
10. Multi-Layer Network (Deborah Brungard)
Slides
draft-ietf-ccamp-gmpls-mln-reqs-00.txt
draft-ietf-ccamp-gmpls-mln-eval-00.txt
draft-papadimitriou-ccamp-gmpls-mrn-extensions-01.txt
Deborah: Next steps
For clarification we will remove architecture-specific text.
Make the draft control plane interconnection model agnostic
Revise mln-eval
Align to the progress of the requirements document
Need for evalution of solution space for virtual te link
Kireeti: Isn't the evaluation document the 1st step to doing a profile?
I would suggest fleshing out the profile
Deborah: Yes
Zafar: Don't we already support flooding of multiple ISCD?
This is internal to the node
Dimitri: Do you really want to advertise internal TE links?
The more I can abstract, the better it is for interop
Zafar: The whole extension is that you want to hide links for hybrid nodes.
Either that or make it a very large bandwidth
Dimitri: The routing protocols expect the node to be a single point
Deborah: We welcome you to work on solutions
Adrian: Is there momentum behind solution draft? It seems to be stuck.
Deborah: We needed to focus on architecture as it has implication on solutions
=======================================================================
11. MIB Module for OSP-TE and OSPF GMPLS (Tomohiro Otani)
Slides
draft-otani-ccamp-gmpls-ospf-mib-02.txt
Adrian: I'm particularly pleased to see this work being done as several RFCs needed
it before they were published.
This does need to be done with the OSPF working group, so anytime there is
an update on the draft please send to the OSPF working group.
I see no reason for this not to be a WG draft
We will send to mailing list.
Adrian: There's a question on ISIS.
The ISIS WG usually prefers work to be done in their WG
But if they are not interested, there is no reason not to do there
Kireeti: For generalized extensions, primary work was for OSPF.
If we do an OSPF MIB this should provoke the ISIS WG to do a TE MIB, as it is needed.
Adrian: I know there are ISIS-TE implementations, so this is needed
============================================
12. Other business
Kireeti: Who supports migration draft becoming a WG draft?
Large (overwhelming!) show of hands
No-one against
Zafar: What about graceful shutdown? Support for WG draft?
Kireeti: Fraceful link shutdown to WG draft?
Small show of hands
No-one against
Dimitri: If the graceful link shutdown has the routing part fixed the
support will be much greater
Kireeti: We'll do a poll on the list after the fixes