Subject: Draft minutes - comments please

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 9 Aug 2005 13:09:15 +0100

IETF-63 Paris August 2005

CCAMP Working Group

Minutes thanks to Deborah Brungard and Don Fedyk

Admin
Adrian reviewed slides of agenda

WG Status
Adrian reviewed draft status and milestones

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.

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.

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.

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

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: <missed response>
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

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

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

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

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

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?
         These questions are relevant.
         How do we work and overlap with various working groups?
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
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 on the list. We should
         discuss more on 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: It differs in that this is not mpls.
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.
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 the items have been discussed.
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.
      MPLS working group is a specific example.
<???>: What would be the way to contact the IEEE to do this?
       Can I get a Liaison?
Alex: We have an established liaison relationship with IEEE.
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.