IETF-62 Proceedings Submission

["Adrian Farrel" <adrian@olddog.co.uk>]

Common Control and Measurement Plane WG (ccamp)

Tuesday, March 8, 2005 at 0900-1130
Minutes by Deborah Brungard, Richard Rabbat and Tove Madsen

Working group status - chairs
- No changes to the agenda made.
- Adrian reviewed status of drafts, reviewed charter milestones.
  We are holding off on new charter until finish last call of 8
  drafts, expect 1-2 months.
- Bill summarized ADs view, should wait for re-chartering until
  finish last call considering expectation will be very soon for
  last calls.
* Dimitri asked about IPR assertion on re-optimization draft
  - Adrian said it did not give the same terms that have been seen
    in some recent IPR claims. The WG has to decide what to do.
  - Scott Bradner said we need to be very careful.  Advised there
    may be anti-trust issues. Best to have no IETF interaction
    other than to ask for clarity.
    Scott offered to review emails on the subject.
  - JP said we can take that as a way to go forward and continue
    technical work.

ASON considerations

ITU liaison - Lyndon Ong presented Wesam's slides
- Thanks to the IETF for liaisons and participation of Adrian and
  Igor at last meetings
- Crankback and the comparison of LMP and ASON discovery will be
  incorporated in SG15 Q14's work.
- There are two liaisons from ITU to CCAMP on the way.
- Routing - ITU not planning any routing exts work, looking to
  IETF's work.
- Continuing work on ASON management.
- An FTP site is available for liaison statements.
* Adrian asked if ITU plans to liaise G.7713 on new text for
  crankback before consent?
  - Lyndon said a meeting is upcoming and will ask for it to be
    considered.
* Kireeti asked if there is any problem in that the crankback draft
  is not an RFC yet?
  - Adrian - RFC is desirable, not required?
  - Scott Bradner - it is required to have an RFC number for final
    balloting. The IESG can request expedited publication.
* Ken Biholar - on terminology for ASON - ITU G.8081 is on ITU
  terminology, and may want to consider including it.
  - Adrian - can that be liaised to us?
  - Steve Trowbridge - Yes, we can do that.

ASON Routing Evaluation
* Adrian - The design team on routing has members from both ITU and
  IETF, although we did not do the correct process, so ITU reps are
  individuals, not ITU representatives.
  - Adrian will work with Steve to formalize the process.
* Adrian - Would like to make the draft from the team on evaluation
  of routing protocols into a working group draft
  - we will take to the list to see if any objection.
* Dimitri - asked if we can use formal liaison process to send this
  draft to ITU, does it need to be WG draft? And encourages comments
  now, before it goes to last call.
  - Adrian - we can liaise the draft and our intention to consider it
    as a WG draft

Lexicography draft (Adrian)
- Q14 indicates meeting went well, authors summarized comments and
  incorporated in this release.
* Adrian asked if should be WG draft
  - Kireeti said we could do that, need to ask the list, also need to
    compare with G.8081
* Ben Mack-Crane - hasn't seen good definitions of GMPLS terms in RFC
  or drafts, are there definitions?
  - Adrian thinks there are good terms, though in multiple
    RFCs/drafts.
  - Ben - if someone is new to the IETF, they have difficulty on
    where to go for definitions.
  - Adrian - if people want to do a draft to collect definitions of all
    GMPLS terms (more general than just ASON as in lexi draft), then
    they are welcome to do it.

Inter-domain GMPLS traffic engineering-rsvp-te extensions (Arthi)
LSP Stitching (Arthi)
- Need feedback on several items.
* Adrian - it would be inappropriate to move extensions to be a WG
  draft without first stitching draft becoming a wg draft. If no one
  objects, see no reason why not to be WG draft.
* Dimitri - Question: the draft was to originally do signaling exts,
  do we need to do more on routing aspects?
  - Arthi - agree, however this comment would have applied to the
    previous merged draft. The whole point of splitting the ID was
    because the scope was wider and generic. In that case, it becomes
    necessary to include the routing aspects as well.
* Dimitri - if allow stitching of end-to-end LSP with LSP segment
  through different switching caps, then this changes the LSP switching
  type along the path and thus this becomes a FA
  - Arthi - but end-to-end does not change.
* Zafar - we need to be careful what advertising because of scalability
  concerns, need further consideration.
  - Kireeti - As Arthi said the LSP segment does not *have to* be
    advertised but *can be* if desired.
  - Arthi - You, of course, need to be careful about advertising
    anything as TE-links dictated by correct policies. And as far as
    scaling is concerned, Igor is standing right behind you and will
    probably say (and I agree) that LSP segments can also be bundled
    in which case you are no longer advertising each LSP segment as a
    TE-link. We are simply having the same discussion again that was on
    the mailing list.
* Igor - thought stitching maybe more appropriate for LSP hierarchy
  draft, but as this already in editor's queue, will add here.
* Lou - sw cap can change hop by hop just needs to match end to end of
  hop.
  - Arthi - agree, we were thinking the same.
* Discussion sent to mailing list

Per-domain path computation method for computing inter-domain traffic
engineering (TE) LSP. (JP)
Draft-vasseur-ccamp-inter-domain-path-comp-00.txt:
routing and path computation aspects.
* Zafar asked clarification on ccamp-pce relationship
  - Kireeti - this draft discusses ASBR on the path, if not then it's
    PCE, suggest add this to draft to clarify that this is for when
    computation is done by elements on the path.
  - JP - ok
