Subject: working group last call on draft-ietf-mpls-tp-requirements-04
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 06 Feb 2009 11:11:08 +0100
List-Id: <l2vpn.ietf.org>

All,

this is to initiate a working group last call for 
draft-ietf-mpls-tp-requirements-04.

This document is one of the key documents for the mpls-tp work,
in particular it is important that the ITU-T mpls-tp ad hoc team
verifies the completeness of the requirements and that we have a
good review form all parties.

Please review and send your comments to the mpls-tp list,
i.e. try to avoid doing a "reply all on this message" !

The working group last call will end on Feb 28, 2009.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Date: Fri, 06 Feb 2009 15:20:00 +0000
Subject: Re: [PWE3] working group last call on draft-ietf-mpls-tp-requirements-04
From: Ben Niven-Jenkins <[email-masked]>
To: Loa Andersson <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Colleagues,

In my rush to get this ready for last call I made an editing mistake,
requirement 30 currently reads

   30  MPLS-TP MUST support unidirectional, bidirectional and co-routed
       bidirectional point-to-point transport paths.

But it should read

   30  MPLS-TP MUST support unidirectional, bidirectional and associated
       bidirectional point-to-point transport paths.

This has no impact in terms of the meaning of the requirement, just an
editing error where I updated the terminology section to reflect discussion
on the MPLS-TP mailing list but forgot to subsequently update the
requirement to use the agreed term.

Ben

On 06/02/2009 10:11, "Loa Andersson" <[email-masked]> wrote:

> All,
> 
> this is to initiate a working group last call for
> draft-ietf-mpls-tp-requirements-04.
> 
> This document is one of the key documents for the mpls-tp work,
> in particular it is important that the ITU-T mpls-tp ad hoc team
> verifies the completeness of the requirements and that we have a
> good review form all parties.
> 
> Please review and send your comments to the mpls-tp list,
> i.e. try to avoid doing a "reply all on this message" !
> 
> The working group last call will end on Feb 28, 2009.
> 
> /Loa

Date: Tue, 10 Feb 2009 18:30:31 +0900
From: "Yuji KAMITE" <[email-masked]>
Subject: RE: Comments to VPMS Requirements
To: "'Greg Mirsky'" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0120_01C98BAD.A7A325E0
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hi Greg,

Thanks for comments.  See inline below please.

  _____

From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Saturday, January 24, 2009 6:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: Comments to VPMS Requirements

Dear Yuji and All,
please find my notes to the document below:

*	Section 4.1

"However, if only P2MP connectivity is required, the traffic between different receivers is not always needed, and traffic from
receiver to sender is not always needed, either."
I believe that in P2MP constructs connectivity between leafs is not just "not always needed" but prohibited. To enforce this might
require extra efforts if P2MP uses VPLS. I propose changing this to:
"However, if only P2MP connectivity is required, the traffic between leafs is not allowed. It might require extra efforts to
guarantee this behavior in VPLS. And in some P2MP scenarios there no traffic from leafs to root."

Agreed.

*	Section 4.2

I'm not sure how second paragraph of the section 4.2 is related to the subject of P2MP scenarios in TDM. And perhaps
"drop-and-continue" TDM-based applications might be added as one of use cases that can benefit from VPMS.

I think you probably mentioned Section 4.3.
Section 4.3 describes the use case of multicast clock distribution that master clock is delivered via TDM P2MP-PW.  Several end
hosts
will receive the same TDM channel via p2mp topology efficiently.

What kind of actual applications do you assume in "drop-and-continue"?
Are you looking at SONET-SDH ring protection's context, TDM-based multicast video delivery usage, or anything else?
Could you elaborate the application scenarios a little more if you have?

*	Section 5

Following seems somewhat ambiguous since frames might not be just duplicated but replicated multiple times on the same node (PE or
P)
"The SP's network (PE as well as P) has a role to duplicate frames so that the traffic source does not need to send multiple frames
to individual receivers."
I think that it can be clarified as:
"The SP's network (PE as well as P) has a role to replicate frames so that the sender's CE does not need to send multiple frames to
individual receivers."

OK, I'll correct.

Is following a requirement or a statement:
"In a VPMS, PEs will be connected by PW technology which may include P2MP traffic optimization ..."
If this is a statement that perhaps it can be re-worded as more probable wording like
"PW technology with P2MP traffic optimization might be used in a VPMS ..."

Agreed.

