Minutes and action items from IETF 57

["Vach Kompella" <[e-mail]>]

I finally got the minutes merged.  Thanks to Dinesh and Sunil for taking notes.
Raw notes files attached.  I'll send another email with the presentations.

Action items (I will send out separate emails on each item as needed):
  - Discussion on mailing list on both WG VPLS solutions
     - issue 1: do we move forward with two solutions?
     - issue 2: do they solve different problems, and if so, need
       applicability stmt for each one

  - Discussion on mailing list - IPLS: draft-shah
     - pretty good response from the room
     - need to verify on mailing list
     - address issues (Cheng-Yin's)

  - note to iesg for interworking
     - what is in scope and what is out
     - comments from WG on draft-shah interworking
     - is draft-sajassi in scope?

  - draft-sodder
     - need to get better refs for mac-in-mac, along with
       some indication that IEEE is in support

  - draft-vpls-ldp
     - change of vc type + opt parameter for
       signaling split horizon
     - change of id from vcid to pwe3 generalized id
       with some modifications

  - draft-radoaca
     - need mailing list response if ready for WG
     - does it need more clarification or is it just broken?

  - requirements
     - 4 week last call issue

  - framework
     - thought it was ready for last call
     - recent comments on mailing list may require some changes

  - draft-rosen
     - need to move it along

  - CE-based VPLS
     - why is it in scope?  Cheng-Yin to address

========================================================
L2VPN minutes from IETF57

Minute takers: Sunil Khandekar, Dinesh Mohan

Agenda bashing:

   Russ is the technical advisor for security

   ppvpn is no longer existent
   start using l2vpn mailing list
   common stuff on l3vpn
   web page with the charter already up
   tried as much as could from ppvpn that is relevant

   three types of vpns - vpws, vpls, and ipls

   ce-based solutions in the charter or not?
     one solution out there which is vpls from customer and
     vpws from provider

Cheng Yee - it is not vpls since it is not full mesh

   Not in charter - inter-area l2vpn and multicast
   4 working group documents
      - l2 framework -03,
      - vpls-bgp-00.txt new draft, discussion needed on mailing list
      - vpls-ldp-00.txt new draft, discussion needed on mailing list
      - l2vpn-requirements-00.txt this is up for last call after meeting

Loa: Issue: IESG is interested in a single solution

       Bilel - how do you define single solution

       Yakov - do not understand why single solution

       Loa - as a operater, not as a chair, is interest in single
             solution for a single problem, no need to have two
             solutions for one problem, if two solutions, then must
             be two problems

       Alex - why are we here, work on a standard for each problem,
              therefore two solutions for the same problem is not
              useful

       Yakov - why this was not applicable to l3vpn yesterday, ietf
               should not be in business of deciding how many

       Alex - each one of us has personal opinion, why people are here
              in the room, lets not have this discussion here since
              not in agenda, but needs to be discussed since IESG
              needs

       Vach - can we hear other people what their opinion is, after we
              hear it on mike, lets take it to mailing list

       Bruce Davies - good to have one standard, but IETF has seen
                      multiple standards in past, lets try to come
                      something that wg can reach standards

       Hamid - way the solutions are decomposed is not correct,
               ldp/bgp since in ldp bgp may be used for
               auto-discovery
             - if functional decomposition done then we do not get
               into this discussion, e.g. l3 may want to use l3 as
               much as possible

       Kireeti - if we can do two

       Ross - working in standards for long time, never seen standards
              body being choosy between solutions

       Ali - show of hands

       Vach - before we do show of hands, how many have read each one
              show of hands to see one or multiple solutions
            - it is tie
            - we will go with multiple solutions for now
            - discussion on mailing list

Loa - Candidate L2VPN drafts
       - shah-ipls
       - sodder-ppvpn-vhls-02
          Vach - is this in scope? questionable
               - to be asked on the mailing list
               - verify with ADs
       - radoaca (GVPLS)
       - carugi-ppvpn-solution-doc-guidelines-01
          Loa - we may want to keep this draft, do we need to make it rfc?]
       - lee-ppvpn-hybrid-vpls-01
       - stokes-vkompella-ppvpn-hvpls-oam-02
       - shah-ppvpn-arp-mediation
       - sajassi-interworking
       - lee-ce-based
       - any missing?

