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