I don't understand if following is a requirement or statement of benefit:
"Also routed backbone provides IP or MPLS-enabled PSN tunnels for transporting the PW traffic."

It is just for an explanation about whole framework, i.e., it's shown PSN tunnel is expected to be naturally used as a transport
technology for PW in VPMS. I'll consider editorial changes around here to make it more clear.

*	Section 6.1.2 Multiple Source Support

I understand this section as expression of requirement of VPMS's high availability. Is that correct understanding? If so, then I'd
propose to change the name of the section to "VPMS High Availability" or remove the section all together since the subject is
covered in section 6.4 Protection and Restoration. For one I'd suggest removing reference to support of multiple senders/sources in
VPMS and mention redundant ACes. How to provide high availability in VPMS, I believe, is outside of the scope of the document but it
is worth mentioning some of possible mechanisms, e.g. redundant ACes, redundant p2mp PWs, p2mp LSP protection, etc.

I think supporting high availability is a basic and important service requirement, so it's worth documenting even though the
detailed
functional discussion (e.g., about P2MP PW, LSP etc.) are out of the scope in this draft.

But I agree with your opinion that Section 6.1.2 largely overlaps with　Section 6.4 now. I'm going to merge/edit to make a unified
section about high-availability  as much as possible.

As you pointed out, redundant (sourc-side) ACes is　actually equivalent to redundant sources.  I'll  try to change the text.

*	Section 6.1.3 Reverse Traffic Support

"The simplest way to accomplish this is to provide different VPMS instances for reverse traffic, i.e. a sender CE is a receiver of
another VPMS instance."
I would argue that this is the simplest and cleanest way to achieve stated goal because it leads to N reverse VMPSes for a VMPS with
N receivers. I think that if application requires support of revese traffic then either it should be OOB or use VPLS model instead
of VPMS.

Yes, this section says, if you want reverse traffic, you need to provision additional VPMS instances for that direction.
Or perhaps are you suggesting to write a sort of guideline when and which model you should adopt,
VPLS model or VPMS model?

And perhaps little typo in "That is, the combination between VLAN id and the flow direction is ..." should be "That is, combination
of VLAN id and the flow direction is ..."

I'll correct.

*	Section 7.3

"Auto-discovery will help operators' initial configuration of adding a new VPN (i.e., VPMS instance), adding/deleting new
sender/receiver, and so on."
I think that VPMS instance is created when a sender PE (can we use "s-PE") and at least one receiver PE (r-PE) been added. Without
this minimum requirement VPMS instance does not exist. If that is correct then only backup s-PE can be dynamically added/deleted
to/from VPMS without destroying the VPN.

You have a point.  This section auto-discovery needs additional consideration in the case multiple-sourced redundancy.
It will be addressed in the next revision.

*	Section 7.7.2 Testing

I think that it is useful to explixitly require ability to test not only connectivity over working P2MP connection but protecting
path(s) as well from s-PE and, possibly, sender CE.

Agreed.  Your requirement is important.
I think protecting path would probably mean "protecting PW" when you use redundancy in P2MP-PW.

Best regards,
Yuji

Regards,
Greg

------=_NextPart_000_0120_01C98BAD.A7A325E0
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-2022-jp">
<META content=3D"MSHTML 6.00.2800.1619" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2><FONT face=3D"=1B$B#M#S=1B(B =1B$B#P%4%7%C%/=1B(B" size=3D3>Hi =
Greg,</FONT></DIV>
<DIV><FONT face=3D"=1B$B#M#S=1B(B =1B$B#P%4%7%C%/=1B(B" =
size=3D3></FONT>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader lang=3Dja align=3Dleft><FONT =
face=3D"=1B$B#M#S=1B(B =1B$B#P%4%7%C%/=1B(B"=20
size=3D3>Thanks for comments.&nbsp; See inline below=20
please.</FONT>&nbsp;</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Dja dir=3Dltr =
align=3Dleft><SPAN=20
  class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dja dir=3Dltr =
align=3Dleft><SPAN=20
  class=3D468384208-10022009>&nbsp;</SPAN></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dja dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  </DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dja dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2><B>From:</B> [email-masked] =
[mailto:[email-masked]]=20
  <B>On Behalf Of </B>Greg Mirsky<BR><B>Sent:</B> Saturday, January 24, =