Marco - targets of carugi-ppvpn-solution-doc-guidelines-01, to push
        solution proposals to document how they satisfy requirements,
        to begin applicability analysis and to promote convergence in
        the solution space.

Vach - can ADs confirm whether the sodder-draft falls in the l2vpn
       charter?

Loa - draft-shah-arp-mediation is out of scope
      draft-sajassi-l2vpn-interworking is out of scope
      draft-ce-based is out of scope, for now

      Ali - Disparate attachements ckts is a real problem so where
            will we address this.

      Vach - Per the charter this is out of scope. We have to decide
             whether members feel whether we need to address this
             here.

      Hamid - Commenting on charter; It says IP VPN and I read that as
              any particular attachment circuit and hence it should be
              in charter

      Alex - The inter-working part was part of the charter when it
             went to IESG.  IESG was concerned that we might be
             stepping on other bodies toes and hence it was taken out.
             Lets gauge the consensus in the room and then take up
             with issue again with the IESG.

     Arvind - draft-sodder fits in this WG.

     Vach - Need normative ref for MAC-in-MAC encap

     Arvind - I will take up the encap We need a normative reference
              for the encap.

     Vach - AFAIK, None was given in the draft.  If you can find a ref
            that is a standard or standards track

     Dinesh - Normative as something that is a std or a
              work-in-progress docs?

     Vach - Std is preferred or work-in-progress on its way to become
            a std is acceptable.

     Dinesh - Before the last call, I understand the requirement but
              initially it is ok to refer to some other work in
              progress.

     Tom Narten: This is a well known process you should give as much
                 info as possible on reference to a work

Loa - Missing components
         - applicablility statement per solution
         - security framework
            - to be worked with Luyuan Fang
         - mib modules
            - need volunteers starting to draft what mibs would look like

       Tom Nadeau - we have pwe3 mibs that kept services like this in mind
       Loa - would you volunteer to write a doc to describe scope
       Tom - yes

Loa - Organizing ourselves

      - When you submit a draft to this WG the naming convention
        should be draft-name-l2vpn-xxx-yyy-00.txt

      - Once it become a WG doc the name changes to:
        draft-ietf-l2vpn-xxx-yyy-00.txt.

      - If you do presentations please follow the a format that has
        the page numbers on the slide, the issues

