Subject: Re: Updated L2VPN WG charter

From: Loa Andersson <[email-masked]>
Date: Sat, 07 Jun 2003 20:56:14 +0200

L2VPNers,

I've put a few questions into the updated version of the l2vpn charter,
background is some wg chair experiences, so it is at this point rather
formalistic issues. The kind of stuff a wg chair will ask him- or
herself when approached by people wanting to do (not to do) certain
things at a specific point in time.

Note: at this time I'm still playing catch up and is not through all
my mail and haven read this thread to the end, Soit is possible that
I'm knocking in open doors. In that case just ignore.

/Loa

------------------------------------------------------------------------

Layer 2 Virtual Private Networks (l2vpn)

Chairs: <under discussion>

Area Director(s):
    Thomas Narten <[email-masked]>
    Erik Nordmark <[email-masked]>

Area Advisor:
    Thomas Narten <[email-masked]>

Technical Advisor:
    Alex Zinin <[email-masked]>

Description of Working Group:

This working group is responsible for defining and specifying a
limited number of solutions

Qustion: What is a limited number of solutions? Understanding that
it is not possible to give an exact number, there is nevertehless
a need to understand what the limitations are. A 100 is still liomited,
but so is 1 or 2.

for supporting provider-provisioned
layer-2 virtual private networks (L2VPNs).

The WG is responsible for standardization of the following solutions:

1. Virtual Private LAN Service--L2 service that emulates LAN
    across an IP and an MPLS-enabled IP network, allowing standard
    Ethernet devices communicate with each other as if they were
    connected to a common LAN segment.

Question: Since there are no MPLS enabled networks that are not IP
           networks (control by an IP routing protocól), it is an open
           issue how to read this.

           Should it be read as:
           a. one solution for IP networks
           b. another for MPLS enabled networks
           c. or a common solutions that works in both MPLS enabled
           networks and in IP networks that is not MPLS enabled

2. Virtual Private Wire Service--L2 service that provides L2
    point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
    point-to-point Ethernet) across an IP and an MPLS-enabled IP network.

Question: Same as for item 1.

3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
    IP network, allowing standard IP devices to communicate with each
    other as if they were connected to a common LAN segment or a point-
    to-point circuit.

The WG will address intra-AS scenarios only at this point (other
scenarios will be considered for inclusion in the updated charter when
the current one is completed.)

Question: "Completed" is fuzzy, when is something completed
            - wg last call done,
            - sent to the iesg for review
            - iesg decision
            - published as RFC.

           It is likely that the point in time is when the previous
           task is "90% done" is when something could be viewed as
           completed from a wg point of view.
           One would need more freedom, and the IETF process is probably
           good enough "after the wg have requested a charter update
           from the iesg and have had that request approved".

As a general rule, the WG will not create new protocols, but will
provide functional requirements for extensions of the existing
protocols that will be discussed in the protocol-specific WGs.
The group will review proposed protocol extensions for L2VPNs before
they are recommended to appropriate protocol-specific WGs.

Question: Can't make head an tail of this. If the wg produces
           "requirements" to be sent to a protocol specific wg,
           once this is done the work will be done within that wg.
           No? If not is the process that we produce "requirements"
           that will be "discussed in the protocol specific wg" and
           once approved by wg and the iesg, the l2vpn wg will
           develop the extensions that will go through the same
           process. Could become a bit cumbersome.
           If we are not doing the extension, how do we make sure
           that we have the attention on the other working group.

As a specific example, this WG will not define new encapsulation
mechanism, but will use those defined in the PWE3 WG.

The WG will work on the following items. Adding new work items
will require rechartering: rechartering.

Question: This is possibly too restrictive, we might see that there are
           work items that are "within charter" and we would like to
           undertake those task, but it wouldn't require a new charter.

1. Discovery of PEs participating in L2 service, and
    topology of required connectivity

2. Signaling of pseudo-wire and service parameters

3. Solution documents (providing the framework for a specific
    solution, should include info on how discovery, signaling,
    and encaps work together, include security, AS as a separate
    document)

4. MIBs

5. L2VPN-specific OAM extensions--extensions to existing OAM
    solutions for VPLS and VPWS.