2009=20
  6:37 AM<BR><B>To:</B> [email-masked]<BR><B>Cc:</B>=20
  [email-masked]<BR><B>Subject:</B> Comments to VPMS=20
  Requirements<BR></FONT><BR></DIV>
  <DIV></DIV>Dear Yuji and All,<BR>please find my notes to the document=20
  below:<BR>
  <UL>
    <LI>Section 4.1</LI></UL>
  <DIV>"However, if only P2MP connectivity is required, the traffic =
between=20
  different receivers is not always needed, and traffic from receiver to =
sender=20
  is not always needed, either."<BR>I believe that in P2MP constructs=20
  connectivity between leafs is not just "not always needed" but =
prohibited. To=20
  enforce this might require extra efforts if P2MP uses VPLS. I propose =
changing=20
  this to:<BR>"However, if only P2MP connectivity is required, the =
traffic=20
  between leafs is not allowed. It might require extra efforts to =
guarantee this=20
  behavior in VPLS. And in some P2MP scenarios there no traffic from =
leafs to=20
  root."<SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D468384208-10022009><FONT=20
color=3D#0000ff>Agreed.</FONT>&nbsp;</SPAN><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <UL>
    <LI>Section 4.2</LI></UL>
  <DIV>I'm not sure how second paragraph of the section 4.2 is related =
to the=20
  subject of P2MP scenarios in TDM. And perhaps "drop-and-continue" =
TDM-based=20
  applications might be added as one of use cases that can benefit from=20
  VPMS.<SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2><BR><FONT face=3D"=1B$B#M#S=1B(B =1B$B#P%4%7%C%/=1B(B" =
size=3D3>I think you probably mentioned Section=20
4.3.<BR>Section 4.3 describes the use case of multicast clock =
distribution that=20
master clock is delivered via TDM P2MP-PW.&nbsp; Several end =
hosts<BR>will=20
receive the same TDM channel via p2mp topology=20
efficiently.</FONT></FONT></SPAN></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D468384208-10022009><FONT color=3D#0000ff>What kind of =
actual=20
applications do you assume in "drop-and-continue"?<BR>Are you looking at =

SONET-SDH ring protection's context, TDM-based multicast video delivery =
usage,=20
or anything else?<BR>Could you elaborate the application scenarios <SPAN =

class=3Dwordlink>a</SPAN> <SPAN class=3Dwordlink>little</SPAN> <SPAN=20
class=3Dwordlink>more</SPAN> if you have?&nbsp; <BR></FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <UL>
    <LI>Section 5</LI></UL>
  <DIV>Following seems somewhat ambiguous since frames might not be just =

  duplicated but replicated multiple times on the same node (PE or =
P)<BR>"The=20
  SP's network (PE as well as P) has a role to duplicate frames so that =
the=20
  traffic source does not need to send multiple frames to individual=20
  receivers."<BR>I think that it can be clarified as:<BR>"The SP's =
network (PE=20
  as well as P) has a role to replicate frames so that the sender's CE =
does not=20
  need to send multiple frames to individual receivers."<BR><SPAN=20
  class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE><SPAN =
class=3D468384208-10022009>
<DIV><FONT color=3D#0000ff><SPAN class=3D468384208-10022009>OK, I'll=20
</SPAN>correct<SPAN class=3D468384208-10022009>.</SPAN></FONT></DIV>
<DIV><FONT face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" color=3D#0000ff =
size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D468384208-10022009>&nbsp;</SPAN><BR>Is following a=20
  requirement or a statement:<BR>"In a VPMS, PEs will be connected by PW =

  technology which may include P2MP traffic optimization ..."<BR>If this =
is a=20
  statement that perhaps it can be re-worded as more probable wording=20
  like<BR>"PW technology with P2MP traffic optimization might be used in =
a VPMS=20
  ..."<BR><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE>
<DIV><SPAN class=3D468384208-10022009><FONT=20
color=3D#0000ff>Agreed.</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D468384208-10022009>&nbsp;</SPAN><BR>I don't =
understand if=20
  following is a requirement or statement of benefit:<BR>"Also routed =
backbone=20
  provides IP or MPLS-enabled PSN tunnels for transporting the PW =
traffic."<SPAN=20
  class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV><SPAN class=3D468384208-10022009><FONT color=3D#0000ff>It is just =
for an=20
explanation about whole framework, i.e., it's shown PSN tunnel is =
expected to be=20
naturally used as a transport</FONT></SPAN></DIV>
<DIV><SPAN class=3D468384208-10022009><FONT color=3D#0000ff>technology =
for PW in=20
VPMS. I'll consider editorial changes around here to make it more=20
clear.</FONT></SPAN><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <UL>
    <LI>Section 6.1.2 Multiple Source Support</LI></UL>
  <DIV>I understand this section as expression of requirement of VPMS's =
