Re: Revised draft minutes

[Kohei Shiomoto <[e-mail]>]

Hello Adrian,

Please let me put my comments in the two blank portions of the revised 
agenda.
See in line.

Kohei

>This draft incorporates feedback from Dimitri and Vishal
>and from an anonymous reviewer. Thanks.
>
>Further comments ASAP.
>
>Adrian
>
>
>Common Control and Measurement Plane WG (ccamp)
>
>THURSDAY, March 4 at 0900-1130
>===============================
>
>CHAIRS: Kireeti Kompella <[e-mail]>
>        Adrian Farrel <[e-mail]>
>
>AGENDA:
>
>===
>Group Admin
>---
>Chairs
>  Admin - Nothing much to say (in English anyway)
>        - In Korean, however, the following was said:
>          "Jigeumbuteo CCAMP meetingeul sijakhagesumnida".
>
>  Agenda bash (5 mins) - No changes
>  Status of WG drafts and milestones
>    Adrian's slides showed that we do have some draft
>    congestion in the WG.
>    - RFC editor queue
>    - status of IANA for SONET/SDH
>      Kireeti talked about an issue with SONET/SDH IANA
>      assignments
>    - need a means to get early assignments.
>      There is WIP to accomplish this, and it is moving
>      ahead.
>    - future allocation of "experimental" values
>
>Liaisons
>---
>Marco Carugi talked about work in SG-13 (SG13 liaison).
>  He covered topics, new study areas, timescales, objectives
>  and status. They are also looking for people interested in
>  doing work in these areas.
>
>  An L1 VPN questionnaire and framework draft were attached
>  to the liaison.
>
>  Tomonori Takeda talked about the technical issues and
>  details of the work.
>
>  Monique Morrow had a couple of clarification for Marco -
>  When will the consent portion of the work be done in the
>  ITU?
>
>    Marco said that the different pieces of work were
>    progressing at different speeds. Some material is
>    already embodied in recommendations. The next SG13
>    meetings are in June and September.
>
>  Dimitri Papadimitriou asked if the draft (l1vpn 
>  framework) provided in the liaison could include a 
>  summarization (as conclusion) on the expected GMPLS work
>  for the CCAMP WG, this would clarify the intent of the
>  liaison in term of expected effort for the CCAMP WG
>
>    Kireeti answered. If CCAMP's rechartering this month
>    results in the addition of L1VPNs to the charter, then
>    a Liaison response from the IETF will include this
>    information, plus a request for a cooperative effort,
>    preferably along the lines of the ASON routing work,
>    wherein the ITU-T defines the requirements and the IETF
>    does the protocol extensions.
>
>  Alex Zinin said that we will have to make a decision at
>  some point as to whether or not we want to do this work
>  here.
>
>  Someone from NTT raised a point that was not captured in
>  the minutes.
>
Kohei Shiomoto said that the protocol for the L1VPN should be developed 
at the IETF as long as it uses IP protocol. There are already 
internet-drafts on GVPN and CCAMP is the best place to discuss it.