Question: OAM for IP only L2VPNs?

6. Interworking of IP devices connected to an IP-only L2 VPN using
    dissimilar attachment circuits. This topic will be explored only
    after the basic L2VPN services (VPWS, VPLS, and IP L2VPN) are
    defined.

Where necessary, the WG will coordinate its activities with IEEE 802.1

Question: Wouldn't it be appropriate to look into re-using mechanisms
           that are (have been) developed by the l3vpn wg? And the other
           way around?
           Or is this within the IETF mode of working, and need not to
           be explicitly stated?

Milestones (optimistic):

JUL 2003  Submit L2 requirements to IESG for publication as
           Informational RFC
JUL 2003  Submit L2 framework to IESG for publication as
           Informational RFC
JUL 2003  Identify VPLS and VPWS solutions for the WG
AUG 2003  Submit an I-D describing MIB for VPLS
AUG 2003  Submit an I-D describing MIB for VPWS
AUG 2003  Submit an I-D on OAM for VPLS
AUG 2003  Submit an I-D on OAM for VPWS
DEC 2003  Submit VPLS solution documents to IESG
DEC 2003  Submit VPWS solution documents to IESG
JAN 2004  Submit IP VPN solution documents to IESG
FEB 2004  Submit MIB for VPLS to IESG
FEB 2004  Submit MIB for VPWS to IESG
MAR 2004  Submit OAM for VPLS to IESG
MAR 2004  Submit OAM for VPWS to IESG

-- 
/Loa

mobile + 46 739 81 21 64
email: [email-masked]

---

From: Alex Zinin <[email-masked]>
Date: Mon, 9 Jun 2003 12:59:51 -0700

Loa,

> I'm knocking in open doors. In that case just ignore.

Thanks for thoughtful comments. It is a good idea to clarify possible
interpretations now. Please see inline below

> a need to understand what the limitations are. A 100 is still liomited,

My opinion is that the _default_ mode for the WG should be one
solution per item of the list below (VPLS, VPWS, IPL2VPN), each going
to STD track. If the WG believes at some point that more than one is
necessary, than (as usual) a strong case would need to be made wrt why
one is not enough.

>            networks and in IP networks that is not MPLS enabled

The intent is to say that the WG should aspire to "c" above.

>             - sent to the iesg for review

I would consider an document/milestone completed when the IESG
review is completed and it's approved.

>            from the iesg and have had that request approved".

The way I see this happening is that the WG chairs and ADs would
discuss the matter, and as soon as both sides are comfortable with
adding more work on the plate, new items would be taken on. The intent
of that piece of the charter is to set priorities for the WG.

>            that we have the attention on the other working group.

We had a discussion about this on the list. The text above tries to
capture in a short form what I described in my message on May 9th:

Alex Zinin wrote:
[...]
> 3. In reality, what we want to achieve is the VPN community being
>    able to propose and document extensions to existing protocols
>    that would help VPN technology development. Also, before a given
>    mechanism goes forward, we need to make sure that:
> 
>      a. The VPN community believes that it serves the purpose
>         and the right way forward
>      
>    AND
>    
>      b. The protocol-specific community believes that using
>         the protocol is a good idea and the way this is done
>         is correct.
> 
>    Given that finally the extension specs have to live in the
>    protocol-specific WGs, ow about we use the following process
>    (draft):
> 
>      1. VPN folks who believe that a given protocol extension
>         is needed, come up with an individual draft describing
>         the details.
> 
>      2. The draft is brought to the appropriate VPN WG. A discussion
>         on the mailing list AND in the room is held on the subject of
>         why this is needed and whether this is a good idea VPN-wise.
>         If there is no agreement on this--the draft does not go
>         any further. Otherwise:
> 
>      3. The draft is taken to the protocol-specific WG. The WG
>         discusses if it is happy with it as a general approach, if
>         so takes it as a WG item. Otherwise, the WG chairs summarize
>         the discussion and send the summary to the VPN WG.
> 
>      4. If the draft is accepted by the protocol-specific WG,
>         the appropriate VPN framework document is updated to describe
>         it and refer to the doc.
> 
>      5. The WG chairs coordinate timing for the draft.
>         When ready to go to IESG, the draft is LC'ed in both WGs.