high=20
  availability. Is that correct understanding? If so, then I'd propose =
to change=20
  the name of the section to "VPMS High Availability" or remove the =
section all=20
  together since the subject is covered in section 6.4 Protection and=20
  Restoration. For one I'd suggest removing reference to support of =
multiple=20
  senders/sources in VPMS and mention redundant ACes. How to provide =
high=20
  availability in VPMS, I believe, is outside of the scope of the =
document but=20
  it is worth mentioning some of possible mechanisms, e.g. redundant =
ACes,=20
  redundant p2mp PWs, p2mp LSP protection, etc.<SPAN=20
  class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE><SPAN =
class=3D468384208-10022009>
<DIV><FONT color=3D#0000ff>&nbsp;<BR>I think supporting high =
availability is a=20
basic and important service<SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN>requirement,<SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN>so it's worth documenting even =
though the=20
detailed<BR>functional discussion (e.g., about P2MP PW, LSP etc.)<SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN>are out of the scope in this=20
draft.</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>But I agree with your opinion that Section =
6.1.2=20
largely overlaps with=1B$B!!=1B(BSection 6.4 now.<SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN>I'm going to merge/edit to make =
a=20
unified<BR>section about high-availability&nbsp; as much as=20
possible.</FONT></DIV>
<DIV><FONT color=3D#0000ff></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>As you pointed out, redundant (sourc-side) =
ACes=20
is=1B$B!!=1B(Bactually equivalent to redundant sources.<SPAN=20
class=3D468384208-10022009>&nbsp;&nbsp;</SPAN>I'll&nbsp;<SPAN=20
class=3D468384208-10022009>&nbsp;try to change</SPAN> the=20
text.</FONT>&nbsp;</SPAN><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <UL>
    <LI>Section 6.1.3 Reverse Traffic Support</LI></UL>
  <DIV>"The simplest way to accomplish this is to provide different VPMS =

  instances for reverse traffic, i.e. a sender CE is a receiver of =
another VPMS=20
  instance."<BR>I would argue that this is the simplest and cleanest way =
to=20
  achieve stated goal because it leads to N reverse VMPSes for a VMPS =
with N=20
  receivers. I think that if application requires support of revese =
traffic then=20
  either it should be OOB or use VPLS model instead of VPMS.<SPAN=20
  class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE><SPAN=20
class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff size=3D2></FONT><FONT=20
face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" color=3D#0000ff =
size=3D2></FONT><FONT face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" =
color=3D#0000ff size=3D2></FONT><FONT=20
face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" color=3D#0000ff =
size=3D2></FONT><FONT face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" =
color=3D#0000ff=20
size=3D2></FONT><FONT face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" =
color=3D#0000ff size=3D2></FONT><FONT=20
face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" color=3D#0000ff =
size=3D2></FONT>
<DIV><BR><FONT color=3D#0000ff>Yes, this section says, if you want =
reverse=20
traffic, you need to provision<SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN>additional VPMS instances for =
that=20
direction.<SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B"=20
size=3D2>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN class=3D468384208-10022009>Or perhaps =
are you=20
suggesting to write a sort of guideline when and which model you should=20
adopt,<BR>VPLS model or VPMS model?&nbsp;</SPAN></FONT></DIV><FONT=20
color=3D#0000ff></FONT>
<DIV><FONT color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D468384208-10022009>&nbsp;</SPAN><BR><BR>And perhaps =
little=20
  typo in "That is, the combination between VLAN id and the flow =
direction is=20
  ..." should be "That is, combination of VLAN id and the flow direction =
is=20
  ..."<SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2><BR><FONT face=3D"=1B$B#M#S=1B(B =1B$B#P%4%7%C%/=1B(B" =
size=3D3>I'll correct.&nbsp;=20
</FONT></FONT>&nbsp;</SPAN><BR></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <UL>
    <LI>Section 7.3</LI></UL>
  <DIV>"Auto-discovery will help operators' initial configuration of =
adding a=20
  new VPN (i.e., VPMS instance), adding/deleting new sender/receiver, =
and so=20
  on."<BR>I think that VPMS instance is created when a sender PE (can we =
use=20
  "s-PE") and at least one receiver PE (r-PE) been added. Without this =
minimum=20
  requirement VPMS instance does not exist. If that is correct then only =
backup=20
  s-PE can be dynamically added/deleted to/from VPMS without destroying =
the=20
  VPN.<SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D468384208-10022009></SPAN>&nbsp;</DIV></BLOCKQUOTE>
<DIV><SPAN class=3D468384208-10022009><FONT color=3D#0000ff>You have a =
point.&nbsp;=20
This section auto-discovery needs additional consideration in the case=20
multiple-sourced redundancy.<BR>It will be addressed in the next=20
revision.<BR></FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <UL>
    <LI>Section 7.7.2 Testing</LI></UL>
  <DIV>I think that it is useful to explixitly require ability to test =
not only=20
  connectivity over working P2MP connection but protecting path(s) as =
well from=20
  s-PE and, possibly, sender CE.<BR><SPAN =
class=3D468384208-10022009><FONT=20
  face=3D"=1B$B#M#S=1B(B =1B$B%4%7%C%/=1B(B" color=3D#0000ff =
size=3D2>&nbsp;</FONT></SPAN></DIV></BLOCKQUOTE><SPAN=20
class=3D468384208-10022009>
<DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D468384208-10022009><FONT =
color=3D#0000ff>Agreed.&nbsp; Your=20
requirement is important.&nbsp;</FONT>&nbsp;</SPAN><BR><FONT =
color=3D#0000ff>I=20
think protecting path would probably mean<SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN>"protecting PW" when you use =
redundancy in=20
P2MP-PW<SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" size=3D2><FONT=20
face=3D"=1B$B#M#S=1B(B =1B$B#P%4%7%C%/=1B(B" =
size=3D3>.</FONT>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff><SPAN=20
class=3D468384208-10022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff><SPAN=20
class=3D468384208-10022009></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff>Best regards,<BR>Yuji<SPAN=20
class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B"=20
size=3D2>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><SPAN class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"><SPAN=20
class=3D468384208-10022009>&nbsp;</SPAN><BR>Regards,<BR>Greg<BR><BR><SPAN=
=20
class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2>&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px"><SPAN=20
class=3D468384208-10022009><FONT face=3D"=1B$B#M#S=1B(B =
=1B$B%4%7%C%/=1B(B" color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0120_01C98BAD.A7A325E0--

From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: Fwd: Posting of IPR Disclosure
Date: Wed, 11 Feb 2009 20:12:22 -0700

FYI.  This doesn't appear to have made it to the list ...

-shane

Begin forwarded message:
> From: IETF Secretariat <[email-masked]>
> Date: February 11, 2009 3:36:27 PM MST
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked] 
> >
> Cc: "[email-masked]" <[email-masked]>,  
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked] 
> >, "Amante, Shane" <[email-masked]>, "[email-masked] 
> " <[email-masked]>, "[email-masked]" <[email-masked] 
> >
> Subject: Posting of IPR Disclosure
>
> Dear Yakov Rekhter, Kireeti Kompella:
>
> An IPR disclosure that pertains to your RFC entitled "Virtual  
> Private LAN
> Service (VPLS) Using BGP for Auto-discovery and Signaling" (RFC4761)  
> was
> submitted to the IETF Secretariat on 2009-02-10 and has been posted  
> on the "IETF
> Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/public/ipr_list.cgi). The title of the  
> IPR
> disclosure is "Juniper's Statement of IPR related to RFC 4761."
>
> The IETF Secretariat
>
>

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Subject: Document Action: 'Requirements for Multicast Support in  Virtual Private LAN Services' to Informational RFC 
Date: Tue, 17 Feb 2009 08:59:54 -0800 (PST)
Cc: l2vpn mailing list <[email-masked]>, l2vpn chair <[email-masked]>, Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>