>
>  Deborah Brungard said that there is work and some synergy
>  and that we should continue to work on this.
>
>    Monique Morrow agrees that we should work on that.
>
>    Marco added some comments that were not captured in the
>    minutes.
>
>    Malcolm Betts said he also feels that we should do this.
>
>  Adrian took a quick poll and it seems as if nobody is
>  against doing this work.
>
>  Kireeti reminded people to continue this discussion on
>  the list.
>
>---
>Lyndon Ong talked about work in SG-15 (3 liaisons).
>
>  Liaisons were on ASON routing requirements, response to
>  comments on Q14 for G.7713.2 and comments on the CCAMP
>  ASON signaling requirements draft.
>
>  Lyndon spent much of the time on the details of response
>  to comments on Q14. It seems that some of the differences
>  in architectural models revolve around "end-to-end" and
>  "call segment" operating models.
>
>  Kireeti asked for the reply by date.
>
>    Lyndon did not have that.
>
>    Steve Trowbridge said that the meeting starts on April
>    19th
>
>  Dimitri had a question on the deadline. There is a
>  deadline on G.7713 (April 2004), isn't there a similar
>  deadline on G.7713.2 (since this is the document to which
>  convergence is expected) ?
>
>    Lyndon said that he had not gone into that. He gave a
>    reason, but this was not captured in the minutes.
>
>  Deborah said that the liaison for 7713.2 does not say any
>  thing about convergence.
>
>    Lyndon said that they are still looking for a "meeting
>    of the minds".
>
>  Deborah said that there is an issue with G.7713.2 because
>  of compatibility.
>
>    Lyndon said that yes there has been a lot of discussion
>    of compatibility questions and requirements.
>
>  Kireeti said that we should not discuss this here.
>
>  Steve Trowbridge added some comments that were not
>  captured in the minutes.
>
>  Kireeti asked the WG to take this discussion to the list
>  and try to keep that discussion on a productive basis.
>
>  Adrian said that he wanted to recognize the efforts of
>  the ITU folks in this work.
>
>===
>ASON Requirements and Solutions
>---
>Dimitri Papadimitriou presented status of ASON Signaling
>Requirements (draft-ietf-ccamp-gmpls-ason-reqts-05.txt.
>
>  The requirements were driven by last year's liaison from
>  the ITU.
>
>  The discussion slides proposed to defer to the GROW WG 
>  (cf. RIFT WG item) concerning the (external) non-IP
>  reachability issue since much broader than just CCAMP
>  GMPLS/ASON context
>
>  After this meeting, Dimitri would like to re-spin the
>  draft and have a two week last call.
>
>  Lyndon said he want to capture the requirement on "non-IP
>  reachability" - whether or not we will work on it here
>
>  Kireeti said that we first need to understand importance
>  of this and then we can look to the ADs for guidance on
>  handling this.  He also said that we should take some time
>  to work out what we want to say to the ITU when we include
>  the current draft.
>
>---
>Dimitri Papadimitriou gave status ASON Signaling Solutions
>(draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt) status.
>
>  He would like feedback on whether or not the current draft
>  deals correctly with the session attribute object that
>  encodes the long call_id (alternatives were also proposed)
>
>  His objective at this point is to try to have a document
>  ready for last call for the next IETF 60 meeting in San
>  Diego
>
>  Lyndon suggested that we might remove the comparison with
>  G.7713 from the draft.
>
>    Adrian asked if this meant that the interworking draft
>    for RFC3473/4 interworking was now obsolete.
>
>      Lyndon said maybe, if interworking is removed as a
>      requirement.
>
>---
>Lou Berger talked about Egress Control -
>draft-berger-gmpls-egress-control-01.txt -
>
>  Original egress label control became explicit label
>  control. This draft attempts to capture the original
>  intent.
>
>  He wants to know if the WG feels that this is ready to
>  be a BCP and what the chairs think the next steps should
>  be.
>
>  Lou re-iterated that the purpose and scope of the draft
>  is for clarification. He does not see any value in adding
>  to this intent or combining it with other work.
>
>  Adrian then took a poll and nobody objected to take this
>  on as a WG item (more than a third were in favor).
>
>---
>Lyndon Ong went over status on ASON Routing Requirements -
>draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
>
>  He includes in his presentation the Design Team's 
>  conclusions as to what there is agreement about what's
>  missing from GMPLS (delta), and what are the areas on 
>  which there is no agreement about what's missing from 
>  GMPLS.
>
>  Vishal Sharma asked if the three issues (slide 6) were 
>  already opened up for discussion on the list, or would 
>  they be formally opened up with the DT members initiating
>  a discussion on these on the list?
>
>    Lyndon Ong replied that a discussion had not been
>    formally opened up yet (although people were free to
>    discuss/comment).
>
>      Kireeti asked Lyndon to more formally open this
>      discussion on the mailing list.
>
>  Vishal Sharma said that he supports this.
>
>  Kireeti said he would like - after checking with the AD -
>  that we should take this work to the IS-IS and OSPF WGs.
>
>    Alex Zinin said this is a good idea.
>
>===
>Tunnel Trace
>---
>Ron Bonica presented status on draft-bonica-tunproto-05.txt
>
>  The solution is very similar to Trace-Route but does not
>  require that each node in a tunnel supports TTL decrement.
>
>  He gave a few examples as to how the idea in the draft
>  will work in a few scenarios.
>
>  There are a couple of outstanding issues:
>  - trace requires a route to tunnel head end
>  - integration with LSP ping.
>
>  He would like to get the draft accepted as a WG draft.
>
>  Yakov asked what SPs use today for tunnel tracing.
>
>    Ron said that in some case people can use ICMP for MPLS.
>
>  Yakov then asked if we could get a BCP on what people are
>  doing.
>
>    Ron asked if he should resubmit his earlier draft on
>    this.
>
>      Kireeti said that we do not want to decide that now.
>
>===
>Protection and Restoration
>---
>Dimitri Papadimitriou presented status on the work of the
>Protection and Restoration Team - specifically:
>1) draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
>2) draft-ietf-ccamp-gmpls-recovery-functional-01.txt
>3) draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
>4) draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt
>
>  He gave estimates on the timing for each of the above
>  drafts (estimated completion dates).
>
>  He outlined the changes to the e2e signaling ID (draft 4,
>  above).
>
>  He encouraged the WG to really read the documents and
>  comment.
>
>  Kireeti polled for consensus on the following:
>
>    a) Analysis - last call? Some support, no objection
>    b) Functional - last call? Some support, no objection
>    c) Terminology - last call? Some support, no objection
>    d) e2e Signaling - WG document? Some support, no object
>
>  People at the microphone were asked to take their
>  questions to the list.
>
Kohei said that the e2e Signaling draft does not address the 
misconnection issues raised in the mailing list.
Dimitri answered that it is addressed in 8.3 of the draft.