* Adrian and Kireeti asked if this should be a WG draft? Good consensus
  in the room to be WG draft, will take it to the list.

Automesh (JP)
- Agreement to rehash work a bit to put these together.
- Now 2 drafts
- Not a new ID, no changes.
- Deployed networks using that.
- No major changes planned
* Igor - asked how to reflect constraints in a node for switching?
  - JP - we are discussing auto mesh, not node switching.
  - Igor - but how do we reflect node capabilities?
  - JP - this draft is not about node capability discovery (for this,
    see draft-vasseur-ccamp-te-node-cap)
  - Igor - how to reflect for computation any internal constraints,
    could do via node caps advertisement.
  - JP agrees, though here just doing a discovery, doesn't think
    related as discovering members of mesh.
  - Adrian - two drafts, this is not node capability that is next one
    by JP, cut discussion said to take it to list.

Routing extensions for discovery of TE node capabilities (JL Le Roux)
* Adrian - on process, authors did a group job of splitting draft
  and sending to OSPF and ISIS groups, chairs will follow up with
  those groups.
* Dimitri - should for terminology call TE router?
  - JL - yes.
  - Dimitri - should the TLV be exclusive to this function?
  - JL - yes.
* Igor - how to distinguish node capabilities?
  - Adrian - do by TLVs, need to do a draft to propose, this draft
    gives you the TLVs, then can follow-up with other drafts to
    describe function want to use it for, take discussion to list.
* JL asked that this be adopted as a WG document.
  - Adrian - Take it to the list

Extensions to GMPLS RSVP graceful restart (Lou Berger)
* Adrian - do editorial respin, let us know, and we will take to
  last call
* Any implementations?
  - Yes - two!

MRN
Requirements (Kohei Shiomoto)
Evaluation draft (JL Le Roux)
Protocol extensions (Dimitri)
* Arthi - what does virtual FA have to do with MRN,
  isn't it general?
  - Dimitri - should we have a specific doc on virtual FA for
    wider scope?
  - Arthi - did you want to scope only to MRN context?
  - Dimitri - no, just not sure if soln doc should be split.
  - Arthi - could be general - so prefer a separate doc on virtual FA.
* Zafar - we need to give a priority capability for TE.
  - Dimitri - new TLV may be needed to describe relationships of
    multiple interfaces
* Zafar - how relates to hierarchy draft?
  - Dimitri - maybe should be as applicability statement,
  - Kireeti - should do on mailing list
* Kireeti - requests to continue work, when re-charter will consider
  for WG drafts.

Routing considerations and CSPF for inter-as (Tomohiro Otani)
* JP - very useful draft. Concerned about the advertisement of DYNAMIC
  summarized TE resource information across domains (static
  capabilities are perfectly fine). Too much of aggregation renders
  the solution inefficient and not enough of aggregation seriously
  compromises the routing scalability. Furthermore, there are other
  confidentiality issues to sort out in the context of inter-provider.
  - Otani - ok, we need more on summarizing capability.
* Kireeti - thinks good and hopes to be a WG draft, though for now
  would request for this draft to continue work, though lets finish
  what ccamp has now and then when re-charter will make this as a
  WG doc.
* Otani - how to handle inter-as cspf constraints?
  - Kireeti - as noted before (continue work).

L2LSP (Dimitri)
* Adrian asked clarification, is this "single hop"?
  - Dimitri - multiple hops each is a LSR, will clarify this in draft
* Kireeti - ADs request a framework doc and include how it relates to
  other SDOs, max 10 pages
  - Dimitri - ok

GMPLS addressing (Richard Rabbat)
* Adrian - as this is first version, recommend continue discussion,
  re-spin draft, and then review again.
* Adrian asked for feedback on the topics, not the technical content
  initially.
* Loa - BCP is a specific type of RFC, describes what we have
  experience with not necessarily what should be (as in this draft)
* Kireeti - warns for everyone with implementations to review the
  draft to ensure direction taken by this draft is right one.
* Lou - should we wait for re-spin or now?
  - Kireeti - wait for re-spin.

L1VPN (Tomonori Takeda)
Framework draft
Applicability draft
* Alex - by next IETF will decide if it should be included in ccamp or
  as separate WG.

Control plane saturation (JL Le Roux)
* Arthi - Do you think the LSRs would really want to advertise such
  control plane limitations ? Secondly, what implication does this have
  in case of inter-domain, especially inter-provider LSPs ?
* Kireeti - because of time, lets do on list.

Graceful shutdown (Zafar Ali)
* Kireeti - will consider for wg doc after re-charter
* JP - is this part of current charter
  - Kireeti - doesn't matter, we just can not include anymore as WG
    doc until re-charter.

Deployment-augmented (Zafar Ali)
* Arthi - This is good work. My only concern is the use of terminology.
  Do you actually expect to use LSP-Hierarchy extensions (say Hop3)
  while signaling an MPLS LSP over that FA in the MPLS domain ?
  - Zafar - no just TE link

GMPLS interworking (Kenji)
* Dimitri - why need to adv priority of LSP?
  - Adrian - need to ask on list.

GMPLS interworking (Kohei Shiomoto)
* Adrian - WG doc will be decided after re-charter
  - Welcome that will merge with other draft on augmented,
  - Suggest also look at Kenji's interworking draft to merge.

Cho - ARP signal
* Kireeti - request work with Dimitri on framework draft,
  - When decide direction and interactions with other SDO, may
    decide to form a design team to work on L2,
  - First we need a framework.