The IESG has approved the following document:

- 'Requirements for Multicast Support in Virtual Private LAN Services '
   <draft-ietf-l2vpn-vpls-mcast-reqts-07.txt> as an Informational RFC

This document is the product of the Layer 2 Virtual Private Networks 
Working Group. 

The IESG contact persons are Mark Townsley and Jari Arkko.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-reqts-07.txt

Technical Summary 
This document provides functional requirements for network solutions 
that support multicast over Virtual Private LAN Service (VPLS). It 
specifies requirements both from the end user and service provider 
standpoints. It is intended that potential solutions will use these 
requirements as guidelines. 

Working Group Summary 

This document has been reviewed by carriers and experts in the L2VPN WG
and there are no outstanding issues. 

Document Quality 
This document was reviewed by the l2vpn chairs and Mark Townsley.

Personnel 
Who is the Document Shepherd for this document? 
Shane Amante ([email-masked]) 

Who is the Responsible Area Director? 
Mark Townsley ([email-masked])

Date: Thu, 19 Feb 2009 11:59:30 -0500
Subject: Re: Comments to VPMS Requirements
From: Greg Mirsky <[email-masked]>
To: Yuji KAMITE <[email-masked]>
Cc: [email-masked]

--0016368e2b20bca18504634875ff
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Yuji,
thank you for your consideration. Please find my clarifications in-line
tagged [GIM]