Kohei said that the misconnection issue does not happen only in the P&R 
context but also in more general context and therefore should be 
addressed in more general context as well.
Kireeti said that the questions should be contiuned to the mailing list.

>
>---
>Lou Berger presented an overview of work on Segment
>Recovery - draft-berger-ccamp-gmpls-segment-recovery-00.txt
>
>  He also talked about what still needs to be done (next
>  steps), including more usage scenarios, more explanatory
>  text and see if the WG will adopt this work.
>
>  Arthi Ayyangar asked if the association object is required
>  even if we are only doing segment recovery (as opposed to
>  e2e).  She had follow up questions that Kireeti asked her
>  to take to the list.
>
>  Adrian polled for support of accepting this as a WG draft.
>  There was moderate support and no objection.
>
>===
>Inter-Area/AS
>---
>Arthi Ayyangar talked about the status of the merged draft
>on Inter-area/AS signaling -
>draft-vasseur-ccamp-inter-area-as-te-00.txt
>
>  The draft currently represents a full merge - work is 
>  still required to strip out redundant and unneeded text.
>
>  She said that the authors encourage people to come forward
>  with their comments.  She would also like to see if there
>  is interest in this work becoming a WG document.
>
>  Vishal Sharma said that the work should apply to general 
>  path computation domains and GMPLS LSPs.
>  In response to Arthi's question on Slide "Outstanding
>  Issues" (about whether detailed description of various 
>  path computation algorithms should be part of this 
>  document or separate document(s)), he supported the 
>  document being split into a framework document, discussing
>  signaling, and another document(s), discussing the path 
>  computation mechanisms, since the latter do not need to be
>  standardized.
>  In response to Slide "Outstanding Issues: Size of the 
>  document" and for clarity, he supported the splitting of 
>  the applicability statement into an independent document.
>
>  Dimitri agreed on the subject of separating the document.
>  In addition, he questioned about the relevance of using 
>  the LSP_Attributes to signal the signaling method for the
>  intra-area/-AS provisioning of the LSP.
>  In particular, he proposed to not include protocol 
>  procedures within examples/scenarios that makes the
>  document difficult to read.
>
>    Arthi asked that Dimitri take his specific comments to
>    the list.
>
>  Kireeti said that he agrees that the document needs to be
>  split - one as a signaling and another (informational) to
>  provide examples for path computation. He also said that
>  we need a separate applicability document.
>
>    Vishal Sharma then said that he would be happy to help 
>    with these tasks.
>
>---
>Vishal Sharma talked about work on Inter-area path
>protection
>draft-dachille-inter-area-path-protection-00.txt
>
>  He provided a brief overview of how it works, and showed
>  how it relates to other work in progress. He also listed
>  the next steps.
>
>  He emphasized that this is really a generic mechanism for
>  diverse path computation, and protection is one 
>  application of it, so the authors would respin with a new
>  name and emphasis to reflect this."
>
>  Zafar Ali asked how this would work if there is a failure
>  at the time during which the backup path is being setup.
>
>    Vishal replied that the solutions to this were, so far,
>    not discussed in the draft, but that there are several 
>    options. 
>
>    He then outlined some of the options. E.g. either 
>    default in such a case to a sequential computation, and
>    use XRO to exclude the link/node where backup path setup
>    failed, and retry the backup (and optimize both primary 
>    and secondary later using the techniques in the draft).
>    Or, set up the primary and the backup again, using the 
>    techniques described in the draft.
>
>    Vishal said they would be happy to add some discussion 
>    in the document, and welcomed feedback on the list.
>
>  Zafar asked how this work relates to PCS/PCE work.
>    
>    Vishal replied that it could actually be made use of by
>    the PCS/PCE approach, and could be viewed as 
>    complementary.
>
>  Kireeti asked that further discussion be taken to the 
>  list.
>
>  Vishal said he welcomed further feedback on the document.
> 
>  Dimitri asked why, knowing that the proposed approach 
>  works as expected in the intra-domain case when the 
>  number of ABRs (where computation can be executed at each
>  stage) does not increase, this approach is so focused on 
>  optimization (since it can't be achieved if this
>  condition is not met).
>
>    Vishal clarified that the focus of the work is to 
>    propose a generic mechanism to facilitate diverse path
>    setup by communicating alternate path info, with 
>    optimization a desired goal (for reasons explained in
>    the document).
>
>    Vishal added that given the network model (where border
>    nodes are not assumed to have visibility in areas other
>    than their own), the scheme was not trying to be 
>    globally optimal.
>
>    Vishal explained that in such cases some selection needs
>    to be performed at each stage.
>
>  Kireeti asked that further discussion on this should be
>  taken to the list.
>
>  Also, he said that Dimitri had a good point - we need to
>  define criteria on which any optimization is based.
>
>  Kireeti concluded by saying that path protection and 
>  inter-area are both in the charter, but that this document
>  could only be considered for a WG document after there was 
>  discussion about the document on the list.
>
>===
>Control Pane Resilience, Hello Protocol and Graceful Restart
>---
>Young Hwa Kim gave a presentation on Requirements for the
>Resilience of Control Plane in GMPLS -
>draft-kim-ccamp-cpr-reqts-00.txt
>
>  He described the reasons why control plane resilience is
>  needed.
>
>  Zafar asked how control plane resilience is different from
>  anything else in IP.
>
>  Steve Trowbridge said that their is also some work in this
>  area in the ITU and he would try to get this in as a
>  liaison as soon as possible.
>
>  Kireeti said that this is an important discussion and
>  there are a lot of things to do. Specific topics should be
>  raised on the list when appropriate.
>
>---
>Lou Berger went over Extensions to GMPLS RSVP Graceful
>Restart
>draft-aruns-ccamp-rsvp-restart-ext-00
>
>  He emphasized that egress restart is already covered in
>  RFC3473 and this work has no effect on that functionality.
>  He gave a brief overview and listed open issues.
>
>  Next steps include merging with other restart drafts and
>  seeing if this work can become a WG draft.
>
>  Arthi said that she feels that the document focuses too
>  much on the ERO. She feels that the draft should address
>  other issues and concerns with the mechanism.
>
>    Lou asked if she would like to contribute text.
>
>  The chairs then asked for other discussion to go to the
>  list.
>
>---
>Zafar Ali talked about Extensions to GMPLS RSVP Graceful
>Restart
>draft-rahman-ccamp-rsvp-restart-extensions-00.txt
>
>  Kireeti said that he appreciated the honesty of the
>  authors in acknowledging other work.
>
>  Nurit Sprecher asked about the relationship to FRR and
>  similar issues.
>
>    Adrian agreed that these were important issues and had
>    been raised on the list in recent days. He asked the
>    authors to make sure that they cover the points in the
>    draft.
>
>---
>Zafar then covered modifications to Hello procedures
>1) draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>2) draft-ali-ccamp-rsvp-hello-gr-admin-00.txt
>
>  He wants to go forward with draft 1 above.
>
>  Adrian polled and there was some interest and no strong
>  objection.
>
>  Kireeti said that this work cannot be informational if
>  it has - or proposes - changes to a standard.
>
>  Zafar also wants draft 2 to be a WG document.
>
>  Kireeti said that we need to take this to the list, but
>  Zafar also needs to socialize the work he is doing so that
>  people may decide whether or not this is work we want to
>  do.
>
>===
>Everything Else
>---
>Emmanuel Dotaro gave status of Multi-region protection -
>draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt
>
>  He briefly covered changes since previous versions.
>
>  He proposes that we may need to make changes to the
>  charter to include all of this work. In particular to
>  include in the charter the complete set of GMPLS 
>  mechanisms for integrated control planes, and not only
>  multi-layer recovery (as it stands today).
>
>  Adrian suggested that the authors need to get more people
>  involved in this important work and revisit this later.
>
>---
>Jean-Louis Le Roux - Advertizing TE Capabilities in IGPs
>draft-vasseur-ccamp-isis-te-caps-00.txt
>
>  He would like to have this accepted as a WG document.
>
>  Adrian asked to hold off on this until after the OSPF talk
>  below.
>
>---
>Seisho Yasukawa
>draft-vasseur-ccamp-ospf-te-caps-00.txt
>
>  He would like to have this accepted as a WG document.
>
>  Regarding both drafts, Kireeti is not sure that this work
>  belongs in this WG. The decision is driven by the
>  generality of its applicability. If we do take it on, their
>  needs to be a functional specification (independent of IGP)
>  as well.
>
>  He asked that further discussion be taken to the list.
>
>---
>The Following presentations were postponed as we ran out
>of time. Adrian made a couple of brief comments as follows:
>  ---
>  Zafar Ali - Explicit Resource Control and Tracking
>  draft-zamfir-explicit-resource-control-bundle-03.txt
>
>    This work concerns identification of component links in
>    EROs and RROs.
>
>    A small group is currently examining other issues
>    concerning identification of component links in all
>    aspects of GMPLS. A draft is expected soon. Please mail
>    Adrian or the list, if you want to be involved in this
>    work.
>
>  ---
>  Lou Berger - Alarm Reporting
>  draft-berger-ccamp-gmpls-alarm-spec-01.txt
>
>    This draft is stable and complete in the view of the
>    authors.
>
>    A quick poll showed some support for this being a WG
>    document, and no opposition. This will be taken to the
>    list.
>
>
>  
>

-- 
Kohei Shiomoto
NTT Network Innovation Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone [phone]    Fax [phone]