ISOCORE - Interoperability test from March IETF - presented by Bill Jensen
 - does not support any particular company - no pictures of Loa this time!
 - scope of interworking - mpls rsvp-te/ldp signaling
      ldp over rsvp tumnels
      mpls based services
      p2p l2vpn - fr, ehternet/ethernet VLAN, VC tunnel scaling scenarios
      l3vpns
      multicast vpns
 - vpls specific issues - updates from march
   - clear definition of VPLS encapsulation actions - fixed
   - ambiguity in the lsr-id
   - ...
 - summary
    ISOCORE leveraged the N+I demo at Las Vegas
    ....
 - Upcoming MPLS/GMPLS testing
   - isocore code testing Aug 4th-Aug 14th
    ....

 Danny - Is the methodology and ... available

 Bill - Yes methodology is available, but some things are under
        non-disclosure

 Danny - can you elaborate multicast vpls?
    - (didn't catch answer)

 Hamid - p2p l2vpn - did you mean the work in pwe3?
   logically the only layer that belongs here is martini
 Bill - maybe should not try to speculate here
 Bijan - Isocore - the point was that we wanted to test compatibility
         between draft-martini and VPLS


Himanshu Shah - Cienna IPLS
draft-shah-ppvpn-IPLS-01.txt

    - predominantly the traffic is IP so IPLS is adequate, supports IP
      devices only, subset of VPLS service

    - adv: no MAC learning at the data plane, no aging, no BPDUs,
      GVRPs, easier to support PE routers etc..

    - when is VPLS needed - when world needs

    Cheng yin - There are lot of issues that I have raised. Are you
                going to address this?

    Himanshu - Yes those will be addressed.

    Vach - you cannot do the comments here, lets get the comments in
           mailing list

    Ali - should address qiq interoperability, partial mesh failure -
          so having end-points as IP does not remove this problem

    Bruce Davis - Show of hands in support

    Vach - pretty good support

    Dinesh - ieee partial mesh issue is actually applicable to all
             VPLS solutions

    Arvind - should also ask support for WG

    Vach - Show of hands to make it WG 15-20, not to make it WG - 1

    Vach - should be also asked on the mailing list if this is ready to become a
WG document



Vach Kompella
draft-ietf-ppvpn-vpls-ldp-00.txt

    Vach - VC-type changed from 0xb to 0x5
         - Handful of hands in favor of adding an optional parameter
           to indicate the VPLS type.
         - Have a VPN-id TLV that allows indicating the type of VPN-id
           that is being used.

    Ali -

    Hamid - Use the PW signaling.  That signaling contains the
            generalized signaling field.  Why not use that?

    Vach - I am just asking for the AGI field to be changed to TLV

    Hamid - There is already some discussion going on in PWE3 to change that.

    Vach - That is what I am proposing

    Hamid - OK

    Luca - why is 32 bits not enough?

    Vach - 32 bits is not enough for inter-galatic VPLS (really not
           sufficient for inter-region and inter-AS VPLS)

    Luca - lets do it in 1000 years then

    Vach - This takes care when the VPLS spans multiple area.  Even
           though that is out of scope right now, when we do move
           there I don't want to restrict ourselves.

    Luca - just introduce a TLV and call it "name"

    Vach - that is what I am doing

    Luca - Please propose this on the PWE3 mailing list.

    Vach - will do.

    Hamid - It is just not a question of why 32 bits is not enough, it
            is because we need a way to identify a set of
            pseudo-wires.

    Hamid - 32 bit is not enough since it needs to be globally unique

    Kireeti - use route targets (48 bits) and then you will get
              discovery too.

Vasile Radoaca
draft-radoaca-ppvpn-gvpls-02.txt

    Peter - Lucent - If you look at the disctributed model, you have
            end to end LDP, do not understand incremental solutions

    Vasile - distrubution model is distribution of functional
             elements, in VPLS MAC learnning is impo functional model,
             therefore access technology is not made specific

    Peter: Why tie separate pseudo-wire together rather than treat it
           end to end

    Vasile: Model is to decompose the access and core and the access
            can be any type

    Ali: I think the question was about splicing and the reasons for
         that is to allow reduction in the number of LDP sessions.

    Ali: You are still using separate pseudo-wire for unicast and
         multicast.  Is it still true?

    Vasile: Yes but this allows it to scale better.

    Ali: The BPDUs of the customer can take a different path from
         unicast pseudo wire and if there is an issue the end
         customers will not be able to detect this.  This will be a
         problem.

    Loa: Please take this on the mailing list.  Are you proposing to
         make WG doc?

    Vasile - yes, make it WG document

    Loa: How many would like this to be a WG doc and how many would
         not?  More people were against the draft then for.  Go back
         to mailing list for more feedback.

    Tom Narten - clearly no consensus here
        - so do we need to see what needs to change to get more
          support, or is it fundamentally a broken idea?

    Ali - we agree that there are merits and some issues in the
          draft. We need to ensure that we address the issues without
          wiping out the merits.

Himanshu - ARP Mediation

    Vach - how many people have read, support

    Vach - is it in scope or out of scope

    Alex - this is out of scope
         - WG would like to proceed with this and ball is now in IESG
           court

    Loa - is WG requesting the IESG

    Andy - Inverse ARP is IETF RFC, Inverse ARP for ATM is IETF RFC,
           this is just trying to mediate between the two, what is the
           issue

    Alex - how is IS-IS supported in this case

    Himanshu - IS IS is not supported

    Ali - My draft supports IS-IS and I would like Alex to take my
          draft up with the IESG as well to make it in scope.

    Ali - bridge encap in is addressed in draft-sajassi interworking,


Yetik - Requirements

      - some of the requirements may be out of scope because of
        charter change between L2VPN and PPVPN, should we keep them in
        requirements or take them out

      Hamid - which of these requirements would be out of scope

      Yetik - For e.g. inter-AS

      Loa - 4 weeks for the WG last call

Final remarks

      Vach - Cheng Yin to bring the issues of CE-based on mailing list

      Ali - HVPLS OAM is on agenda?

      Vach - HVPLS OAM is not on the agenda

      Ali - the OAM mechanism that we come up should be transport
            agnostics.

-Vach