IETF 58 - L2VPN minutes

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

Folks,

Here are the minutes from the L2VPN session at IETF 58.  Sorry for the
delay.  Thanks to Alia and Ken for taking notes.

========================================================================
==========
Minutes L2VPN WG November 12, 1530-1730

Scribe: Kenneth Sundell <[e-mail]>
Scribe: Alia Atlas <[e-mail]>

L2VPN wg agenda IETF58 - Minneapolis

1. Agenda bashing

Loa: There is a custom in the IETF not to use two chairs from same
company
Rick to stay until next meeting (Rick and Vach at the same company).

No objections.
 
Loa went through the agenda
No changes to agenda

2. WG Status, Vach Kompella

Milestones:

At risk:
Aug 03  Submit an I-D describing MIB for VPLS 
Aug 03  Submit an I-D describing MIB for VPWS 
Vach: Submit Enterprise MIBs as jump start

Aug 03  Submit an I-D on OAM for VPLS 
Aug 03  Submit an I-D on OAM for VPWS 
Need to follow the OaM development happening in the MPLS WG closely
before persuing the work Need more participation

Oct 03 Submit L2 requirements to IESG for publication as Informational
RFC
Into last call soon (some security considerations issues)

Oct 03  Submit L2 framework to IESG for publication as Informational RFC

Ready to go too

Completed or threreabouts
Done    Identify VPLS and VPWS solutions for the WG 
Dec 03  Submit VPLS solution documents to IESG 
Dec 03  Submit VPWS solution documents to IESG 
A last call warning is issued to find traction. 

Andy Malis: Send it to the list

Looking good:
Jan 04  Submit IP-only L2VPN solution documents to IESG 
Seems Achievable

Feb 04  Submit MIB for VPLS to IESG 
Feb 04  Submit MIB for VPWS to IESG 
Achievable?


Working group documents

   a: draft-ietf-l2vpn-signaling-00.txt
      To be presented.

   b: draft-ietf-l2vpn-requirements-00.txt Waiting for Russ Housley's
      comments (sec advisor) otherwise ready to go

   c: draft-ietf-l2vpn-l2-framework-03.txt
      Eric Rosen

   d: draft-ietf-l2vpn-vpls-bgp-00.txt
      Kireeti Kompella

   e: draft-ietf-ppvpn-vpls-ldp-01.txt
      Need to rename draft from *ppvpn* to *l2vpn*

   f: draft-shah-ppvpn-ipls-02.txt 
      Will be published as a wg doc

   g: draft-heinanen-radius-l2tp-vpls-00.txt (will be published as a wg
      doc) Mark Townsley picked up the work after Juha Heinanen, the
      document was already approved as a working group document (not
issued
      as that this time).

      Mark Townsley: Will resend the document with wg status, but
solicits
                     comments on the list before doing do.

   h: draft-heinanen-radius-pe-discovery-04.txt (will be published as a
wg
      doc) Should have wg status. Greg Weber wasn't present, but Mark
said
      that the same procedure will be applied for this work as well.

3. Detecting and Reacting to Failures of the Full Mesh in IPLS and VPLS
   draft-rosen-l2vpn-mesh-failure-00.txt
   Eric Rosen

Assuming that full mesh of PW's is present, if assuption fails, 
blackholes can occur.

Failure modes:
  - data plane connectivity
  - PW state at edge
  - auto-discovery failure or configuration mismatch

Bad ideas for detecting failures
  - local information (detection only)
    - mismatch between operational PWs and discovered endpoints
    - PW operational status changes
  - global information (resilience)
    - PWs as overlay network, Spanning tree
    - PWs as overlay network, run routing
    - but don't really want to run a routing protocol or spanning tree
    - overhead costs

Not so quite bad idea
  - global information (detection only)
    - each edge tells every other edge "here are the PW endpoints i can
      talk to"
    - get global info, from each edge, set of other edges that can be
seen
    - any edge not universally seen is removed from the mesh

What is the reaction after constructing this information?
  - log the failure
  - or fix the failure through re-routing
  - most important is to get the detection part

Is this worth pursuing?

Yakov: Does it need to be new protocol to existing ones or done by nms
(mibs)

Vach: The approach is to detect, fixing things is another question

Eric: By NMS do you mean some mgmt station or from each PE

Yakov: From mgmt station

Vach: Not necessarily need protocol, but we don't want SNMP gets between
PEs

Eric: In practice, using NMS to detect dynamic problems hasn't
historically
worked well.

Yakov: Have traps when PW goes up and when goes down, so can check
adjacency.

Vach: If just wanting to detect, then MIB could be enough.  If more than
that.

Eric: Be careful.  One could build a tool to look at the MIB info to
      determine this.  How happy are people with depending on NMS yet?

Yakov: If all the protocol is to do is detection, then need operator
action
using nms to fix problem

Vach: we haven't determined the scope of the problem yet, so maybe
detection is sufficient

Liam Casey: The detection time has to be fast, comparable to control
plane.
Agree to pursuing the work. Propose to do it in the control plane as
opposed to the management plane for default border repair.  Suggest that
failure mode is "if one router can't be reached by another, then no
router
should be allowed to reach."

Jack Lukaski/Lewkowski: Do not reinvent the weel. use existing protocols
done elsewhere in this domain (SONET, ATM F4/F5 AIS).  Separate in-band
from out-of-band.

Vach: Asking the WG if this is an important problem to solve?
Yes: a fair number of hands
Opposed: None

Vach: The consensus to be verified on the list

Eric: Had already raised on mailing list, said wasn't important and was
beaten up.  But dead silence now.

4. The "generalized FEC ID" in the PWE3 control messages, as discussed
in
    draft-ietf-pwe3-control-protocol-04.txt

draft-ietf-l2vpn-signaling-00.txt Eric Rosen

PWE3 control protocol draft (in lc) define it
Superset of signaling paradigm in VPLS-LDP spec (L2VPN WG draft)

Eric: Can we all agree to use it?  It has been sparsely discussed on the
mailing list by a few persons.  There do not seem to be any substantive
technical issues with it

Vach: Think we can close on this but want to hear others opinions.
Naming
of a VPLS is going to change substantially.  Not many are involved in
the
discussion (even if people seem to go off and implement it) Have a
couple
of issues: most important is to drop the distributed VPLS part, since
nobody is doing that.

Eric: Some people in WG are interested in distributed VPLS.
Inter-provider
case may need it.  Friends from Nortel should jump up.

(Aside from Vach: Hamid from Nortel did come to chairs and ask that it
should be retained).

Rick: Input from VPLS implementers?
No response

Eric: We got so tired doing the framework and requirements that at this
point nobody cares..?

Loa: Hmmm no responses.  This is how we handle it, three weeks on the
mailing list, no comments and we go with the solution.

End of session