Please see if this makes sense.

>            undertake those task, but it wouldn't require a new charter.

The intent here is again to give WG chairs and ADs a tool to control
the amount of work in the WG. For instance, if we wanted to add QoS,
we would need to add an item to this list, and hence revise the
charter.

If an item is within the charter, then adding it should be a matter
of adding a milestone, which is a much less painful procedure.

> Question: OAM for IP only L2VPNs?

No objection

>            Or is this within the IETF mode of working, and need not to

I would say this consideration will anyways be on a case-by-case
basis, which is, as you say, already the normal IETF mode.

Thanks

Alex

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 9 Jun 2003 19:58:41 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Alex Zinin
> Sent: Monday, June 09, 2003 4:00 PM
> To: Loa Andersson
> Cc: l2vpn; Thomas Narten
> Subject: Re: Updated L2VPN WG charter
> 
> 
> Loa,
> 
> > I've put a few questions into the updated version of the l2vpn 
> > charter, background is some wg chair experiences, so it is at this 
> > point rather formalistic issues. The kind of stuff a wg 
> chair will ask 
> > him- or herself when approached by people wanting to do (not to do) 
> > certain things at a specific point in time.
> 
> Thanks for thoughtful comments. It is a good idea to clarify 
> possible interpretations now. Please see inline below
> 
> > Qustion: What is a limited number of solutions? 
> Understanding that it 
> > is not possible to give an exact number, there is 
> nevertehless a need 
> > to understand what the limitations are. A 100 is still 
> liomited, but 
> > so is 1 or 2.
> 
> My opinion is that the _default_ mode for the WG should be 
> one solution per item of the list below (VPLS, VPWS, 
> IPL2VPN), each going to STD track. If the WG believes at some 
> point that more than one is necessary, than (as usual) a 
> strong case would need to be made wrt why one is not enough.

	Alex,

	I like this idea in theory, but in practice, how is
the determination of going with one over the other going to
be made if the WG seems fairly divided? I have seen this
handled in different ways in different WGs in the past, but
it was never consistent. I guess we could always call in 
the VP to breat the tie or flip a coin? *)

	--tom

> I would consider an document/milestone completed when the 
> IESG review is completed and it's approved.
> 
> The way I see this happening is that the WG chairs and ADs 
> would discuss the matter, and as soon as both sides are 
> comfortable with adding more work on the plate, new items 
> would be taken on. The intent of that piece of the charter is 
> to set priorities for the WG.
> 
> > protocols that will be discussed in the protocol-specific WGs. The 
> > group will review proposed protocol extensions for L2VPNs 
> before they 
> > are recommended to appropriate protocol-specific WGs.
> 
> We had a discussion about this on the list. The text above 
> tries to capture in a short form what I described in my 
> message on May 9th:
> 
> Alex Zinin wrote:
> [...]
> > The WG will work on the following items. Adding new work items will 
> > require rechartering: rechartering.
> 
> The intent here is again to give WG chairs and ADs a tool to 
> control the amount of work in the WG. For instance, if we 
> wanted to add QoS, we would need to add an item to this list, 
> and hence revise the charter.
> 
> If an item is within the charter, then adding it should be a 
> matter of adding a milestone, which is a much less painful procedure.
> 
> I would say this consideration will anyways be on a 
> case-by-case basis, which is, as you say, already the normal 
> IETF mode.
> 
> Thanks
> 
> Alex
> 
>

---

From: Alex Zinin <[email-masked]>
Date: Tue, 10 Jun 2003 14:42:06 -0700

Tom-

> the VP to breat the tie or flip a coin? *)

This topic is what we (the ADs and the WG chairs) are discussing now.
There is no magic wand. However, what I can say already is:

 1. If the WG is able to make the decision, we should do everything
    possible to make this happen--no doubt that decisions made by
    consensus are preferred over all other options.

 2. I'd like us to have a clear understanding on the way forward (read
    have made all necessary decisions) two weeks from Vienna the latest.

 3. To make this possible, we'll start the discussion right after
    the charter has been approved.

Alex