[snip]

>
>    - Section 4.2
>
> I'm not sure how second paragraph of the section 4.2 is related to the
> subject of P2MP scenarios in TDM. And perhaps "drop-and-continue" TDM-based
> applications might be added as one of use cases that can benefit from VPMS.
>
>
>
> I think you probably mentioned Section 4.3.
> Section 4.3 describes the use case of multicast clock distribution that
> master clock is delivered via TDM P2MP-PW.  Several end hosts
> will receive the same TDM channel via p2mp topology efficiently.
>
> What kind of actual applications do you assume in "drop-and-continue"?
> Are you looking at SONET-SDH ring protection's context, TDM-based multicast
> video delivery usage, or anything else?
> Could you elaborate the application scenarios a little more if you have?
>
[GIM] You're right, it was Section 4.3. I thought of TDM-based video
distribution but your study case is perfectly fine for VPMS.

[snip]

>
>
>    - Section 6.1.3 Reverse Traffic Support
>
> "The simplest way to accomplish this is to provide different VPMS instances
> for reverse traffic, i.e. a sender CE is a receiver of another VPMS
> instance."
> I would argue that this is the simplest and cleanest way to achieve stated
> goal because it leads to N reverse VMPSes for a VMPS with N receivers. I
> think that if application requires support of revese traffic then either it
> should be OOB or use VPLS model instead of VPMS.
>
>
>
> Yes, this section says, if you want reverse traffic, you need to provision
>  additional VPMS instances for that direction.
> Or perhaps are you suggesting to write a sort of guideline when and which
> model you should adopt,
> VPLS model or VPMS model?
>
>
[GIM] I'm concerned that VPMS model doesn't allow it to be used as E-Tree as
defined by MEF in Section 6.3 MEF6.1. This is probably neither good nor bad
but just a fact.
But if we decide that VPMS is essentially unidirectional service, then all
applications that require bi-directional commuunication between the root and
a leaf are outside of the scope of VPMS and the only model we have in l2vpn
now for such applications will be VPLS.

Kind regards,
Greg

--0016368e2b20bca18504634875ff
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

--0016368e2b20bca18504634875ff--

Date: Fri, 20 Feb 2009 15:14:33 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: the first MPLS-TP RFC

All,

we have our first MPLS-TP RFC:

         RFC 5317

         Title:      Joint Working Team (JWT) Report
                     on MPLS Architectural Considerations for a
                     Transport Profile
         Author:     S. Bryant, Ed.,
                     L. Andersson, Ed.
         Status:     Informational
         Date:       February 2009
         Mailbox:    [email-masked],
                     [email-masked]
         Pages:      10, 68
         Characters: 18367, 1411313
         Updates/Obsoletes/SeeAlso:   None

         I-D Tag:    draft-bryant-mpls-tp-jwt-report-00.txt

         URL:        http://www.rfc-editor.org/rfc/rfc5317.txt

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Date: Mon, 23 Feb 2009 15:26:09 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked],  [email-masked], Ross Callon <[email-masked]>,  David Ward <[email-masked]>, ITU-T ad hoc team on MPLS-TP <[email-masked]>
Subject: new mpls(-tp) working group document

Dear all,

the poll for draft-gray-mpls-tp-nm-req to become MPLS WG document
has ended with full support.

Authors, please republish as: draft-ietf-mpls-tp-nm-req-00

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

Date: Thu, 26 Feb 2009 12:49:09 +0100
From: Loa Andersson <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked],  ITU-T ad hoc team on MPLS-TP <[email-masked]>, [email-masked], IAB IAB <[email-masked]>, "Iesg (E-mail)" <[email-masked]>
Subject: RFC 5462 the second MPLS-TP RFC

All,

we have just seen our second mpls-tp RFC being published:

RFC5462 'Multiprotocol Label Switching (MPLS) Label Stack Entry:
         "EXP" Field Renamed to "Traffic Class" Field'.

/Loa

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]